[ironic] On redfish-virtual-media vs idrac-redfish-virtual-media

Julia Kreger juliaashleykreger at gmail.com
Thu Jan 21 14:44:26 UTC 2021

So, un-written and always situational flexible.

When we all started down the path of creating ironic so many years ago.

Wow I suddenly feel old.

Anyway, back then we were a bit naive to think every vendor properly
and consistently implemented vendor hardware behavior and interfaces
the same way. Reality has been kind of far from it and vendors really
don't like changing BMC code to become compliant to standard after the
fact. I think the right thing is trying to provide guard rails to
continue to do the right thing for the user since vendors are
generally getting mostly compliant, the rest is fairly easy to handle
if we know what... and how to handle these things.

So overall, I think it is perfectly acceptable to have some
conditional code in generic drivers... especially of advanced
features, to go "oh, we need this $thing slightly differently" or "Oh,
This driver is completely wrong, lets fix it for them magically"

So implementation details aside (as it is the implementer's
prerogative on the initial design) , I'm good and agree with the
general ideas. Hope that makes sense.

On Wed, Jan 20, 2021 at 9:56 AM Dmitry Tantsur <dtantsur at redhat.com> wrote:
> Hi all,
> 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.
> 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.
> 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.
> 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).
> Thoughts?
> Dmitry
> [1] https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024d16cbf5829b2c/ironic/drivers/modules/drac/boot.py#L130
> [2] https://review.opendev.org/c/openstack/ironic/+/757198/
> [3] https://review.opendev.org/c/openstack/ironic/+/771619
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

More information about the openstack-discuss mailing list