Open Stack

On August 19, 2014 at 3:49:43 AM, Thierry Carrez (thierry at openstack.org<mailto:thierry at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140820/b9e52fc2/attachment.html>