[Starlingx-discuss] FW: PTG upstreaming discussion

[Dean Troyer]

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 at gmail.com