<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, May 13, 2013 at 11:33 AM, Scott Moser <span dir="ltr"><<a href="mailto:smoser@ubuntu.com" target="_blank">smoser@ubuntu.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 13 May 2013, Devananda van der Veen wrote:<br>
<br>
> On Mon, May 13, 2013 at 9:47 AM, Scott Moser <<a href="mailto:smoser@ubuntu.com">smoser@ubuntu.com</a>> wrote:<br>
><br>
> > On Fri, 10 May 2013, Clint Byrum wrote:<br>
> ><br>
<br>
</div><div class="im">> > I largely agree here, but we have config-drive in nova.  I think it makes<br>
> > sense to have an analog in bare metal provisioning.  In bare metal, it<br>
> > would actually allow the nodes to never have access to the management<br>
> > network while in "user" possession (ie, detach pxe/management network<br>
> > after system installed).<br>
> ><br>
> ><br>
> Config drive for baremetal seems possible for some (but not all) hardware.<br>
> Clearly, we'll need to support multiple deployment models :)<br>
<br>
</div>Can you give an example of what hardware would not be supported?<br></blockquote><div><br></div><div style>Any hardware which doesn't support mounting virtual media and exposing it to the guest -- this is, afaict, not part of the IPMI specification, though most large hw vendors have implemented it anyway.</div>

<div style><br></div><div style>Also, this approach would be unsuitable for high-density compute where many SOCs share a single management board, even if that BMC supports virtual media, since this would serialize the deployment process.</div>

<div style><br></div><div style> (caveat: I'm assuming that HDC systems whose BMC support virtual media would only support mounting a small number of, or just one, virtual media at a time. I base this assumption on the knowledge that some HDC systems have a limitation to the number of concurrent SOL sessions, which is considerably lower than the number of SOCs they contain.)</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> However, detaching from the management network seems like less than great<br>
> security to me. The moment that the user requests any management of their<br>
> instance be performed, you'll have to reconnect it to the management<br>
> network *before* you can power it down (or do what ever else you need).<br>
> There is still a clear (though perhaps shorter) window where the tenant has<br>
> access to the management network.<br>
<br>
> Also, the management network is the only vector for the cloud operator to<br>
> monitor the health of a bare metal instance (eg., poll power state and hw<br>
> sensors over IPMI). Not having that visibility seems, well, like a bad idea<br>
> to me.<br>
<br>
</div>You seem to assume there that ipmi or other power control is on the same<br>
network as the pxe boot or other network that the user needs to use.<br>
I dont think that is necessarily true. That may be a silly/broken<br>
limitation of ipmi (ipmi does have shortcomings for untrusted occupant).<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div style>Perhaps we meant different things by "management network". I was including both the out-of-band network (eg, for IPMI) and the network used for image deployment under the broad heading of "Management networks", whether these are actually handled by one or multiple NICs, VLANs, or what ever. Instance provisioning requires access to both; instance management requires access to the out-of-band net, and tenants do not require access to either. Removing tenant access from the network used for image deployment should be straight forward, and should be fine to do once deployment is complete, but I don't think we shouldn't be mucking with the out-of-band network.</div>

<div style><br></div><div style>Anyway, I think we agree on all that, and I probably just misinterpreted "detach from the management network" as "detach from both IPMI and PXE networks", which it seems is not what you meant :)</div>

<div style><br></div><div style>Cheers,</div><div style>-Devananda</div><div> </div></div></div></div>