Open Stack

I agree.

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 competing
standards <https://xkcd.com/927/> ), 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.

To cut the long story short - I'm all for relaxing the rules where
reasonable and where needed, as pointed out by Dmitry.

Thank you,
Jacob

On Fri, Jan 22, 2021 at 1:07 PM Iury Gregory <iurygregory at gmail.com> wrote:

> 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/416b678d/attachment.html>