<p dir="ltr"><br>
On Apr 26, 2013 3:29 AM, "Mark McLoughlin" <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
><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">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">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>
></p>
<p dir="ltr">I thought about / discussed this with a few folks, but all the physical bits don't seem to fit well in Nova's API, DB, or general paradigm.</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">Yes, exactly, and the code already supports pluggable power and imaging drivers (and has more than one of each). I intend to add pluggable back ends for discovery and firmware mgmt as well, but don't feel that fits within Nova's scope.</p>

<p dir="ltr">> 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.</p>
<p dir="ltr">There is an extension to the nova API for managing baremetal nodes and interfaces, which I plan to expand on. Does that count? :)<br></p>
<p dir="ltr">-Deva<br>
</p>