Open Stack

On 9/27/2018 10:11 AM, Dean Troyer wrote:
> On Thu, Sep 27, 2018 at 9:06 AM, Doug Hellmann<doug at doughellmann.com>  wrote:
>> I definitely think having details about the gaps would be a prerequisite
>> for approving a goal, but I wonder if that's something 1 person could
>> even do alone. Is this an area where a small team is needed?
> Maybe, but it does break down along project/API lines for the most
> part, only crossing in places like Matt mentioned where compute+volume
> interact in server create, etc.
> 
> For the purposes of a goal, I think we need to be thinking more about
> structural things than specific command changes.  Things like Monty
> mentioned elsewhere in the thread about getting all of the exiting
> client libs to correctly use an SDK adapter then behaviours converge
> and the details of command changes become project-specific.
> 

Yeah I did the gap analysis for the compute API, you'd need each team 
doing that, for however they define "gaps". Not all projects use 
microversions, but they probably add new resources to the API so I'd 
consider that one way to identify gaps, e.g. can I list foo resources 
from service type bar?

Another thought I had about breaking this down into more digestable 
chunks, at least from a nova perspective, is looking at closing gaps on 
a smaller scale. Looking at the latest user survey analytics [1] the 
majority of deployments are running mitaka or newton. The max compute 
API microversion in mitaka was 2.25. Considering the gaps between 2.1 
and 2.25 [2] simply getting OSC compute API support up to mitaka levels 
would be an accomplishment. I don't know how well that would translate 
to other project teams, but it's an idea for how the nova team could 
help break down this work into a more realistic goal for a single release.

[1] https://www.openstack.org/analytics
[2] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc

-- 

Thanks,

Matt