Should we store licensing information as a comment in the
*-requirements files ? Can it be stored on the same line ? Something
like:
oslo.messaging=1.3.0a4 # Apache-2.0
Since it's licenses we're tracking shouldn't we be tracking indirect
dependencies too (i.e. packages pulled in by
We could use a separate requirements file for each driver, following a naming
convention to let installation tools pick up the right file. For example,
oslo.messaging might include amqp-requirements.txt, qpid-requirements.txt,
zmq-requirements.txt, etc.
If we're going to have more than one
Most of the reason for the #2 there is for plugins that taskflow can
use (but which are not required for all users). Ideally there would be
more dynamic way to list requirements of libraries and projects, one
that actually changes depends on the features used/desired to be used.
Disclaimer:
Hi all,
In api.v2.images.ImagesController._get_locations_op_pos there is a
comment that location indices start from one from the client's
perspective and the code subtracts one from the incoming 'index
position' parameter before proceeding with the subsequent operations.
But I see that
Hi all,
I see that api.v2.images.ImagesController._do_replace_locations does not
allow replacing a set of locations with another set. Either the existing
set must be empty or the new set must be empty. The replace operation is
therefore just another implementation of add/delete.
So why not just
Hi All,
While trying to work on a bug I was trying to simulate some image
download failures and found that apparently the 'killed' state is never
set using v2 APIs.
If I understand correctly, a file upload goes to
api.v2.image_data.ImageDataController.upload and goes all the way to
Hi Fei,
Thanks for the confirmation.
I think you're right. The 'killed' status should be set in method upload()
if there is an upload failure, see
https://github.com/openstack/glance/blob/master/glance/common/utils.py#L244
I think you meant:
in 'saving' or
some other state when a PUT fails?
On Sun, Jan 26, 2014 at 5:10 AM, David Koo kpublicm...@gmail.com wrote:
Hi Fei,
Thanks for the confirmation.
I think you're right. The 'killed' status should be set in method
upload()
if there is an upload failure, see
wrote:
On Sun, Jan 26, 2014 at 4:37 PM, David Koo kpublicm...@gmail.com wrote:
Perhaps there is still a bug where an image is getting stuck in 'saving'
or
some other state when a PUT fails?
Yes, that's precisely the problem.
We should definitely fix that, thanks for pointing
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date: 01/27/2014 09:39 AM
Subject: Re: [openstack-dev] [Glance] Is the 'killed' state ever set in
v2?
On Sun, Jan 26, 2014 at 4:37 PM, David Koo kpublicm...@gmail.com
Hi All,
At the moment the GlanceException class has only a static
message member which holds the error string. As a result higher
level modules (e.g. API) are unable to translate a lower level
exception to a more meaningful user-facing message - they either have
to construct a totally new
Hi All,
Bug 1251055 was taken on 14th Nov but there seems to have been no activity
since then (no fixed proposed).
I think I have a fix for this and would like to upload the fix but is it
acceptable to do so when the bug is assigned to somebody else? Can I just
assign it to myself and upload
On Nov 29, 02:22:17 PM (Friday), Chris Friesen wrote:
We're currently running Grizzly (going to Havana soon) and we're
running into an issue where if the active controller is ungracefully
killed then nova-compute on the compute node doesn't properly
connect to the new rabbitmq server on the
Hi All,
A quick question about simple janitorial tasks ...
I noticed that glance.api.v2.image_data.ImageDataController.upload has two
identical except clauses (circa line 98):
except exception.StorageFull as e:
msg = _(Image storage media is full: %s) % e
Hi All,
Newbie stacker here ...
I have a basic question regarding the indended behaviour of Glance's
image update API: What is the indended behaviour of Glance when updating
an already uploaded image file?
The functional test indicates that the intended behaviour is to
disallow such
On Wed, Oct 30, 2013 at 12:18:13AM -0400, Mike Spreitzer wrote:
David koo david@huawei.com wrote on 10/29/2013 05:19:24 AM:
Would it be possible to provide an alternate link to the doc? The
GFW blocks google docs :(.
For those of you behind the GFW, here is the main doc and some
Hi Yathi,
https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit
Would it be possible to provide an alternate link to the doc? The GFW blocks
google docs :(.
Thanks.
--
Koo
___
OpenStack-dev mailing list
17 matches
Mail list logo
