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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
