Open Stack

On 06/15/2016 12:14 AM, Mark Voelker wrote:
<snip>
> 
> It is perhaps important to note here that the DefCore seems to have two meanings to a lot of people I talk to today: it’s a mark of interoperability (the OpenStack Powered badge that says certain capabilities of this cloud behave like other clouds bearing the mark) and it gives a cloud the ability to call itself OpenStack (e.g. you can get a trademark/logo license agreement from the Foundation).  
> 
> The OpenStack Powered program currently covers Icehouse through Mitaka.  Right now, that includes releases that were still on the Nova 2.0 API.  API extensions were a supported thing [1] back in 2.0 and it was even explicitly documented that they allowed for additional attributes in the responses and “vendor specific niche functionality [1]”.  The change to the Tempest tests [2] applied to the 2.0 API as well as 2.1 with the intent of preventing further changes from getting into the 2.0 API at the gate, which totally makes sense as a gate test.  If those same tests are used for DefCore purposes, it does change what vendors need to do to be compliant with the Guidelines rather immediately--even on older releases of OpenStack using 2.0, which could be problematic (as noted elsewhere already [3]).

Right, that's fair. And part of why I think the pass* makes sense.
Liberty is the introduction of microversions on by default for clouds
from Nova upstream configs.

> So, through the interoperability lens: I think many folks acknowledge that supporting extensions lead to a lot of variance between clouds, and that was Not So Awesome for interoperability.  IIRC part of the rationale for switching to microversions with a single monotonic counter and deprecating extensions [4] was to set a course for eliminating a lot of that behavioral variance.
> 
> From the “ability to call yourself OpenStack” lens: it feels sort of wrong to tell a cloud that it can’t claim to be OpenStack because it’s running a version that falls within the bounds of the Powered program with the 2.0 API (when extensions weren't deprecated) and using the extension mechanism that 2.0 supported for years.

To be clear, extensions weren't a part of the 2.0 API, they were a part
of the infrastructure. It's a subtle but different point. Nova still
supports the 2.0 API, but on different infrastructure, which
doesn't/won't support extensions.

Are people registering new Kilo (or earlier) clouds in the system today?
By the time folks get to Newton, none of that is going to work anyway in
code.

In an ideal world product teams would be close enough to upstream code
and changes to see all this coming and be on top of it. In the real
world, a lot of these teams are like a year (or more) behind, which
actually makes Defcore with a pass* an ideal alternative communication
channel to express that products are coming up to a cliff, and should
start working on plans now.

> I think that’s part of what makes this issue tricky for a lot of folks.
> 
> [1] http://docs.openstack.org/developer/nova/v2/extensions.html

It's an unfortunate accident of bugs in our publishing system that that
URL still exists. That was deleted in Oct 2015. I'll look at getting it
properly cleaned up.

	-Sean

-- 
Sean Dague
http://dague.net