Open Stack

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
fast-track projects.


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
> 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).
> >
> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/204e037a/attachment.html>