Open Stack

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.

Adrian