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 ), 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@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@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@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[]'s
Iury Gregory Melo Ferreira 
MSc in Computer Science at UFCG
Part of the puppet-manager-core team in OpenStack
Software Engineer at Red Hat Czech