[openstack-dev] [openstack-tc] Splitting the Baremetal driver out of Nova
m at metacloud.com
Fri Apr 26 18:24:39 UTC 2013
I agree with Russell's timeline. Once Ironic is integrated, there really
isn't a need to maintain duplicate code paths (if the feature parity is
there). If it's a vast departure/rearchitecture (which it doesn't look
like this will be) such as the split for openstack networking from
Nova-Network, the staged / dual system support is required.
+1 from me as well on the split.
It should also be made clear that this is a revisit of the approach because
it "doesn't fit in nova" as well as it really stands on it's own as a
project in light of the concerns that this process could be used to
On Fri, Apr 26, 2013 at 8:56 AM, Russell Bryant <rbryant at redhat.com> wrote:
> On 04/26/2013 10:26 AM, Monty Taylor wrote:
> > On 04/26/2013 09:56 AM, Russell Bryant wrote:
> >> 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
> >>>> 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
> >>>> 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
> >>> the library and BareMetalDriver would be the Nova part. I hadn't
> >>> 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
> >> 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).
> > Good point.
> > As it pertains to incubated splits and the deprecation of the feature in
> > the original project - what do we think the cutover should be? If, for
> > instance, we moved forward with Ironic as an incubated project, and then
> > accepted into integrated for "I" - since there had already been the
> > Havana cycle with the external project and the incubated project, do we
> > pull the code from nova in I? Or do we wait until J?
> If there is a sufficiently documented migration path, I think pulling
> baremetal out of Nova in the same release Ironic becomes integrated
> would be acceptable (so, theoretically I in this case).
> Russell Bryant
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev