<div dir="ltr">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. <div>
<br></div><div>+1 from me as well on the split.</div><div><br></div><div>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.<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 8:56 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/26/2013 10:26 AM, Monty Taylor wrote:<br>
<div><div class="h5">><br>
><br>
> On 04/26/2013 09:56 AM, Russell Bryant wrote:<br>
>> On 04/26/2013 06:29 AM, Mark McLoughlin wrote:<br>
>>> Hey<br>
>>><br>
>>> On Thu, 2013-04-25 at 11:57 -0700, Devananda van der Veen wrote:<br>
>>>> In the Nova "Baremetal Next Steps" design session last Thursday, I proposed<br>
>>>> that we split the baremetal driver out into its own top-level project -<br>
>>>> this was met with support from everyone in the room. We then discussed the<br>
>>>> project's plans and how such a split should be done. I have written up that<br>
>>>> proposal in more detail here, and would like to bring this before the TC.<br>
>>>><br>
>>>> <a href="https://wiki.openstack.org/wiki/BaremetalSplitRationale" target="_blank">https://wiki.openstack.org/wiki/BaremetalSplitRationale</a><br>
>>><br>
>>> I'm all for the code being in a separate project - I think this thing<br>
>>> could have users outside of Nova.<br>
>>><br>
>>> I did work up an idea for how it could be done during Folsom<br>
>>> development, but I actually was thinking of it just being a library:<br>
>>><br>
>>> <a href="https://gist.github.com/markmc/5466295" target="_blank">https://gist.github.com/markmc/5466295</a><br>
>>><br>
>>> Not much detail there, but BareMetalConnection/BareMetalNode would be in<br>
>>> the library and BareMetalDriver would be the Nova part. I hadn't figured<br>
>>> on this being a service with its own REST API, but perhaps that does<br>
>>> make sense.<br>
>><br>
>> I'm +1 on splitting it out. I wasn't too sure about library vs. service<br>
>> with an API because I'm not hugely familiar with this code, anyway. I<br>
>> think Devananda did a nice job documenting the rationale, though. I<br>
>> think this bullet from the doc helps push me toward the idea of a service:<br>
>><br>
>> Operational teams often perform tasks on hardware which do not<br>
>> apply to virtual machines (eg., discovery, HW RAID configuration,<br>
>> firmware updates, burn-in). These could be added as Nova API<br>
>> extensions, but again, it seems like the wrong approach. Instead,<br>
>> a separate API could manage hardware before exposing via the Nova<br>
>> API. For example, after being discovered, configured, updated, and<br>
>> burned in by Ironic, it could then be enrolled with Nova and<br>
>> provisioned as any other cloud instance (eg, via "nova boot").<br>
>><br>
>> It seems that a separate API makes sense here to avoid making awkward<br>
>> extensions to the compute API.<br>
>><br>
>>> However, that does make me wonder whether we'd see desire to plug<br>
>>> alternative baremetal provisioning technologies into that API, in the<br>
>>> same way we see a desire for alternative backends to the Swift API.<br>
>><br>
>> Would that be a problem? Actually, is that different from how it works<br>
>> already?<br>
>><br>
>> cfg.StrOpt('driver',<br>
>> default='nova.virt.baremetal.pxe.PXE',<br>
>> help='Baremetal driver back-end (pxe or tilera)'),<br>
>> cfg.StrOpt('power_manager',<br>
>> default='nova.virt.baremetal.ipmi.IPMI',<br>
>> help='Baremetal power management method'),<br>
>><br>
>>> Finally, making this a service (with a yet undefined API) rather than a<br>
>>> library makes me think the new project should go through an incubation<br>
>>> period, rather than bypassing incubation the way Cinder did.<br>
>><br>
>> I agree here.<br>
>><br>
>> I'm actually generally concerned with the fast-track approach. I do not<br>
>> think it is the case here, but it could be abused in the future as an<br>
>> alternative, perhaps easier method to getting a project to be<br>
>> integrated. I have actually heard this exact strategy mentioned in<br>
>> conversation (growing something in a project and then splitting it off,<br>
>> because it seems as if it will be easier that way).<br>
><br>
</div></div>> Good point.<br>
><br>
> As it pertains to incubated splits and the deprecation of the feature in<br>
> the original project - what do we think the cutover should be? If, for<br>
> instance, we moved forward with Ironic as an incubated project, and then<br>
> accepted into integrated for "I" - since there had already been the<br>
> Havana cycle with the external project and the incubated project, do we<br>
> pull the code from nova in I? Or do we wait until J?<br>
<br>
If there is a sufficiently documented migration path, I think pulling<br>
baremetal out of Nova in the same release Ironic becomes integrated<br>
would be acceptable (so, theoretically I in this case).<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>