Open Stack

On 05/04/16 17:49 -0400, Nikhil Komawar wrote:
>
>I think in the interest of supporting the OSC effort, I am with
>deprecating the CLI stuff (possibly glanceclient too -- BUT in a
>different thread).
>
>I believe removing the bindings/modules that support possibly OSC and
>other libs might be lot trickier. (nova proxy stuff for glance may be an
>exception but I don't know all the libs that use it).
>
>And on Matt's question of glanceclient supporting image-meta stuff,
>Glance and in turn glanceclient should be a superset of the Images API
>that Nova and other services support. If that's not the case, then we've
>a DefCore problem but AFAIK, it's not.
>
>On the note of adding / removing support for Glance v2 API and proxy
>jazz in Nova:: Last time I'd a discussion with johnthetubaguy and we
>agreed that the proxy API won't change for Nova (the changes needed for
>the Glance v2 adoption would ensure the proxy API remains same) also,
>the purpose of Glance v2 adoption (in Nova and everywhere else) is to
>promote the "right" public facing Glance API (which is in development &
>supposed to be v2).
>
>I'm glad we're chatting about deprecating the Nova proxy API proactively
>but I think we should not tie it (or get confused that it's tied with)
>the Nova's adoption of Glance v2 API.

Right!

There's been a lot of effort in not breaking Nova's Image proxy. I'd love to see
it burn on the ground till there's nothing left of it but removing it is
probably going t ocause more harm than good right now.

The changes that Mike proposed will make it possible to use Glance V2 and still
keep the image proxy as-is so that it can be deprecated following the right
deprecation path without blocking Nova's migration to V2.

So, to answer Matt's question directly. I'd remove those CLI commands only as
part of the migration to OSC but not as a motivation for the image proxy to go
away. Nova could add a warning on those CLI commands to let users know they
should use OSC for that and that they are talking to an old, likely broken, API.

Nova's adoption of Glance's V2 should not be tied to the CLI/Image Proxy
deprecation.

Flavio

>Yours sincerely!
>
>On 4/5/16 5:30 PM, Michael Still wrote:
>> On Wed, Apr 6, 2016 at 7:28 AM, Ian Cordasco <sigmavirus24 at gmail.com
>> <mailto:sigmavirus24 at gmail.com>> wrote:
>>
>>
>>
>>
>>
>>     -----Original Message-----
>>
>>     From: Michael Still <mikal at stillhq.com <mailto:mikal at stillhq.com>>
>>
>>     Reply: OpenStack Development Mailing List (not for usage
>>     questions) <openstack-dev at lists.openstack.org
>>     <mailto:openstack-dev at lists.openstack.org>>
>>
>>     Date: April 5, 2016 at 16:11:05
>>
>>     To: OpenStack Development Mailing List (not for usage questions)
>>     <openstack-dev at lists.openstack.org
>>     <mailto:openstack-dev at lists.openstack.org>>
>>
>>     Subject:  Re: [openstack-dev] [nova][glance] Proposal to remove
>>     `nova image-*` commands from novaclient
>>
>>
>>
>>     > As a recent newcomer to using our client libraries, my only real
>>     objection
>>
>>     > to this plan is that our client libraries as a mess [1][2]. The
>>     interfaces
>>
>>     > we expect users to use are quite different for basic things like
>>     initial
>>
>>     > auth between the various clients, and by introducing another
>>     library we
>>
>>     > insist people use we're going to force a lot of devs to
>>     eventually go
>>
>>     > through having to understand how those other people did that thing.
>>
>>     >
>>
>>     > I guess I could ease my concerns here if we could agree to some
>>     sort of
>>
>>     > standard for what auth in a client library looks like...
>>
>>     >
>>
>>     > Some examples of auth at the moment:
>>
>>     >
>>
>>     > self.glance = glance_client.Client('2', endpoint, token=token)
>>
>>     > self.ironic = ironic_client.get_client(1, ironic_url=endpoint,
>>
>>     > os_auth_token=token)
>>
>>     > self.nova = nova_client.Client('2', bypass_url=endpoint,
>>     auth_token=token)
>>
>>     >
>>
>>     > Note how we can't decide if the version number is a string or an
>>     int, and
>>
>>     > the argument names for the endpoint and token are different in
>>     all three.
>>
>>     > Its like we're _trying_ to make this hard.
>>
>>     >
>>
>>     > Michael
>>
>>     >
>>
>>     > 1: I guess I might be doing it wrong, but in that case I'll just
>>     mutter
>>
>>     > about the API docs instead.
>>
>>     > 2: I haven't looked at the unified openstack client library to
>>     see if its
>>
>>     > less crazy.
>>
>>     >
>>
>>
>>
>>     What if we just recommend everyone use the openstacksdk
>>     (https://pypi.python.org/pypi/openstacksdk)? We could add more
>>     developer resources by deprecating our individual client libraries
>>     to use that instead? It's consistent and well-designed and would
>>     probably benefit from us actively helping with each service's portion.
>>
>>
>> So like I said, I haven't looked at it at all because I am middle
>> aged, stuck in my ways, hate freedom, and because I didn't think of it.
>>
>> Does it include a command line interface that's not crazy as well?
>>
>> If so, why are we maintaining duplicate sets of libraries / clients?
>> It seems like a lot of wasted effort.
>>
>> Michael
>>
>> --
>> Rackspace Australia
>>
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>-- 
>
>Thanks,
>Nikhil
>
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/058974d3/attachment.pgp>