Open Stack

On Thursday afternoon at the PTG we talked about various API-related 
topics. The full etherpad is here [1]. These are the highlights.

Policy
------

There was a separate etherpad for this [2]. We talked through a few 
proposals that John Garbutt has for dealing with policy in nova. One was 
for simply documenting the various policies so that you get a 
description of the policy and what API path(s) it touches. There are a 
couple of other specs in [2] dealing with fixing the misuse of the 
admin_or_owner role and another spec proposing to add more granular 
roles and make them the defaults. During the session there was mostly 
some discussion about the ideas and those will be fed back into the 
specs. If you're an operator that hates dealing with policy, you should 
read those specs.

Deploy nova-api under WSGI
--------------------------

It's been possible to run nova-api under WSGI for several releases now 
but it's always been considered experimental by the Nova team and in 
Ocata we found out that there is actually a pretty serious bug [3] when 
running that way which affects how Nova deals with rolling upgrades. 
Since running the APIs under WSGI is a cross-project goal for Pike, we 
talked a bit about the plan to make this happen, which involves fixing 
that bug and deploying nova-api under httpd in the 
gate-tempest-dsvm-neutron-nova-next-full-ubuntu-xenial-nv job. EmilienM 
was already looking at making nova-api run under apache in devstack. 
There were also some wrinkles that have to be sorted out when fixing the 
bug, and sdague and cdent said they'd work on fixing that. Finally we 
talked about when we can drop support for running nova-api with 
eventlet, and thought that if we can get the wsgi support in early 
enough in Pike, we can deprecate running nova-api under eventlet in Pike 
and plan to remove that support in the R release.

Deprecating file injection
--------------------------

We talked about an older thread I brought up in Ocata [4] related to the 
issues with "personality" files in the compute API and agreed to:

(1) Drop the VFSLocalFS fallback for libvirt when guestfs isn't 
available. There will not be a deprecation period for this as it was a 
hack for older ubuntu versions anyway and is a known security issue. 
Sean Dague is working on this.
(2) Deprecate personality files from the compute API with a 
microversion. We'll continue to honor personality files in the API 
before the deprecation microversion. I'll be working on this.

We also made a note to reach out to people that were interested in using 
dynamic vendordata [5]. I did that and the feedback has been positive, 
which further supports deprecating file injection and hooks.

Return instance flavor in server body
-------------------------------------

We talked about a spec [6] which proposes to return the flavor 
information used to create a server as part of the server GET response 
body, since the original flavor used to create the instance could have 
been deleted or changed so getting that information via the flavors API 
later may not be accurate. There was some debate about the flavor info 
to return (like id or name) which was settled, at least for now, and 
those updates are being made in the spec which Chris Friesen is now driving.

API improvements for cold migration
-----------------------------------

Takashi Natsume brought up some previously approved specs related to 
being able to list/show cold migrations for a server, force the host for 
a cold migration and abort an in-progress cold migration. There was 
general agreement on doing these but the abort cold migration spec 
needed to be updated a bit to be less libvirt-specific since we expect 
other virt drivers should be able to implement that one.

Add scheduler hints to the server GET response
----------------------------------------------

This was proposed by Balaizs Gibizer (gibi) and is the same idea as the 
flavors one above. It would be useful to expose the original scheduler 
hints used when creating a server so that another server could be 
created with the same scheduler hints. The action on this item was gibi 
needs to write a spec but there was general agreement it seemed OK.

Service-locked servers
----------------------

This was a short discussion about a feature that projects that use 
service instances, like Trove, would like to have, where the service 
(trove in this case) has a lock on a server in Nova and only the service 
(or the admin) can perform actions on the server. John Garbutt was going 
to write up a nova spec for this, and Amrith Kumar was going to write up 
a Trove spec for using the Nova feature.

[1] https://etherpad.openstack.org/p/nova-ptg-pike-api
[2] https://etherpad.openstack.org/p/pike-ptg-keystone-policy
[3] https://bugs.launchpad.net/nova/+bug/1661360
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107195.html
[5] https://docs.openstack.org/developer/nova/vendordata.html
[6] https://review.openstack.org/#/c/265282

-- 

Thanks,

Matt Riedemann