Open Stack

Hi,

> I see in the priority list that "redfish support" is still highly wanted (4
> +1).
> And we are still very interested to provide that. It took much more time
> than expected, as we first decided that we wanted a good low level library
> to help us dialog following the Redfish standard to the management board of
> systems.
>
> Now that we have this [1] much more in place than last year [2], and due to
> some nascient customer demand, we would like to come back to this community
> to propose to work with you on providing this feature into future Ironic
> releases.
>

Cool, looking forward to see it proposed and merged!

> We're not the most proficient OpenStack contributors as of now, so will need
> your help and guidance wrt both processes and code aspects.
> And as our knowledge of the internals of Ironic is still weak, we may have
> difficulties to describe precisely in a Blueprint what will be the impact at
> Ironic level of the addition of that feature.
>
> I understood that this community is now using RFE bugs to follow this type
> of work, and I suppose we need to resubmit a new proposal (IIUC maybe more
> precise, less generic wrt architecture). Is the BR indeed the right place to
> do that (as I understood from [3]) ? Should we rather start working at the
> code level to understand how we could hook that feature in the current code
> base (idea would be to mimic how the iLO driver is doing it today to have a
> skeleton of code for our redfish driver) and then show some code before
> being able to see the proposal accepted (even if they get the -2 mentioned
> on [4]) ?
>

Yes [3] is the way to go. In a RFE the problem can be described in a
high-level language, if some parts are controversial then a spec will
be required (which requires more details on each specific area the
feature will impact and so on). One tip here: Start small.

I see that you want you want mimic the iLO driver which is a very
featured driver in tree, support things like virtual media, RAID
configuration, secure boot, etc... Instead of writing an RFE for
having feature parity with it I would instead break it into multiple
RFEs. For example, the first RFE could be about implementing the power
interface (power on/off, reboot, get power state) using redfish, that
should be straight forward and you will have the foundation of your
driver now merged into the code base. From there one you can open
another RFE for each feature.

It's important to remember that drivers required 3rd party CI, so,
this makes it easy to extend the redfish CI as you go (since redfish
controller be simulated - not requiring real bare metal for tests - it
may be possible to test it using the standard gate jobs).


> Some basic questions:
> I'm also a bit lost with terminology: Should I call this a redfish driver
> (like an iLO driver) or a redfish module, with drivers being pxe_redfish ?

I would call it a driver, of course that in code we will have a
redfish module (under ironic/drivers/modules).

> Should I put my proposal in ironic-specs under specs/not-implemented ? There
> is no directory for Newton there so I guess the process changed, but I
> haven't found a doc guiding me on where to put new spec proposals sorry.
> Menwhile it's readable at [5].
>

You should put it in specs/approved with a symlink into
specs/not-implenented [0]. But again, only if a spec is needed, I
wouldn't mind it too much, start with the RFE and we go from there.

[0] https://github.com/openstack/ironic-specs#openstack-baremetal-provisioning-specifications

Hope that helps,
Lucas