Open Stack

On 03/26/2015 01:15 PM, Adrian Otto wrote:
> Rob,
> 
> On Mar 26, 2015, at 10:01 AM, Rob Hirschfeld <rob at rackn.com> wrote:
> 
>> On 03/26/2015 08:17 AM, Chris Hoge wrote:
>>> This also overlaps a bit with versioned apis. Right now in
>>> Keystone we’re in the transition from v2 to v3, and being able to
>>> have a decision on the required version or allowing an ‘or’ on
>>> the versions will need to be addressed.
>> I'm less enthusiastic about having two versions of the same thing
>> in the spec.  From an OpenStack user, I consider that Nova and
>> Nova-Net are different components (some may disagree, of course).
> 
> I do agree that Nova and Nova-Net are different components. I
> disagree with your expressed sentiment about resisting a permissive
> requirement that would allow for a previous version of a component
> that is in a state of transition. We need to apply an approach of
> criteria that is sensitive sensibility to the speed at which
> OpenStack Clouds can reasonably evolve at in order to maintain
> compliance.
> 
> Ideally we should be able to reach an agreement about a capability
> that could be expressed using something like:
> 
> keystone_version => 2
> 
> We can adjust that expected compliance value to a higher one when we
> have confidence that OpenStack Cloud operators can actually meet the
> desired requirement value. Using a simple OR is less attractive
> because every requirement wold need to be re-evaluated every time
> there is a new version of a capability. Using a lower boundary is a
> common solution to this problem.

Sorry - I should have replied to this one instead ...

We should not express keystone_version => 2 . We should describe the
capability that needs to be there. If the keystone v3 api removes the
ability to do something that the v2 was doing or introduces an
incompatibility that is not accounted for, then we should not accept v3
api features until the keystone team has fixed that.

This may mean we have to be conservative about accepting as core
capabilities things that we know are in a state of flux - but that is as
it should be. We do not NEED to accept more capabilities into the
definition if those capabilities are going to lead to us immediately
lying to our users.