[openstack-dev] [ironic] midcycle recording and summary

Dmitry Tantsur dtantsur at redhat.com
Tue Dec 5 16:58:42 UTC 2017


Hi all!

Sorry for the delay with this, here is the summary of the midcycle.

The midcycle notes are at 
https://etherpad.openstack.org/p/ironic-queens-midcycle, and the recording is 
https://bluejeans.com/s/h7gNU (requires flash, but can be downloaded).


We discussed four topics:

(I) Queens priorities

Most of the work is moving forward quite well. The following things raised concerns:
1. Classic driver deprecation. Still a lot of documentation to update (and 
sometimes write). Tracking at 
https://etherpad.openstack.org/p/ironic-switch-to-hardware-types
2. Graphical console. Was not moving at all, still on the spec stage. Was 
updated by pas-ha after the midcycle, but still at high risk for Queens.
3. Reference architecture guide. I was not able to do much after landing the 
common bits. I may be able to get to it closer to the release, but help is 
appreciated. Let me know if you want to get one of use cases and cover it.
4. Neutron event processing. On the spec stage, at risk for Queens.
5. BIOS configuration. The spec is moving well, but the driver implementations 
may slip into Rocky.

(II) Forum feedback

Julia walked us through 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124520.html. A 
few RFEs will be written as a result of the discussion.

(II) API version negotiation in Nova

We need to stop hardcoding one and only one ironic API version in our virt 
driver. Works is to be done on ironicclient to make it technically possible. We 
discussed several variants of how it may look. I would like to start a 
discussion in a form of an API-SIG guideline, so that we have a recommendation 
for all SDKs to do it similarly.

(IV) Automatic upgrades to hardware types

We would like to help operators to migrate the nodes to hardware types. We 
discussed a recent suggestion to provide migration on the API level. We rejected 
it for several reasons:
1. anything implemented in the API has to stay essentially forever
2. it won't work for out-of-tree drivers
3. result of the creation API will not match what a user supplied

We agreed to migrate existing nodes as part of online_data_migration, I'm 
planning to amend the spec with it.


Thanks all,
Dmitry



More information about the OpenStack-dev mailing list