Open Stack

On 04/26/2013 06:29 AM, Mark McLoughlin wrote:
> Hey
> 
> On Thu, 2013-04-25 at 11:57 -0700, Devananda van der Veen wrote:
>> In the Nova "Baremetal Next Steps" design session last Thursday, I proposed
>> that we split the baremetal driver out into its own top-level project -
>> this was met with support from everyone in the room. We then discussed the
>> project's plans and how such a split should be done. I have written up that
>> proposal in more detail here, and would like to bring this before the TC.
>>
>> https://wiki.openstack.org/wiki/BaremetalSplitRationale
> 
> I'm all for the code being in a separate project - I think this thing
> could have users outside of Nova.
> 
> I did work up an idea for how it could be done during Folsom
> development, but I actually was thinking of it just being a library:
> 
>   https://gist.github.com/markmc/5466295
> 
> Not much detail there, but BareMetalConnection/BareMetalNode would be in
> the library and BareMetalDriver would be the Nova part. I hadn't figured
> on this being a service with its own REST API, but perhaps that does
> make sense.

I'm +1 on splitting it out.  I wasn't too sure about library vs. service
with an API because I'm not hugely familiar with this code, anyway.  I
think Devananda did a nice job documenting the rationale, though.  I
think this bullet from the doc helps push me toward the idea of a service:

    Operational teams often perform tasks on hardware which do not
    apply to virtual machines (eg., discovery, HW RAID configuration,
    firmware updates, burn-in). These could be added as Nova API
    extensions, but again, it seems like the wrong approach. Instead,
    a separate API could manage hardware before exposing via the Nova
    API. For example, after being discovered, configured, updated, and
    burned in by Ironic, it could then be enrolled with Nova and
    provisioned as any other cloud instance (eg, via "nova boot").

It seems that a separate API makes sense here to avoid making awkward
extensions to the compute API.

> However, that does make me wonder whether we'd see desire to plug
> alternative baremetal provisioning technologies into that API, in the
> same way we see a desire for alternative backends to the Swift API.

Would that be a problem?  Actually, is that different from how it works
already?

    cfg.StrOpt('driver',
               default='nova.virt.baremetal.pxe.PXE',
               help='Baremetal driver back-end (pxe or tilera)'),
    cfg.StrOpt('power_manager',
               default='nova.virt.baremetal.ipmi.IPMI',
               help='Baremetal power management method'),

> Finally, making this a service (with a yet undefined API) rather than a
> library makes me think the new project should go through an incubation
> period, rather than bypassing incubation the way Cinder did.

I agree here.

I'm actually generally concerned with the fast-track approach.  I do not
think it is the case here, but it could be abused in the future as an
alternative, perhaps easier method to getting a project to be
integrated.  I have actually heard this exact strategy mentioned in
conversation (growing something in a project and then splitting it off,
because it seems as if it will be easier that way).

-- 
Russell Bryant