Open Stack

Hi

On 13-04-26 02:24 PM, Morgan Fainberg wrote:
> 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.

I think that if you follow the way cinder did it I think that would work.
>
> 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 
> <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev