Mailing List Archive

Rob,

Thanks for this list.

As regards "Havana Keystone is not designated", does this mean that I can have an OpenStack(tm) cloud without having a Keystone compatible API ?

If it is just the requirement for API compatibility, should this not be that it has no designated code.

If it is actually not required, can the other components function fully without Keystone ? I would hope to be able to point a standard CLI such as nova at an OpenStack (tm) cloud and for it to work.

This may reflect that some clouds have alternative identity implementations but I am not aware if they are API compatible yet.

Tim

From: Rob_Hirschfeld@Dell.com [mailto:Rob_Hirschfeld@Dell.com]
Sent: 16 August 2014 22:28
To: foundation@lists.openstack.org
Subject: [OpenStack Foundation] DefCore Update on Designated Sections, please disccuss/+1

Board Members,

Note: if you'd like a quick DefCore review, please read http://robhirschfeld.com/2014/08/12/patchwork-onion/

Last week, the DefCore committee had an open meeting to create the initial strawman Design Sections. This strawman is intended as the basis for discussion leading up to an official DefCore recommendation at the September Board meeting. We are planning to have open community discussion meetings for this in a few weeks after reviewing with the TC and other leaders.

Before we do that, we felt that the Board should have a chance to +1 and discuss the recommendations. The recommendations are based on 10 principles (in the post script)

RECOMMENDATIONS:

* Havana Nova is by default designated except scheduler, filter, drivers, API extensions and networking.

* Havana Swift has no designated code due to lack of consensus (see principles)

* Havana Keystone is not designated.

* Havana Glance designated sections are the API implementation code and domain model.

* Havana Cinder designated sections are the API implementation code

* Havana Neutron has no designated sections.

* Havana Heat is not a core capability, no position at this time.

* Havana Horizon is not a core capability, no position at this time.

* other projects do not are not core capabilities and are not reviewed at this time.

10 PRINCIPLES POST SCRIPT:
Should be DESIGNATED:
1. code provides the project external REST API, or
2. code is shared and provides common functionality for all options, or
3. code implements logic that is critical for cross-platform operation
Should NOT be DESIGNATED:
4. code interfaces to vendor-specific functions, or
5. project design explicitly intended this section to be replaceable, or
6. code extends the project external REST API in a new or different way, or
7. code is being deprecated
8. UNdesignated by Default
? Unless code is designated, it is assumed to be undesignated.
? This aligns with the Apache license.
? We have a preference for smaller core.
9. Designated by Consensus
? If the community cannot reach a consensus about designation then it is considered undesignated.
? Time to reach consensus will be short: days, not months
? Except obvious trolling, this prevents endless wrangling.
? If there's a difference of opinion then the safe choice is undesignated.
10. Designated is Guidance
? Loose descriptions of designated sections are acceptable.
? The goal is guidance on where we want upstream contributions not a code inspection police state.
? Guidance will be revised per release as part of the DefCore process.



Rob
______________________________
Rob Hirschfeld
cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
Please note, I am based in the CENTRAL (-6) time zone

On 8/16/2014 5:30 PM, Rob_Hirschfeld@Dell.com<mailto:Rob_Hirschfeld@Dell.com> wrote:
Board Members,

Note: if you’d like a quick DefCore review, please read http://robhirschfeld.com/2014/08/12/patchwork-onion/

Last week, the DefCore committee had an open meeting to create the initial strawman Design Sections. This strawman is intended as the basis for discussion leading up to an official DefCore recommendation at the September Board meeting. We are planning to have open community discussion meetings for this in a few weeks after reviewing with the TC and other leaders.

Before we do that, we felt that the Board should have a chance to +1 and discuss the recommendations. The recommendations are based on 10 principles (in the post script)

RECOMMENDATIONS:

· Havana Nova is by default designated except scheduler, filter, drivers, API extensions and networking.

So, basically the REST API? I assume volume, networking and db fall under "drivers" The only other pieces are the conductor and cells.


· Havana Swift has no designated code due to lack of consensus (see principles)

· Havana Keystone is not designated.

· Havana Glance designated sections are the API implementation code and domain model.

· Havana Cinder designated sections are the API implementation code

API implementation code could be a little confusing. There's the code that implements the wsgi stack and then there's the code that implements the operations. I assume you mean the wsgi stack?


· Havana Neutron has no designated sections.

· Havana Heat is not a core capability, no position at this time.

· Havana Horizon is not a core capability, no position at this time.

· other projects do not are not core capabilities and are not reviewed at this time.

10 PRINCIPLES POST SCRIPT:
Should be DESIGNATED:
1. code provides the project external REST API, or

I'd like to see the API-level integration tests included with this. A REST API isn't much use unless we can ensure it's functionally comparable across drivers.

Unless these integration/compatibility tests are going to be handled by another external project? (which would be unfortunate)

2. code is shared and provides common functionality for all options, or
In the Nova case, I'm not sure what code this is referring to since everything else is non-designated.

Is it saying that there should be no single use-case code?

Tim Bell wrote:
> As regards “Havana Keystone is not designated”, does this mean that I
> can have an OpenStack™ cloud without having a Keystone compatible API ?

I think that would be a cloud "powered by OpenStack™".

> If it is just the requirement for API compatibility, should this not be
> that it has no designated code.
>
> If it is actually not required, can the other components function fully
> without Keystone ? I would hope to be able to point a standard CLI such
> as nova at an OpenStack™ cloud and for it to work.
>
> This may reflect that some clouds have alternative identity
> implementations but I am not aware if they are API compatible yet.

I think I agree with Tim -- keystone is a pretty critical component for
basic interoperability of OpenStack clouds. API compatibility sounds
like a bare minimum.

We should also proactively look at making Keystone code designated in
the future. I understand that some OpenStack companies do not run
Keystone -- if that's due to technical limitations, it would be good to
have a full account of those, so that we can make sure filling those
gaps in baked into Keystone future roadmap.

Cheers,

--
Thierry Carrez (ttx)

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On August 19, 2014 at 3:49:43 AM, Thierry Carrez (thierry@openstack.org<mailto:thierry@openstack.org>) wrote:
Tim Bell wrote:
> As regards “Havana Keystone is not designated”, does this mean that I
> can have an OpenStackâ„¢ cloud without having a Keystone compatible API ?

I think that would be a cloud "powered by OpenStackâ„¢".

That would be correct for the current Havana DefCore capabilities.


> If it is just the requirement for API compatibility, should this not be
> that it has no designated code.
>
> If it is actually not required, can the other components function fully
> without Keystone ? I would hope to be able to point a standard CLI such
> as nova at an OpenStackâ„¢ cloud and for it to work.
>
> This may reflect that some clouds have alternative identity
> implementations but I am not aware if they are API compatible yet.

I think I agree with Tim -- keystone is a pretty critical component for
basic interoperability of OpenStack clouds. API compatibility sounds
like a bare minimum.

This is clearly a big gap. I originally missed it because of the inclusion of the ‘compute-auth’ capability. But, I now see that is just validating that Compute properly uses auth information. The real issue is that there was no basic user auth capabilities identified during the development of the Havana criteria. I did some digging to try and understand why this is the case. As I retraced the steps that evolved, I think I understand what happened.

The capabilities were derived directly from a catalog of tests under the ‘api’ directory within tempest. If you look at the identity folder, it is all administrative capabilities that are tested - none of which would have made the cut for consideration. Looking only at that part of the project, you would be left wondering if we don’t actually test basic api functionality. Of course, we don’t completely miss testing basic identity functions. But, the method used to accomplish this is by testing the identity client in the ‘services’ folder within tempest - not with having a pure API level test.

I think the question is how to do move to rectify this in future version of capability identification and scoring. Do we use client interface tests as a proxy for API tests? In other words, should we require that a client library works against an OpenStack-powered cloud? or do we force the work to develop pure API level tests within the projects to serve as the validation for DefCore.

Perhaps this was discussed early on in the process, I don’t recall. But, we should make sure we put some clarity around it.


We should also proactively look at making Keystone code designated in
the future. I understand that some OpenStack companies do not run
Keystone -- if that's due to technical limitations, it would be good to
have a full account of those, so that we can make sure filling those
gaps in baked into Keystone future roadmap.

I think there is good progress there. Rackspace, for instance, plans to move to running Keystone code in production for the public cloud as the way to support Keystone V3. The teams have been engaging to work through scaling concerns, etc. Hopefully that is a sign that things are moving in the right direction.


Cheers,

--
Thierry Carrez (ttx)

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

>Tim Bell wrote: 
>> As regards “Havana Keystone is not designated”, does this mean that I 
>> can have an OpenStack™ cloud without having a Keystone compatible API ? 

>I think that would be a cloud "powered by OpenStack™". 
>That would be correct for the current Havana DefCore capabilities.

+1 - we're limited to the API tests that we have available

>> If it is just the requirement for API compatibility, should this not be 
>> that it has no designated code. 

It's good to have designated code BUT not a vendor requirement.

>> If it is actually not required, can the other components function fully 
>> without Keystone ? I would hope to be able to point a standard CLI such 
>> as nova at an OpenStack™ cloud and for it to work. 

We're limited to the available tests. In this case, we're testing Tempest by proxy.
Our goal is to encourage the community to expand coverage where there are
critical gaps.

> 
> This may reflect that some clouds have alternative identity 
> implementations but I am not aware if they are API compatible yet. 

> Perhaps this was discussed early on in the process, I don’t recall. But, we should make sure we put some clarity around it.

v3 had a lot of tests but did not make the cut because it was not stable in Havana.


> We should also proactively look at making Keystone code designated in 
> the future.

+1

> Rackspace, for instance, plans to move to running Keystone code in production for the public cloud as the way to support Keystone V3. The teams have been engaging to work through scaling concerns, etc. Hopefully that is a sign that things are moving in the right direction.

+1
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Tim - sorry for the slow response (inline). Great questions. The purpose of making Havana Advisory is to flush out these exact issues.

> As regards "Havana Keystone is not designated", does this mean that I can have an OpenStack(tm) cloud without having a Keystone compatible API ?

No. DefCore has Capabilities (API requirements) and Designated Code. This is just the code part.

> If it is just the requirement for API compatibility, should this not be that it has no designated code.

I'm not sure with the double negative. If there is no designated code, then those capabilities are API only. That could change over the course of several releases as the project matures.

> If it is actually not required, can the other components function fully without Keystone ? I would hope to be able to point a standard CLI such as nova at an OpenStack (tm) cloud and for it to work.

There was a thread about this. Apparently we have a Keystone v2 API test gap. Unfortunately, we're limited by the tests that are available and we'll have to test Keystone by inference.

> This may reflect that some clouds have alternative identity implementations but I am not aware if they are API compatible yet.

Without tests, it's impossible to tell. Since we know that clouds have alternative implementations, it would create a problem to require them to implement the code.


_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation