<div dir="ltr">I agree.<div><br></div><div>As someone who transitioned from an Ironic operator to Ironic developer, I'd like to stress the importance of user experience (and as a result, user confidence). As much as I dislike non-compliance with standards (and <a href="https://xkcd.com/927/" target="_blank">competing standards</a> ), I believe that directly exposing the users to these for the sake of a cleaner codebase isn't the right thing to do. It's really bad if operators have to deep dive into the inner workings of the drivers to figure out what's going on (got some past first-hand experience unfortunately). This often results in site-specific workarounds and fixes which may be never accepted upstream and the time spent developing these could be better spent contributing to Ironic.</div><div><br></div><div>To cut the long story short - I'm all for relaxing the rules where reasonable and where needed, as pointed out by Dmitry.</div><div><br></div><div>Thank you,</div><div>Jacob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 22, 2021 at 1:07 PM Iury Gregory <<a href="mailto:iurygregory@gmail.com" target="_blank">iurygregory@gmail.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></div><div>I think it is a good idea to be more flexible for the generic drivers. <br>The approach to block redfish-virtual-media for Dell is something that makes sense to me, at least we can easily backport to  stable branches (I see the approach to make redfish-virtual-media work for Dell on stable branches as a feature, but I may be mistaken)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 21 de jan. de 2021 às 15:46, Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, un-written and always situational flexible.<br>
<br>
When we all started down the path of creating ironic so many years ago.<br>
<br>
Wow I suddenly feel old.<br>
<br>
Anyway, back then we were a bit naive to think every vendor properly<br>
and consistently implemented vendor hardware behavior and interfaces<br>
the same way. Reality has been kind of far from it and vendors really<br>
don't like changing BMC code to become compliant to standard after the<br>
fact. I think the right thing is trying to provide guard rails to<br>
continue to do the right thing for the user since vendors are<br>
generally getting mostly compliant, the rest is fairly easy to handle<br>
if we know what... and how to handle these things.<br>
<br>
So overall, I think it is perfectly acceptable to have some<br>
conditional code in generic drivers... especially of advanced<br>
features, to go "oh, we need this $thing slightly differently" or "Oh,<br>
This driver is completely wrong, lets fix it for them magically"<br>
<br>
So implementation details aside (as it is the implementer's<br>
prerogative on the initial design) , I'm good and agree with the<br>
general ideas. Hope that makes sense.<br>
<br>
On Wed, Jan 20, 2021 at 9:56 AM Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> Now that we've gained some experience with using Redfish virtual media I'd like to reopen the discussion about $subj. For the context, the idrac-redfish-virtual-media boot interface appeared because Dell machines need an additional action [1] to boot from virtual media. The initial position on hardware interfaces was that anything requiring OEM actions must go into a vendor hardware interface. I would like to propose relaxing this (likely unwritten) rule.<br>
><br>
> You see, this distinction causes a lot of confusion. Ironic supports Redfish, ironic supports iDRAC, iDRAC supports Redfish, ironic supports virtual media, Redfish supports virtual media, iDRAC supports virtual media. BUT! You cannot use redfish-virtual-media with iDRAC. Just today I had to explain the cause of it to a few people. It required diving into how exactly Redfish works and how exactly ironic uses it, which is something we want to protect our users from.<br>
><br>
> We already have a precedent [2] of adding vendor-specific handling to a generic driver. I have proposed a patch [3] to block using redfish-virtual-media for Dell hardware, but I grew to dislike this approach. It does not have precedents in the ironic code base and it won't scale well if we have to handle vendor differences for vendors that don't have ironic drivers.<br>
><br>
> Based on all this I suggest relaxing the rule to the following: if a feature supported by a generic hardware interface requires additional actions or has a minor deviation from the standard, allow handling it in the generic hardware interface. Meaning, redfish-virtual-media starts handling the Dell case by checking the System manufacturer (via the recently added detect_vendor call) and loading the OEM code if it matches "Dell". After this idrac-redfish-virtual-media will stay empty (for future enhancements and to make the patch backportable).<br>
><br>
> Thoughts?<br>
><br>
> Dmitry<br>
><br>
> [1] <a href="https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024d16cbf5829b2c/ironic/drivers/modules/drac/boot.py#L130" rel="noreferrer" target="_blank">https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024d16cbf5829b2c/ironic/drivers/modules/drac/boot.py#L130</a><br>
> [2] <a href="https://review.opendev.org/c/openstack/ironic/+/757198/" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/ironic/+/757198/</a><br>
> [3] <a href="https://review.opendev.org/c/openstack/ironic/+/771619" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/ironic/+/771619</a><br>
><br>
> --<br>
> Red Hat GmbH, <a href="https://de.redhat.com/" rel="noreferrer" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn,<br>
> Commercial register: Amtsgericht Muenchen, HRB 153243,<br>
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="background-color:rgb(255,255,255)"><font style="background-color:transparent"><div><div dir="ltr"><div><div style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:12.8px"><i style="font-size:13px"><font style="color:rgb(0,0,0)">Att[]'s</font><br><font color="#500050"><span style="color:rgb(0,0,0)">Iury Gregory Melo Ferreira</span> </font><br></i><i><font color="#000000">MSc in Computer Science at UFCG<br></font></i></div><div style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:12.8px"><i><font color="#000000">Part of the puppet-manager-core team in OpenStack</font></i><br><i><font color="#000000"><span style="background-color:rgb(255,255,255)"><font style="background-color:transparent"><i><font color="#000000">Software Engineer at Red Hat Czech</font></i></font></span></font></i></div><div><font style="font-family:arial,sans-serif;font-size:12.8px" color="#000000"><i>Social</i>:</font><font style="font-family:arial,sans-serif;font-size:12.8px"><font color="#888888"> </font><a href="https://www.linkedin.com/in/iurygregory" target="_blank"><font color="#0b5394">https://www.linkedin.com/in/iurygregory</font></a></font></div><div><i style="color:rgb(136,136,136);background-color:transparent;font-size:13px"><font color="#500050"><span style="color:rgb(0,0,0)">E-mail: </span> </font><a href="mailto:iurygregory@gmail.com" style="color:rgb(0,84,136)" target="_blank">iurygregory@gmail.com</a></i></div></div></div></div></font></span></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>