Re: [openstack-dev] [nova] Queens PTG recap - everything else

[Matt Riedemann]

On 9/19/2017 7:52 AM, Belmiro Moreira wrote:

I didn't find any mention to nested quotas.
Was it discussed in the PTG? and what can we expect for Queens?


There is no one driving the unified limits work [1] so nested quotas is 
stalled and we didn't spend any time discussing it at the PTG.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121944.html


--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova] Queens PTG recap - everything else

[Belmiro Moreira]

Hi Matt,
thanks for these great summaries.

I didn't find any mention to nested quotas.
Was it discussed in the PTG? and what can we expect for Queens?

thanks,
Belmiro
CERN

On Mon, Sep 18, 2017 at 11:58 PM, Matt Riedemann 
wrote:

> There was a whole lot of other stuff discussed at the PTG. The details are
> in [1]. I won't go into everything here, so I'm just highlighting some of
> the more concrete items that had owners or TODOs.
>
> Ironic
> --
>
> The Ironic team came over on Wednesday afternoon. We talked a bit, had
> some laughs, it was a good time. Since I don't speak fluent baremetal,
> Dmitry Tantsur is going to recap those discussions in the mailing list.
> Thanks again, Dmitry.
>
> Privsep
> ---
>
> Michael Still has been going hog wild converting the nova libvirt driver
> code to use privsep instead of rootwrap. He has a series of changes tracked
> under this blueprint [2]. Most of the discussion was a refresh on privsep
> and a recap of what's already been merged and some discussion on
> outstanding patches. The goal for Queens is to get the entire libvirt
> driver converted and also try to get all of nova-compute converted, but we
> want to limit that to getting things merged early in the release to flush
> out bugs since a lot of these are weird, possibly untested code paths.
> There was also discussion of a kind of privsep heartbeat daemon to tell if
> it's running (even though it's not a separate service) but this is
> complicated and is not something we'll pursue for Queens.
>
> Websockify security proxy framework
> ---
>
> This is a long-standing security hardening feature [3] which has changed
> hands a few times and hasn't gotten much review. Sean Dague and Melanie
> Witt agreed to focus on reviewing this for Queens.
>
> Certificate validation
> --
>
> This is another item that's been discussed since at least the Ocata summit
> but hasn't made much progress. Sean Dague agreed to help review this, and
> Eric Fried said he knew someone that could help review the security aspects
> of this change. Sean also suggested scheduling a hangout so the John
> Hopkins University team working on this can give a primer on the feature
> and what to look out for during review. We also suggested getting a
> scenario test written for this in the barbican tempest plugin, which runs
> as an experimental queue job for nova.
>
> Notifications
> -
>
> Given the state of the Searchlight project and how we don't plan on using
> Searchlight as a global proxy for the compute REST API, we are not going to
> work on parity with versioned notifications there. There are some cleanups
> we still need to do in Nova for versioned notifications from a performance
> perspective. We also agreed that we aren't going to consider deprecating
> legacy unversioned notifications until we have parity with the versioned
> notifications, especially given legacy unversioned notification consumers
> have not yet moved to using the versioned notifications.
>
> vGPU support
> 
>
> This depends on nested resource providers (like lots of other things). It
> was not clear from the discussion if this is static or dynamic support,
> e.g. can we hot plug vGPUs using Cyborg? I assume we will not support hot
> plugging at first. We also need improved functional testing of this space
> before we can make big changes.
>
> Preemptible (spot) instances
> -
>
> This was continuing the discussion from the Boston forum session [5]. The
> major issue in Nova is that we don't want Nova to be in charge of
> orchestrating preempting instances when a request comes in for a "paid"
> instance. We agreed to start small where you can't burst over quota. Blazar
> also delivered some reservation features in Pike [6] which sound like they
> can be built on here, which also sound like expiration policies. Someone
> will have to prototype an external (to nova) "reaper" which will cull the
> preemptible instances based on some configurable policy. Honestly the notes
> here are confusing so we're going to need someone to drive this forward.
> That might mean picking up John Garbutt's draft spec for this (link not
> available right now).
>
> Driver updates
> --
>
> Various teams from IBM gave updates on plans for their drivers in Queens.
>
> PowerVM (in tree): the team is proposing a few more capabilities to the
> driver in Queens. Details are in the spec [7].
>
> zDPM (out of tree): this out of tree driver has had two releases (ocata
> and pike) and is working on 3rd party CI. One issue they have with Tempest
> is they can only boot from volume.
>
> zVM (out of tree): the team is working on refactoring some code into a
> library, similar to os-xenapi, os-powervm and oslo.vmware. They have CI
> running but are not yet reporting against nova changes.
>
> Endpoint discovery
> --
>
> This is carry-over work 

[openstack-dev] [nova] Queens PTG recap - everything else

[Matt Riedemann]

There was a whole lot of other stuff discussed at the PTG. The details 
are in [1]. I won't go into everything here, so I'm just highlighting 
some of the more concrete items that had owners or TODOs.


Ironic
--

The Ironic team came over on Wednesday afternoon. We talked a bit, had 
some laughs, it was a good time. Since I don't speak fluent baremetal, 
Dmitry Tantsur is going to recap those discussions in the mailing list. 
Thanks again, Dmitry.


Privsep
---

Michael Still has been going hog wild converting the nova libvirt driver 
code to use privsep instead of rootwrap. He has a series of changes 
tracked under this blueprint [2]. Most of the discussion was a refresh 
on privsep and a recap of what's already been merged and some discussion 
on outstanding patches. The goal for Queens is to get the entire libvirt 
driver converted and also try to get all of nova-compute converted, but 
we want to limit that to getting things merged early in the release to 
flush out bugs since a lot of these are weird, possibly untested code 
paths. There was also discussion of a kind of privsep heartbeat daemon 
to tell if it's running (even though it's not a separate service) but 
this is complicated and is not something we'll pursue for Queens.


Websockify security proxy framework
---

This is a long-standing security hardening feature [3] which has changed 
hands a few times and hasn't gotten much review. Sean Dague and Melanie 
Witt agreed to focus on reviewing this for Queens.


Certificate validation
--

This is another item that's been discussed since at least the Ocata 
summit but hasn't made much progress. Sean Dague agreed to help review 
this, and Eric Fried said he knew someone that could help review the 
security aspects of this change. Sean also suggested scheduling a 
hangout so the John Hopkins University team working on this can give a 
primer on the feature and what to look out for during review. We also 
suggested getting a scenario test written for this in the barbican 
tempest plugin, which runs as an experimental queue job for nova.


Notifications
-

Given the state of the Searchlight project and how we don't plan on 
using Searchlight as a global proxy for the compute REST API, we are not 
going to work on parity with versioned notifications there. There are 
some cleanups we still need to do in Nova for versioned notifications 
from a performance perspective. We also agreed that we aren't going to 
consider deprecating legacy unversioned notifications until we have 
parity with the versioned notifications, especially given legacy 
unversioned notification consumers have not yet moved to using the 
versioned notifications.


vGPU support


This depends on nested resource providers (like lots of other things). 
It was not clear from the discussion if this is static or dynamic 
support, e.g. can we hot plug vGPUs using Cyborg? I assume we will not 
support hot plugging at first. We also need improved functional testing 
of this space before we can make big changes.


Preemptible (spot) instances
-

This was continuing the discussion from the Boston forum session [5]. 
The major issue in Nova is that we don't want Nova to be in charge of 
orchestrating preempting instances when a request comes in for a "paid" 
instance. We agreed to start small where you can't burst over quota. 
Blazar also delivered some reservation features in Pike [6] which sound 
like they can be built on here, which also sound like expiration 
policies. Someone will have to prototype an external (to nova) "reaper" 
which will cull the preemptible instances based on some configurable 
policy. Honestly the notes here are confusing so we're going to need 
someone to drive this forward. That might mean picking up John Garbutt's 
draft spec for this (link not available right now).


Driver updates
--

Various teams from IBM gave updates on plans for their drivers in Queens.

PowerVM (in tree): the team is proposing a few more capabilities to the 
driver in Queens. Details are in the spec [7].


zDPM (out of tree): this out of tree driver has had two releases (ocata 
and pike) and is working on 3rd party CI. One issue they have with 
Tempest is they can only boot from volume.


zVM (out of tree): the team is working on refactoring some code into a 
library, similar to os-xenapi, os-powervm and oslo.vmware. They have CI 
running but are not yet reporting against nova changes.


Endpoint discovery
--

This is carry-over work from Ocata and Pike to standardize how Nova does 
endpoint discovery with other services, like 
keystone/placement/cinder/glance/neutron/ironic/barbican. The spec is 
here [8]. The dependent keystoneauth1 changes were released in Pike so 
we should be able to make quick progress on this early in Queens to 
flush out bugs.


Documentation
-

We talked about the