Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Nikhil Komawar]

On 4/6/16 2:43 PM, Matt Riedemann wrote:
>
>
> On 4/6/2016 1:17 PM, Nikhil Komawar wrote:
>>
>>
>> On 4/6/16 2:09 PM, Clint Byrum wrote:
>>> Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700:
 Need a inline clarification.

 On 4/6/16 10:58 AM, Flavio Percoco wrote:
> On 06/04/16 08:26 -0400, Sean Dague wrote:
>> On 04/06/2016 04:13 AM, Markus Zoeller wrote:
>>> +1 for deprecation and removal
>>>
>>> To be honest, when I started with Nova during Kilo, I didn't get
>>> why we have those passthrough APIs. They looked like convenience
>>> APIs.
>>> A short history lesson, why they got introduced, would be cool.
>>> I only
>>> found commit [1] which looks like they were there from the
>>> beginning.
>>>
>>> References:
>>> [1]
>>> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33
>>>
>>>
>> The short history lesson is nova image API existed before glance.
>> Glance
>> was a spin out from Nova of that API. Doing so doesn't
>> immediately make
>> that API go away however. Especially as all these things live on
>> different ports with different end points. So the image API
>> remained as
>> a proxy (as did volumes, baremetal, and even to some extend
>> networks).
>>
>> It's not super clear how you deprecate and remove these things
>> without
>> breaking a lot of people, as a lot of the libraries implement the
>> nova
>> image resources -
>> https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb
>>
>>
> We can deprecate it without removing it. We make it work with v2 and
> start
> warning people that the API is not supported anymore. We don't fix
> bugs in that
> API but tell people to use the newer version.
>
> I think that should do it, unless I'm missing something.
> Flavio
>
 Is it a safe practice to not fix bugs on a publicly exposed API? What
 are the recommendations for such cases?

>>> I don't think you can make a blanket statement that no bugs will be
>>> fixed.
>>>
>>> There are going to be evolutions behind this API that make a small bug
>>> today into a big bug tomorrow. The idea is to push the user off the API
>>> when they try to do more with it, not when we forcibly explode their
>>> working code.
>>>
>>> "We don't break userspace". I know _we_ didn't say that about our
>>> project. But I like to think we understand the wisdom behind that,
>>> and can
>>> start at least pretending we believe in ourselves and our users enough
>>> to hold to it for some things, even if we don't really like some of the
>>> more dark and dingy corners of userspace that we have put out there.
>>
>> I see, so here's a more subjective idea of how we want to handle such
>> sensitive (being used for long time, important for some core operations,
>> etc) APIs and fix bugs on a case by case basis. We may be going in a
>> positive direction by reducing support but amount of work wise, I think
>> we can set expectations for developers as more process and less fixing.
>>
>>> __
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> This thread has gotten longer and more complicated than I expected.
>
> At a very basic level, we aren't going to (knowingly) break the nova
> images API if using glance v2 on the backend, that's where a
> translation layer has to come in as part of the glance v2 adoption.
>
> But the nova images API is feature frozen, meaning we aren't going to
> make it handle glance v2-like requests. The same is true for how we
> don't have volume-type support in the nova volume create API.
>
> So now that we can all agree that we aren't removing the nova images
> API and we aren't going to break it for glance v2 adoption, we can
> also agree that we don't want people using it.
>
> One of the entry points to using it is via the CLI and python API
> bindings in python-novaclient. Hence why I'm proposing that we
> deprecate and eventually remove those. That's not a dependency for
> glance v2 adoption in nova, it's just a parallel thing we should have
> already done awhile back.
>
> OK, I think that's it.
>
Thanks for the clarification and giving us a complete outline of the
plan. It makes sense.

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Nikhil Komawar]

On 4/6/16 2:09 PM, Clint Byrum wrote:
> Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700:
>> Need a inline clarification.
>>
>> On 4/6/16 10:58 AM, Flavio Percoco wrote:
>>> On 06/04/16 08:26 -0400, Sean Dague wrote:
 On 04/06/2016 04:13 AM, Markus Zoeller wrote:
> +1 for deprecation and removal
>
> To be honest, when I started with Nova during Kilo, I didn't get
> why we have those passthrough APIs. They looked like convenience APIs.
> A short history lesson, why they got introduced, would be cool. I only
> found commit [1] which looks like they were there from the beginning.
>
> References:
> [1]
> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33
>
 The short history lesson is nova image API existed before glance. Glance
 was a spin out from Nova of that API. Doing so doesn't immediately make
 that API go away however. Especially as all these things live on
 different ports with different end points. So the image API remained as
 a proxy (as did volumes, baremetal, and even to some extend networks).

 It's not super clear how you deprecate and remove these things without
 breaking a lot of people, as a lot of the libraries implement the nova
 image resources -
 https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb

>>> We can deprecate it without removing it. We make it work with v2 and
>>> start
>>> warning people that the API is not supported anymore. We don't fix
>>> bugs in that
>>> API but tell people to use the newer version.
>>>
>>> I think that should do it, unless I'm missing something.
>>> Flavio
>>>
>> Is it a safe practice to not fix bugs on a publicly exposed API? What
>> are the recommendations for such cases?
>>
> I don't think you can make a blanket statement that no bugs will be
> fixed.
>
> There are going to be evolutions behind this API that make a small bug
> today into a big bug tomorrow. The idea is to push the user off the API
> when they try to do more with it, not when we forcibly explode their
> working code.
>
> "We don't break userspace". I know _we_ didn't say that about our
> project. But I like to think we understand the wisdom behind that, and can
> start at least pretending we believe in ourselves and our users enough
> to hold to it for some things, even if we don't really like some of the
> more dark and dingy corners of userspace that we have put out there.

I see, so here's a more subjective idea of how we want to handle such
sensitive (being used for long time, important for some core operations,
etc) APIs and fix bugs on a case by case basis. We may be going in a
positive direction by reducing support but amount of work wise, I think
we can set expectations for developers as more process and less fixing.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Clint Byrum]

Excerpts from Nikhil Komawar's message of 2016-04-06 10:46:28 -0700:
> Need a inline clarification.
> 
> On 4/6/16 10:58 AM, Flavio Percoco wrote:
> > On 06/04/16 08:26 -0400, Sean Dague wrote:
> >> On 04/06/2016 04:13 AM, Markus Zoeller wrote:
> >>> +1 for deprecation and removal
> >>>
> >>> To be honest, when I started with Nova during Kilo, I didn't get
> >>> why we have those passthrough APIs. They looked like convenience APIs.
> >>> A short history lesson, why they got introduced, would be cool. I only
> >>> found commit [1] which looks like they were there from the beginning.
> >>>
> >>> References:
> >>> [1]
> >>> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33
> >>>
> >>
> >> The short history lesson is nova image API existed before glance. Glance
> >> was a spin out from Nova of that API. Doing so doesn't immediately make
> >> that API go away however. Especially as all these things live on
> >> different ports with different end points. So the image API remained as
> >> a proxy (as did volumes, baremetal, and even to some extend networks).
> >>
> >> It's not super clear how you deprecate and remove these things without
> >> breaking a lot of people, as a lot of the libraries implement the nova
> >> image resources -
> >> https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb
> >>
> >
> > We can deprecate it without removing it. We make it work with v2 and
> > start
> > warning people that the API is not supported anymore. We don't fix
> > bugs in that
> > API but tell people to use the newer version.
> >
> > I think that should do it, unless I'm missing something.
> > Flavio
> >
> 
> Is it a safe practice to not fix bugs on a publicly exposed API? What
> are the recommendations for such cases?
> 

I don't think you can make a blanket statement that no bugs will be
fixed.

There are going to be evolutions behind this API that make a small bug
today into a big bug tomorrow. The idea is to push the user off the API
when they try to do more with it, not when we forcibly explode their
working code.

"We don't break userspace". I know _we_ didn't say that about our
project. But I like to think we understand the wisdom behind that, and can
start at least pretending we believe in ourselves and our users enough
to hold to it for some things, even if we don't really like some of the
more dark and dingy corners of userspace that we have put out there.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Nikhil Komawar]

Need a inline clarification.

On 4/6/16 10:58 AM, Flavio Percoco wrote:
> On 06/04/16 08:26 -0400, Sean Dague wrote:
>> On 04/06/2016 04:13 AM, Markus Zoeller wrote:
>>> +1 for deprecation and removal
>>>
>>> To be honest, when I started with Nova during Kilo, I didn't get
>>> why we have those passthrough APIs. They looked like convenience APIs.
>>> A short history lesson, why they got introduced, would be cool. I only
>>> found commit [1] which looks like they were there from the beginning.
>>>
>>> References:
>>> [1]
>>> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33
>>>
>>
>> The short history lesson is nova image API existed before glance. Glance
>> was a spin out from Nova of that API. Doing so doesn't immediately make
>> that API go away however. Especially as all these things live on
>> different ports with different end points. So the image API remained as
>> a proxy (as did volumes, baremetal, and even to some extend networks).
>>
>> It's not super clear how you deprecate and remove these things without
>> breaking a lot of people, as a lot of the libraries implement the nova
>> image resources -
>> https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb
>>
>
> We can deprecate it without removing it. We make it work with v2 and
> start
> warning people that the API is not supported anymore. We don't fix
> bugs in that
> API but tell people to use the newer version.
>
> I think that should do it, unless I'm missing something.
> Flavio
>

Is it a safe practice to not fix bugs on a publicly exposed API? What
are the recommendations for such cases?

>>
>> -Sean
>>
>> -- 
>> Sean Dague
>> http://dague.net
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Mathieu Gagné]

On Tue, Apr 5, 2016 at 11:24 PM, Monty Taylor  wrote:
> On 04/05/2016 05:07 PM, Michael Still wrote:
>
>> self.glance = glance_client.Client('2', endpoint, token=token)
>
>
> There are next to zero cases where the thing you want to do is talk to
> glance using a token and an endpoint.

I used to have a use case for that one. I'm only mentioning so you can
have a good laugh at it. =)

We have an internal development cloud where people can spawn a whole
private OpenStack infrastructure for testing and development purposes.
This means ~50 instances.
All instances communicate between them using example.org DNS, this
includes URLs found in the Keystone catalog.
Each stack has a private DNS server resolving those requests for
example.org and our internal tool configure it once the stack is
provisioned.
This means each developper has its own example.org zone which resolves
differently. They can configure their own local resolvers to use the
one found in the stack if they wish.

Now the very funny part:

Developers can decide to destroy their stack as they wish in brutal
ways. The side-effect we saw is that it left orphan volumes on our
shared block storage backend which also happens to have a maximum
number of volumes.
So to clean them up, we wrote a script that connects to each
developer's stack and try to list volumes in Cinder, compare them with
the ones found on the block storage backend and delete orphan ones.
Since everybody has the same example.org DNS in their catalog, we
needed a way to tell python-cinderclient to not use the DNS found in
the catalog but the actual IP of the developper's Cinder instance.
That's our use case where we needed the endpoint argument. =)

Good news, we found an alternative solution where we override the
Python socket resolving methods instead and override the IP from there
instead of using the endpoint argument.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Flavio Percoco]

On 06/04/16 08:26 -0400, Sean Dague wrote:

On 04/06/2016 04:13 AM, Markus Zoeller wrote:

+1 for deprecation and removal

To be honest, when I started with Nova during Kilo, I didn't get
why we have those passthrough APIs. They looked like convenience APIs.
A short history lesson, why they got introduced, would be cool. I only
found commit [1] which looks like they were there from the beginning.

References:
[1]
https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33


The short history lesson is nova image API existed before glance. Glance
was a spin out from Nova of that API. Doing so doesn't immediately make
that API go away however. Especially as all these things live on
different ports with different end points. So the image API remained as
a proxy (as did volumes, baremetal, and even to some extend networks).

It's not super clear how you deprecate and remove these things without
breaking a lot of people, as a lot of the libraries implement the nova
image resources -
https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb


We can deprecate it without removing it. We make it work with v2 and start
warning people that the API is not supported anymore. We don't fix bugs in that
API but tell people to use the newer version.

I think that should do it, unless I'm missing something.
Flavio



-Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Sean Dague]

On 04/06/2016 04:13 AM, Markus Zoeller wrote:
> +1 for deprecation and removal
> 
> To be honest, when I started with Nova during Kilo, I didn't get
> why we have those passthrough APIs. They looked like convenience APIs.
> A short history lesson, why they got introduced, would be cool. I only
> found commit [1] which looks like they were there from the beginning.
> 
> References:
> [1] 
> https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33

The short history lesson is nova image API existed before glance. Glance
was a spin out from Nova of that API. Doing so doesn't immediately make
that API go away however. Especially as all these things live on
different ports with different end points. So the image API remained as
a proxy (as did volumes, baremetal, and even to some extend networks).

It's not super clear how you deprecate and remove these things without
breaking a lot of people, as a lot of the libraries implement the nova
image resources -
https://github.com/fog/fog-openstack/blob/master/lib/fog/openstack/compute.rb


-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Flavio Percoco]

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 <sigmaviru...@gmail.com
<mailto:sigmaviru...@gmail.com>> wrote:





-Original Message-

From: Michael Still <mi...@stillhq.com <mailto:mi...@stillhq.com>>

Reply: OpenStack Development Mailing List (not for usage
questions) <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>

Date: April 5, 2016 at 16:11:05

To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@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

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Markus Zoeller]

"Steve Martinelli" <steve...@ca.ibm.com> wrote on 04/06/2016 06:45:42 AM:

> From: "Steve Martinelli" <steve...@ca.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)" 
> <openstack-dev@lists.openstack.org>
> Date: 04/06/2016 06:46 AM
> Subject: Re: [openstack-dev] [nova][glance] Proposal to remove `nova 
> image-*` commands from novaclient
> 
> +1000. Totally in favor of this, if anything it seems overdue, I'm a 
> bit surprised that they aren't already deprecated. Two alternatives 
> exist for the CLI (osc and glanceclient), and two alternatives exist 
> for python API bindings (SDK and glanceclient).
> 
> This should follow the same case with the nova volume-* commands, 
> deprecate for 2 releases [1] and then remove [2]. The deprecation 
> message can point users to OSC and glanceclient.
> 
> [1] https://github.com/openstack/python-novaclient/commit/
> 23f13437dd64496fcbc138bbaa9b0ac615a3cf23
> [2] https://github.com/openstack/python-novaclient/commit/
> a42570268915f42405ed0b0a67c25686b5db22ce
> 
> Thanks,
> 
> Steve Martinelli
> OpenStack Keystone Project Team Lead

+1 for deprecation and removal

To be honest, when I started with Nova during Kilo, I didn't get
why we have those passthrough APIs. They looked like convenience APIs.
A short history lesson, why they got introduced, would be cool. I only
found commit [1] which looks like they were there from the beginning.

References:
[1] 
https://github.com/openstack/python-novaclient/commit/7304ed80df265b3b11a0018a826ce2e38c052572#diff-56f10b3a40a197d5691da75c2b847d31R33

Regards, Markus Zoeller (markus_z)

> [image removed] Matt Riedemann ---2016/04/05 03:49:05 PM---As we 
> discuss the glance v2 spec for nova, questions are coming up around 
> what to do about the nova
> 
> From: Matt Riedemann <mrie...@linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 2016/04/05 03:49 PM
> Subject: [openstack-dev] [nova][glance] Proposal to remove `nova 
> image-*` commands from novaclient
> 
> 
> 
> As we discuss the glance v2 spec for nova, questions are coming up 
> around what to do about the nova images API which is a proxy for glance 
v1.
> 
> I don't want to add glance v2 support to the nova API since that's just 
> more proxy gorp.
> 
> I don't think we can just make the nova images API fail if we're using 
> glance v2 in the backend, but we'll need some translation later for:
> 
> user->nova-images->glance.v2->glance.v1(ish)->user
> 
> But we definitely want people to stop using the nova images API.
> 
> I think we can start by deprecating the nova images-* commands in 
> python-novaclient, and probably the python API bindings in novaclient 
too.
> 
> People should be using python-glanceclient or python-openstackclient for 

> the CLI, and python-glanceclient or some SDK for the python API 
bindings.
> 
> We recently removed the deprecated nova volume-* stuff from novaclient, 
> this would be the same idea.
> 
> Does anyone have an issue with this?
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Steve Martinelli]

+1000. Totally in favor of this, if anything it seems overdue, I'm a bit
surprised that they aren't already deprecated. Two alternatives exist for
the CLI (osc and glanceclient), and two alternatives exist for python API
bindings (SDK and glanceclient).

This should follow the same case with the nova volume-* commands, deprecate
for 2 releases [1] and then remove [2]. The deprecation message can point
users to OSC and glanceclient.

[1]
https://github.com/openstack/python-novaclient/commit/23f13437dd64496fcbc138bbaa9b0ac615a3cf23
[2]
https://github.com/openstack/python-novaclient/commit/a42570268915f42405ed0b0a67c25686b5db22ce

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead



From:   Matt Riedemann <mrie...@linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   2016/04/05 03:49 PM
Subject:    [openstack-dev] [nova][glance] Proposal to remove `nova
    image-*` commands from novaclient



As we discuss the glance v2 spec for nova, questions are coming up
around what to do about the nova images API which is a proxy for glance v1.

I don't want to add glance v2 support to the nova API since that's just
more proxy gorp.

I don't think we can just make the nova images API fail if we're using
glance v2 in the backend, but we'll need some translation later for:

user->nova-images->glance.v2->glance.v1(ish)->user

But we definitely want people to stop using the nova images API.

I think we can start by deprecating the nova images-* commands in
python-novaclient, and probably the python API bindings in novaclient too.

People should be using python-glanceclient or python-openstackclient for
the CLI, and python-glanceclient or some SDK for the python API bindings.

We recently removed the deprecated nova volume-* stuff from novaclient,
this would be the same idea.

Does anyone have an issue with this?

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Monty Taylor]

On 04/05/2016 05:07 PM, Michael Still wrote:

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.


The big misunderstanding is thinking that our client libs are for our 
users. I made that mistake early on. Our client libs are really for 
server to server communication.


If you want a client lib that works - use either openstacksdk or shade. 
Which of the you use depends on what you want to accomplish. 
openstacksdk is a well designed interface to the OpenStack APIs. Of 
course, the OpenStack APIs are really hard to use across clouds. Shade 
hides the incompatibilities between the clouds, but is not a direct 
mapping to REST API docs.



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:


If you want a client object from one of the client libraries, I STRONGLY 
suggest using os-client-config to construct them instead of using the 
constructors directly. This is because the constructors are really only 
for other OpenStack services.


http://inaugust.com/posts/simple-openstack-clients.html




self.glance = glance_client.Client('2', endpoint, token=token)


There are next to zero cases where the thing you want to do is talk to 
glance using a token and an endpoint. In fact, outside of being inside 
of nova and making proxy calls, the only 'valid' use case is keystone 
service catalog bootstrapping ... and that got replaced with something 
sane in mitaka.


What you want is this:

client = os_client_config.make_client(
'network',
auth_url='https://example.com', username='my-user',
password='awesome-password', project_name='my-project',
region_name='the-best-region')

You should ALWAYS pass an auth_url, a username, a password and a 
project_name. Otherwise, the keystoneauth Session will not be able to 
re-auth you. Also, it saves you having to construct a token yourself.



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.


The python-*client libraries are exceptionally painful to use. Any time 
you want to use them, I recommend not using them, as above.



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.

On Wed, Apr 6, 2016 at 5:46 AM, Matt Riedemann
> wrote:

As we discuss the glance v2 spec for nova, questions are coming up
around what to do about the nova images API which is a proxy for
glance v1.

I don't want to add glance v2 support to the nova API since that's
just more proxy gorp.

I don't think we can just make the nova images API fail if we're
using glance v2 in the backend, but we'll need some translation
later for:

user->nova-images->glance.v2->glance.v1(ish)->user

But we definitely want people to stop using the nova images API.

I think we can start by deprecating the nova images-* commands in
python-novaclient, and probably the python API bindings in
novaclient too.

People should be using python-glanceclient or python-openstackclient
for the CLI, and python-glanceclient or some SDK for the python API
bindings.

We recently removed the deprecated nova volume-* stuff from
novaclient, this would be the same idea.

Does anyone have an issue with this?

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Rackspace Australia


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Dean Troyer]

On Tue, Apr 5, 2016 at 4:35 PM, Ian Cordasco  wrote:

> The goal is to centralize the server expertise and have that be combined
> with the folks who know how to better design a library for a good developer
> experience (kind of like with osc). That said, I think the SDK would have
> gained more traction if the OSC project had adopted it (which it is
> hesistant to do given the troubles it has had with conflicting versions of
> the service clients).
>

Actually it is simple timing.  I didn't want OSC to require the SDK until
they had a 1.0 release, but we went ahead and implemented Network commands
using the SDK anyway because there were no compatibility issues.  OSC
pre-dates the SDK by at least 2 years...

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Nikhil Komawar]

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.

Yours sincerely!

On 4/5/16 5:30 PM, Michael Still wrote:
> On Wed, Apr 6, 2016 at 7:28 AM, Ian Cordasco <sigmaviru...@gmail.com
> <mailto:sigmaviru...@gmail.com>> wrote:
>
>  
>
>
>
> -Original Message-
>
> From: Michael Still <mi...@stillhq.com <mailto:mi...@stillhq.com>>
>
> Reply: OpenStack Development Mailing List (not for usage
> questions) <openstack-dev@lists.openstack.org
> <mailto:openstack-dev@lists.openstack.org>>
>
> Date: April 5, 2016 at 16:11:05
>
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org
> <mailto:openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Ian Cordasco]

 

-Original Message-
From: Michael Still <mi...@stillhq.com>
Reply: Michael Still <mi...@stillhq.com>
Date: April 5, 2016 at 16:30:36
To: Ian Cordasco <sigmaviru...@gmail.com>
CC: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` 
commands from novaclient

> 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.

I think the goal for the python-openstacksdk was to create an effort, like the 
python-openstackclient, which would provide a good user experience (in this 
case for developers) with a consistent design for a single library to eliminate 
the need for every other library.

The goal is to centralize the server expertise and have that be combined with 
the folks who know how to better design a library for a good developer 
experience (kind of like with osc). That said, I think the SDK would have 
gained more traction if the OSC project had adopted it (which it is hesistant 
to do given the troubles it has had with conflicting versions of the service 
clients).

I'll let those projects developers/core reviewers speak more to all of that 
since I've been out of the loop for a while.
--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Michael Still]

On Wed, Apr 6, 2016 at 7:28 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:

>
>
> -Original Message-
> From: Michael Still <mi...@stillhq.com>
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: April 5, 2016 at 16:11:05
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Ian Cordasco]

 

-Original Message-
From: Michael Still <mi...@stillhq.com>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: April 5, 2016 at 16:11:05
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@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.

--  
Ian Cordasco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Michael Still]

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.

On Wed, Apr 6, 2016 at 5:46 AM, Matt Riedemann 
wrote:

> As we discuss the glance v2 spec for nova, questions are coming up around
> what to do about the nova images API which is a proxy for glance v1.
>
> I don't want to add glance v2 support to the nova API since that's just
> more proxy gorp.
>
> I don't think we can just make the nova images API fail if we're using
> glance v2 in the backend, but we'll need some translation later for:
>
> user->nova-images->glance.v2->glance.v1(ish)->user
>
> But we definitely want people to stop using the nova images API.
>
> I think we can start by deprecating the nova images-* commands in
> python-novaclient, and probably the python API bindings in novaclient too.
>
> People should be using python-glanceclient or python-openstackclient for
> the CLI, and python-glanceclient or some SDK for the python API bindings.
>
> We recently removed the deprecated nova volume-* stuff from novaclient,
> this would be the same idea.
>
> Does anyone have an issue with this?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Rackspace Australia
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Ian Cordasco]

On Apr 5, 2016 2:49 PM, "Matt Riedemann"  wrote:
>
> As we discuss the glance v2 spec for nova, questions are coming up around
what to do about the nova images API which is a proxy for glance v1.
>
> I don't want to add glance v2 support to the nova API since that's just
more proxy gorp.
>
> I don't think we can just make the nova images API fail if we're using
glance v2 in the backend, but we'll need some translation later for:
>
> user->nova-images->glance.v2->glance.v1(ish)->user
>
> But we definitely want people to stop using the nova images API.
>
> I think we can start by deprecating the nova images-* commands in
python-novaclient, and probably the python API bindings in novaclient too.
>
> People should be using python-glanceclient or python-openstackclient for
the CLI, and python-glanceclient or some SDK for the python API bindings.
>
> We recently removed the deprecated nova volume-* stuff from novaclient,
this would be the same idea.
>
> Does anyone have an issue with this?

Seems reasonable to me. :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

[Matt Riedemann]

As we discuss the glance v2 spec for nova, questions are coming up 
around what to do about the nova images API which is a proxy for glance v1.


I don't want to add glance v2 support to the nova API since that's just 
more proxy gorp.


I don't think we can just make the nova images API fail if we're using 
glance v2 in the backend, but we'll need some translation later for:


user->nova-images->glance.v2->glance.v1(ish)->user

But we definitely want people to stop using the nova images API.

I think we can start by deprecating the nova images-* commands in 
python-novaclient, and probably the python API bindings in novaclient too.


People should be using python-glanceclient or python-openstackclient for 
the CLI, and python-glanceclient or some SDK for the python API bindings.


We recently removed the deprecated nova volume-* stuff from novaclient, 
this would be the same idea.


Does anyone have an issue with this?

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev