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

Iury Gregory iurygregory at gmail.com
Fri Jan 22 03:00:51 UTC 2021


I think it is a good idea to be more flexible for the generic drivers.
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)

Em qui., 21 de jan. de 2021 às 15:46, Julia Kreger <
juliaashleykreger at gmail.com> escreveu:

> 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
>
>

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210122/df05f8c3/attachment-0001.html>


More information about the openstack-discuss mailing list