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