Open Stack

The v3 experimental jobs are available for tempest [0]:
      - check-tempest-dsvm-keystonev3-full
      - check-tempest-dsvm-neutron-keystonev3-ful

At the moment the difference between these and the regular jobs are that
what has been implemented in this bp [1]:
- tempest works with v3 credentials, which include domain_id - atm
configured to "Default"
- all tokens used by the API tests are v3 tokens

The intention for these experimental jobs is to have services eventually
using v3 tokens as well - the spec is available here [2].

As soon as v3 token becomes available in the auth middleware used by the
various services, I'd like to enable it in the v3 jobs, until we have dsvm
jobs running with v3 alone.

andrea

[0]
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n2260
[1]
https://github.com/openstack/qa-specs/blob/master/specs/multi-keystone-api-version-tests.rst
[2]
https://github.com/openstack/qa-specs/blob/master/specs/keystone-v3-jobs.rst



On 22 July 2014 19:28, Joe Gordon <joe.gordon0 at gmail.com> wrote:

>
>
>
> On Thu, Jul 17, 2014 at 11:12 AM, Morgan Fainberg <
> morgan.fainberg at gmail.com> wrote:
>
>>
>>
>> > > I wasn't aware that PKI tokens had domains in them. What happens to
>> nova
>> > > in this case, It just works?
>> > >
>> >
>> > Both PKI and UUID responses from v3 contain:
>> >
>> > 1. the user's domain
>> >
>> > And if it's a project scoped token:
>> >
>> > 2. the project's domain
>> >
>> > Or if it's a domain-scoped token:
>> >
>> > 3. a domain scope
>> >
>> > The answer to your question is that if nova receives a project-scoped
>> token
>> > (1 & 2), it doesn't need to be domain-aware: project ID's are globally
>> > unique and nova doesn't need to know about project-domain relationships.
>> >
>> > If nova receives a domain-scoped token (1 & 3), the policy layer can
>> balk
>> > with an HTTP 401 because there's no project in scope, and it's not
>> > domain-aware. From nova's perspective, this is identical to the scenario
>> > where the policy layer returns an HTTP 401 because nova was presented
>> with
>> > an unscoped token (1 only) from keystone.
>>
>> Let me add some specifics based upon the IRC discussion I had with Joe
>> Gordon.
>>
>> In addition to what Dolph has outlined here we have this document
>> http://docs.openstack.org/developer/keystone/http-api.html#how-do-i-migrate-from-v2-0-to-v3
>> that should help with what is needed to do the conversion. The change to
>> use v3 largely relies on a deployer enabling the V3 API in Keystone.
>>
>> By and large, the change is all in the middleware. The middleware will
>> handle either token, so it really comes down to when a V3 token is
>> requested by the end user and subsequently used to interact with the
>> various OpenStack services. This part requires no change on Nova (or any
>> other services) part (with exception to the Domain-Scoped tokens outlined
>> above and the needed changes to policy if those are to be supported).
>>
>> Each of the client libraries will need to be updated to utilize the V3
>> API. This has been in process for a while (you’ve seen the code from Jamie
>> Lennox and Guang Yee) and is mostly supported by converting each of the
>> libraries to utilize the Session object from keystoneclient instead of the
>> many various implementations to talk to auth.
>>
>> Last but not least here are a couple bullet points that make V3 much
>> better than the V2 Keystone API (all the details of what V3 brings to the
>> table can be found here:
>> https://github.com/openstack/identity-api/tree/master/v3/src/markdown ).
>> A lot of these benefits are operator specific.
>>
>> * Federated Identity. V3 Keystone supports the use of SAML (via
>> shibboleth) from a number of sources as a form of Identity (instead of
>> having to keep the users all within Keystone’s Identity backend). The
>> federation support relies heavily upon the domain constructs in Keystone
>> (which are part of V3). There is work to expand the support beyond SAML
>> (including a proposal to support keystone-to-keystone federation).
>>
>> * Pluggable Auth. V3 Keystone supports pluggable authentication
>> mechanisms (a light weight module that can authenticate the user), this is
>> a bit more friendly than needing to subclass the entire Identity backend
>> with a  bunch of conditional logic. Plugins are configured via the Keystone
>> configuration file.
>>
>> * Better admin-scoping support. Domains allow us to better handle “admin”
>> vs “non-admin” and limit bleeding those roles across projects (a big
>> complaint in v2: you were either an admin or not an admin globally). Due to
>> backwards compatibility requirements, we have largely left this as it was,
>> but the support is there and can be seen via the policy.v3cloudsample.json
>> file provided in the Keystone tree.
>>
>> * The hierarchical multi tenancy work is being done against the V3
>> Keystone API. This is again related to the domain construct and support.
>> This will likely require changes to more than just Keystone to make full
>> use of the new functionality, but specifics are still up in the air as this
>> is under active development.
>>
>> These are just some of benefits of V3, there are a lot of improvements
>> over V2 that are not on this list (or are truly transparent to the end-user
>> and deployer).
>>
>
> Thanks for the clarifications! Sounds like getting full Keystone V3
> support by default is doable in Juno.
>
>
>>
>>
>> Cheers,
>> Morgan Fainberg
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140722/dcc3b9a4/attachment.html>