Open Stack

On Wed, Oct 07, 2015 at 12:41:55PM -0700, Devananda van der Veen wrote:
> Ramesh,
> 
> I thought about your points over night, and then looked at our in-tree
> driver code from stable/kilo and asked myself, "what if this driver was out
> of tree?" They'd all have broken -- for very similar reasons as what I
> encountered with my demo driver.
> 
> When we split the boot and deploy interfaces, we kept compatibility only at
> the boundary between ConductorManager and the Driver class. That's all we
> set out to do, because that's all we defined the interface to be. I can
> accept that, but I'd like us to think about whether the driver interface:
> a) is merely the interfaces defined in ironic/drivers/base.py, as we
> previously defined, or
> b) also includes one or more of the hardware-agnostic interface
> implementations (eg, PXEBoot, AgentDeploy, AgentRAID, inspector.Inspector)
> 
> As recent experience has taught me, these classes provide essential
> primitives for building new hardware drivers. If we want to support
> development of hardware drivers out of tree, but we don't want to include
> (b) in our definition of the API, then we are signalling that such drivers
> must be implemented entirely out of tree (iow, they're not allowed to
> borrow *any* functionality from ironic/drivers/modules/*).
> 
> And if we're signalling that, and someone goes and implements such a driver
> and then later wants to propose it upstream -- how will we feel about
> accepting a completely alternative implementation of, say, the pxe boot
> driver?

I agree; there's some hard things to think about here. I'd like to get a
definition of our driver API solidified and documented during Mitaka.
It's odd, because there are two pieces to (b) above; the names/methods
provided, and the actual behavior. I'm not sure that AgentDeploy is not
backwards compatible when it comes to names or methods, but we've
certainly changed the behavior. I've added this topic to our design
summit proposal list.

As for the original problem, I like ramesh's idea with the FakeBoot
driver. I think it will cause the least amount of breakage to
out-of-tree drivers, and still allow for an easy fix. We *do* need to be
very loud about this in release notes, ops mailing list, etc.

Deva, could you update the patch ASAP? I'd like to get it landed
tomorrow, so we can backport and get 4.2.1 out the door this week.

Thanks for digging into this! :)

// jim