<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 19, 2020 at 7:31 AM Donny Davis <<a href="mailto:donny@fortnebula.com">donny@fortnebula.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 18, 2020 at 11:57 PM Dan Sneddon <<a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Steve, Lars,</div><div dir="auto"><br></div><div dir="auto">I just wanted to throw an idea out there:</div><div dir="auto"><br></div><div dir="auto">Redfish requires user accounts. Is there a way to stretch this idea into a more general Redfish proxy? Ironic would have to create a temporary user account for Redfish in the BMC, and then provide the tenant an IP:port of a TCP proxy for the tenant to connect to. </div><div dir="auto"><br></div><div dir="auto">The TCP proxy would be deactivated when the node was deleted. When the node was cleaned, the user account would be removed. When nodes were scheduled, the Ironic-generated user accounts would be removed and recreated as needed based on the scheduling request. Ironic settings could be provided to control the access rights/group of the user accounts.</div><div dir="auto"><br></div><div dir="auto">A variant of this would create and manage the user account, but not provide a TCP proxy. Instead, perhaps the BMC location could be returned. This would not meet the criteria of not providing direct access to the hardware. We would have to remove accounts from the BMC when the node was deleted or require cleaning, but it could still potentially be less secure.</div><div dir="auto"><br></div><div dir="auto">A downside of the role-based user scheduling approach is that Ironic then requires credentials for the BMC that include user account management, which could run counter to security policy. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 18, 2020 at 6:08 PM Steve Baker <<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>On 17/10/20 7:29 am, Lars Kellogg-Stedman wrote:<br><br>> In the work that we're doing with the Mass Open Cloud [1], we're<br><br>> looking at using Ironic (and the multi-tenant support we contributed)<br><br>> to manage access to a shared pool of hardware while still permitting<br><br>> people to use their own provisioning tools.<br><br>><br><br>> We don't want to expose the hardware BMC directly to consumers; we<br><br>> want Ironic to act as the access control mechanism for all activities<br><br>> involving the hardware.<br><br>><br><br>> The missing part of this scenario is that at the moment this would<br><br>> require provisioning tools to know how to talk to the Ironic API if<br><br>> they want to perform BMC actions on the host, such as controlling<br><br>> power.<br><br>><br><br>> While talking with Mainn the other day, it occurred to me that maybe<br><br>> we could teach virtualbmc [2] how to talk to Ironic, so that we could<br><br>> provide a virtual IPMI interface to provisioning tools. There are some<br><br>> obvious questions here around credentials (I think we'd probably<br><br>> generate them randomly when assigning control of a piece of hardware<br><br>> to someone, but that's more of an implementation detail).<br><br>><br><br>> I wanted to sanity check this idea: does this seem reasonable? Are<br><br>> there alternatives  you would suggest?<br><br><br><br>As far as I'm aware, an IPMI host:port endpoint will manage exactly one <br><br>baremetal host, with no obvious mechanism to specify which host to <br><br>control when you have multiple hosts behind a single endpoint. These <br><br>days with the rise of Redfish I think IPMI is considered a legacy <br><br>interface now.<br><br><br><br>I suspect a BMC interface is not the right abstraction for a <br><br>multi-tenant baremetal API, that's why Ironic was started in the first <br><br>place ;)<br><br><br><br>If there are provisioning tools frequently used by the target audience <br><br>of Mass Open Cloud which have poor Ironic API support then we'd like to <br><br>know what those tools are so we can improve that support.<br><br><br><br><br><br>> Thanks!<br><br>><br><br>> [1] <a href="https://github.com/CCI-MOC/esi" rel="noreferrer" target="_blank">https://github.com/CCI-MOC/esi</a><br><br>> [2] <a href="https://github.com/openstack/virtualbmc" rel="noreferrer" target="_blank">https://github.com/openstack/virtualbmc</a><br><br>><br><br><br><br><br><br></blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="monospace, monospace">Dan Sneddon         |  Senior Principal Software Engineer<br><a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a> |  <a href="http://redhat.com/cloud" target="_blank">redhat.com/cloud</a><br>dsneddon:irc        |  @dxs:twitter</font><br></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div><div>Lars, </div><div>Please forgive my ignorance if I did not understand your question. Why not just use Nova with the ironic driver? Nova won't tell a user about the abstraction to metal and it's pretty easy to get setup and running with Ironic. This way users can request a metal type that is predefined and the rest is handled for them. This way you can keep consumers and admins separate and provide that multi-tenant functionality without exposing any critical details of the underlying infra.  </div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>~/DonnyD</div><div>C: 805 814 6800</div><div>"No mission too difficult. No sacrifice too great. Duty First"</div></div></div></div>
</blockquote></div><div><br></div><div>/donnyd shakes fist at gmail </div><div><br></div><div><div>Lars, </div><div>Please forgive my ignorance if I did not understand your question. Why not just use Nova with the ironic driver? Nova won't tell a user about the abstraction to metal and it's pretty easy to get setup and running with Ironic. This way users can request a metal type that is predefined and the rest is handled for them. This way you can keep consumers and admins separate and provide that multi-tenant functionality without exposing any critical details of the underlying infra.</div></div><div><br></div><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>~/DonnyD</div><div>C: 805 814 6800</div><div>"No mission too difficult. No sacrifice too great. Duty First"</div></div></div></div>