Open Stack

2014-04-03 7:12 GMT+08:00 Jamie Lennox <jamielennox at redhat.com>:

>
>
> ----- Original Message -----
> > From: "Adam Young" <ayoung at redhat.com>
> > To: openstack-dev at lists.openstack.org
> > Sent: Wednesday, 2 April, 2014 11:13:22 PM
> > Subject: Re: [openstack-dev] [Keystone] python-keystoneclient v3
>  functionality
> >
> > On 04/01/2014 07:36 AM, Yaguang Tang wrote:
> >
> >
> >
> > Thanks Jamie,
> >
> > then the following question is do we intend to move other services client
> > library V3 identity support to python-openstackclient?
> > AFAIK it's poorly supported for Nova Cinder Neutron client library, and
> I am
> > working on add v3 support for those libraries[1], just
> > want to make sure that is the correct direction.
> >
> > [1] https://review.openstack.org/#/c/81749/
> > https://review.openstack.org/#/c/81767/
> >
> >
> > Sort of. The Keystone client should be responsible for all fo the service
> > catalog manipulations throughout openstack. So the Cinder client should
> use
> > the Keystone client.
> >
> > To see the idea, read Jamie's blog post:
> >
> > http://www.jamielennox.net/blog/2014/02/24/client-session-objects/
> >
> > The main idea is that Keystone will handle the HTTP session setup, so
> that we
> > have a single place to focus attention on for HTTP network security
> issues.
> > And you should not need to parse the service catalog at all.
> >
> >
>
> So Adam is right in that the general idea to transition people to using
> the V3 API will be to use the keystoneclient.session.Session object and
> that will do everything for you. This is not going to be an easy transition
> for everyone and i've got a summit session proposed:
> http://summit.openstack.org/cfp/details/205 in which i want to deal with
> precisely this problem.
>
> Regarding your notion of openstackclient though, you need to seperate the
> concept of a CLI and the library.
>
> Take for example Heat or Horizon, they communicate with keystone through
> the python-keystoneclient and nova via the python-novaclient etc. They do
> not use the keystone or nova cli utility. The primary job of the
> python-*client libraries is NOT to provide a cli. The cli is just an
> application that makes use of the library.
>

  Yeah, but when we talking about the support of v3 for Nova Cinder and
Neutron. I think it's mostly about the auth token middleware and CLI
support of the client library.

>
> So yes, i think it has generally been accepted that the clients will move
> (at there own pace) to using openstackclient for there CLI, but
> openstackclient will still rely on the various libraries to do the actual
> communication with services
>

   I wonder is it worth to enable v3 for CLI when we moving to
openstackclient  so that  OpenStack users and operators can test and
evaluate v3 API , and we may probably add a v3 test gate to CI. what we
face is that   user can use v3 API with novaclient CLI, this has been asked
many times in the OpenStack user mailing list.


>
>
> Jamie
>
> >
> >
> > 2014-04-01 12:08 GMT+08:00 Jamie Lennox < jamielennox at redhat.com > :
> >
> >
> >
> > On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:
> > > Hi all,
> > >
> > >
> > > I am sorry if this has been discussed before, the question is will we
> > > support keystone v3 operation
> > > in python-keystoneclient? I know most of the v3 functionality have
> > > been implemented in python-openstackclient, but from the
> > > python-openstackclient wiki says, it's primarily a wrapper of
> > > python-*client, and provides unified interface to user. The end user
> > > uses python-keystoneclient to manage
> > > user, tenant, service before, if we don't intend to support v3
> > > functionality in keystoneclient, then
> > > it means we force end user to change from keystoneclient to
> > > openstackclient, is this what we want to
> > > do?
> > >
> >
> > It depends what you mean by python-keystoneclient.
> >
> > If you mean the python library then yes it supports the V3 API already.
> >
> > If you mean the keystone CLI that is currently bundled as part of the
> > python-keystoneclient then yes that is deprecated in favour of
> > python-openstackclient.
> >
> > We will maintain the CLI application in keystoneclient however even for
> > V2 API calls I recommend that you use the openstack CLI tool.
> >
> > Jamie
> >
> > >
> > > --
> > > Tang Yaguang
> > >
> > >
> > > Canonical Ltd. | www.ubuntu.com | www.canonical.com
> > > Mobile: +86 152 1094 6968
> > > gpg key: 0x187F664F
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
> > --
> > Tang Yaguang
> >
> > Canonical Ltd. | www.ubuntu.com | www.canonical.com
> > Mobile: +86 152 1094 6968
> > gpg key: 0x187F664F
> >
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Tang Yaguang

Canonical Ltd. | www.ubuntu.com | www.canonical.com
Mobile:  +86 152 1094 6968
gpg key: 0x187F664F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140403/76a68693/attachment.html>