On Mon, 17 Sep 2018, Jolliffe, Ian wrote:
and the notes below summarize the outcomes. This does not reflect the outcomes of the direct engagement with the Neutron and Nova teams, that summary will follow.
Here are my notes from Friday afternoon's Nova session, line numbers are in the Nova etherpad as of writing this * Y: vcpu models (begins line 872): (patch 0012, more?) cfriesen to write a spec for listing CPU models in nova.conf * Y: read-only API additions (line 893): (part of patch 0024, others?) one spec and one microversion will cover the additional bits reported in server show returns (GET /servers) * N: non-default quotas (line 907): this is changed in the transition to unified limits in Keystone, can be handled in client libs * Y: I/O semaphore (line 910): (first part of patch 0015) new config option to limit concurrent high-IOPS operations * Y: Flavor extra spec and image validation (line 919): (patch 0022) validate the bits that are not virt driver-specific * Y: periodic orphan resource cleanup (line 927): (patch 0018) add a name check for configured prefixes marked as deleted in database, kill if still running * N: libvirt reboot timeout (line 936): (patch 0020) maybe document hard reboot alternative * N: compute node latency/power mgmt (line 941): new enough libvirt can do this? sean-k-mooney checking, preference to push this into hypervisor * Y: HPET (line 945): (patch 0068) no spec required, bp only; also implemented in cyborg * Y: NUMA-aware live migration (line 953): Artom will continue (spec https://review.openstack.org/#/c/599587/)
Python-Clients: items need to map to main project server-side disposition. Additionally, we agreed we should move the clients as close to master as possible, this can be done independently as this provides users backward compatibility.
More details: client libs, OpenStack SDK and OpenStackClient are all released independently from the main release cycle, although there are cycle stable branches maintained for co-installability/dependency issues. The major client changes are in areas that can be maintained separately from the upstream (OSC plugins, SDK-like addon libs), I would like to consider keeping the user-facing bits as close to current release (maybe not quite on master) as possible.
We made lots of updates to the google-spreadsheet in real time. [0]
I am going back through my notes to update Jira tickets to reflect the spreadsheet changes I made... dt -- Dean Troyer dtroyer@gmail.com