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 
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,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to