What version of webob do you have installed? stable/essex explicitly depends on
v1.0.8, which ensures that the 'request' attribute is not-None on a Response
object. As of v1.1.1, the 'request' attribute was no longer a supported part of
the API. We treat this in Folsom and Grizzly by explicitly
The short answer here is 'no, there are no plans to natively support HA glance
services'. These problems already have well-established answers and are much
better solved outside of the context of OpenStack.
If you'd like to make a case for built-in HA support, however, I think we would
all
You can set image properties with the '--prop' option. For this command, you
need to use '--prop kernel_id=14652b05-0c27-45d1-b614-a059c9f4f7dc' and '--prop
ramdisk_id=c0f6a4df-5051-49d3-855e-8627c6c15ba6'.
On Nov 1, 2012, at 1:49 AM, Ahmed Al-Mehdi wrote:
Hello,
I followed the steps in
.
From: Brian Waldon bcwal...@gmail.com
Date: Thursday, November 1, 2012 10:49 AM
To: Ahmed Al-Mehdi ah...@coraid.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] [OpenStack][Glance] Uploading image to glance
reports invalid options- kernel_id
with image. May be
used multiple times.
From: openstack-bounces+george.mihaiescu=q9@lists.launchpad.net
[mailto:openstack-bounces+george.mihaiescu=q9@lists.launchpad.net] On
Behalf Of Brian Waldon
Sent: Thursday, November 01, 2012 2:07 PM
To: Ahmed Al
My immediate thought is that you configured glance-registry to use keystone
authentication but you didn't do the same for glance-api. Make sure you add the
following to glance-registry.conf:
[paste_deploy]
flavor=keystone
On Oct 31, 2012, at 4:46 PM, Ahmed Al-Mehdi wrote:
Hello,
I
It looks like you aren't deploying Glance with Keystone authentication enabled.
Add a [paste_deploy] section to glannce-api and glance-registry configs with a
single entry: flavor=keystone.
On Oct 19, 2012, at 12:19 AM, Sam Stoelinga wrote:
Hi all,
When I create a snapshot of a VM, the
This is an important point to bring up. I wrote about this in my Essex -
Folsom migration writeup, but I failed to mention it in the actual Glance
documentation. I'll fix that.
To give you the answer you're looking for - the v2 API is being implemented in
such way that it doesn't depend on
OpenStack
Images API and completely rewriting the python Glance client.
During Grizzly, I plan to continue work on the v2 Images API, but mostly focus
on internal code refactoring.
Thanks!
Brian Waldon
___
Mailing list: https://launchpad.net
The glance client tool can't reach whatever host you have configured. Make sure
your environment variables are set correctly. Additionally, ensure that the URI
returned in your service catalog from keystone is pointing to the right
endpoint.
On Aug 30, 2012, at 2:40 AM, Trinath Somanchi wrote:
While I don't know the root cause here, I did want to rule out that Glance
error as the cause. The code logging that line looks like this:
def process_response(self, resp):
try:
request_id = resp.request.context.request_id
except AttributeError:
Can you share the sequence of commands you used during the install process?
On Aug 29, 2012, at 3:18 AM, Trinath Somanchi wrote:
Hi-
I have installed Openstack Folsom-3 Glance for my testing and found this
error while db sync.
As the feature phase of Folsom has closed, I went ahead and wrote up some notes
about Glance. I included it all in this email, but you can see the pretty
version at http://bcwaldon.cc/2012/08/20/openstack-folsom-glance-overview.html.
Brian Waldon
--
As we are coming up on the Folsom OpenStack
As we can't just add things to our APIs, it's not straight-forward to support
them across the board. I think it would make sense to bake these parameters
into the next versions of our APIs for collection sorting, but my opinion is
definitely biased.
Maybe Joe Heck can comment, as he's working
deployers riding major releases wouldn't be left out in
the dark.
All comments welcome!
Brian Waldon
[1] http://markmail.org/message/5bd5zkyre57ppi3n
[2] http://markmail.org/message/soaldxs4lovd2uir___
Mailing list: https://launchpad.net/~openstack
Post
Even being able to add images while providing an external location would be
useful. You could depend on your user to put it in swift or s3 and just provide
a uri that references it.
On Aug 9, 2012, at 11:05 AM, Gabriel Hurley wrote:
Indeed, uploading large files with the Horizon webserver as
with 'v1' as the
first token in your path: http://Glance_URL:PORT/v1/images/detail
Brian Waldon
On Aug 9, 2012, at 2:05 AM, Sajith Kariyawasam wrote:
Hi all,
I'm trying to invoke Openstack Glance REST API s using a Java client, to get
image details. etc (Ultimately I need to upload an image
we're on a pretty short timeline.
Brian Waldon
The People's PTL
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
Brian Waldon
Sent: Wednesday, August 08, 2012 3:51 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Images API v2 Versioning and Glance
tl
Your glance-api server probably can't talk to your glance-registry server. Make
sure glance-registry is running and that glance-api is correctly configured
with its IP and port.
On Aug 5, 2012, at 8:22 PM, 王鹏 breakwin...@gmail.com wrote:
hello,everyone:
when I over glance install and config
On Aug 3, 2012, at 6:59 AM, Alan Pevec wrote:
So before glance is removed from openstack/glance (in folsom-3 if I
understood correctly?)
Given the response from the community, I think it would be a bad idea to remove
bin/glance in Folsom. My current plan is to leave it in until Grizzly
The review has now landed in python-glanceclient master, so I'm going to
release it tomorrow as v0.3.0 if nothing comes up between now and then.
On Aug 2, 2012, at 3:10 AM, Thierry Carrez wrote:
Brian Waldon wrote:
Ok, so I spent some time on this and got all of the existing/legacy CLI
Ok, so I spent some time on this and got all of the existing/legacy CLI working
within python-glanceclient. It should let anybody using the existing client
keep on keepin' on without having to worry about CLI compatibility (until we
actually remove the deprecated functionality in the v2
feedback. Please file bugs on the python-glanceclient
project in launchpad if you find anything to be missing.
Brian Waldon
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
On Jul 31, 2012, at 2:37 PM, Christoph Hellwig wrote:
On Tue, 2012-07-31 at 11:41 -0700, Brian Waldon wrote:
released python-glanceclient v0.2.0 and would love to gather some
feedback. Please file bugs on the python-glanceclient project in
launchpad if you find anything to be missing
On Jul 31, 2012, at 9:49 PM, Matt Joyce wrote:
I think we're running out of opportunities to do stuff like this.
This is exactly the sort of thing that will drive George Reese into a
homocidal rage. More to the point its exactly the sort of thing our users
are going to despise us for.
Here's the latest draft:
https://docs.google.com/document/d/1jPdgmQUzTuSt9iqcgPy74fbkzafCvqfQpvzRhwf2Kic/edit
It is still a work in progress as we have found several tweaks we want to make
as we actually implement it. I will spend some time updating the google doc
sometime soon.
On Jul 12,
comments like this, I would suggest you
keep them to yourself.
Have a great day!
Brian Waldon
On Jul 12, 2012, at 9:32 AM, George Reese wrote:
This community just doesn't give a rat's ass about compatibility, does it?
-George
On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote:
Hello
and with respect to the whole Cinder
question in general suggest to me that this cavalier attitude towards
forward migration hasn't changed.
So you can kiss my ass.
-George
On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote:
We actually care a hell of a lot about compatibility. We also
?
I think you answered your own question.
Sent from my iPhone
On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.com wrote:
What exactly was so offensive about what I said? Communities like OpenStack
are built on top of people *doing* things, not *talking* about things
tl;dr: I vote for option 2 as it's the only reasonable path from a deployer's
point of view
With my deployer hat on, I think option 1 isn't really valid. It's completely
unfair to force deployers to use Cinder before they can upgrade to Folsom.
There are real deployments using nova-volumes,
TL;DR - Screw the rules, let's call the next release 'Grizzly'
As California is rather lacking in the 'municipality names starting with a G
that we should use for an OpenStack release' department, I have had to look
*slightly* outside the ruleset to find a suitable 'G' release name - that name
I've written up a short guide in Nova's HACKING.rst on how to write useful
commit messages: https://review.openstack.org/#/c/9118/.
The driving factor here is the amount of time I've personally spent coaching
people through the process of composing a commit message. I believe we would
all
We did land a change to python-glanceclient earlier this morning that caused
this, but I didn't really understand the explanation given to me by Monty.
We've got a patch in review that should help alleviate the problem for now:
https://review.openstack.org/#/c/9018/1
Brain
On Jun 26, 2012,
On Jun 14, 2012, at 10:16 AM, Glen Campbell wrote:
My team is working on a set of language bindings for OpenStack and Rackspace
services. The first language we're working on is Python, and I'm trying to
come up with a simple, generic way to handle API extensions.
The first question that
for each individual attribute.
Brian Waldon
On Jun 13, 2012, at 2:34 AM, Daniel P. Berrange wrote:
I was recently pointed at this changeset which adds CPU arch filtering
to the Nova schedular.
https://review.openstack.org/#/c/8267/
IIUC, this relies on any disk images registered with glance
Jay: I asked Michael to rewrite the tool directly using the Glance's REST API -
that's why this question is coming up.
Michael: You should just authenticate with keystone directly
(python-keystoneclient would be easiest), then pass your X-Auth-Token header in
with any subsequent Glance
: Brian Waldon
Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net
Date: 06/08/2012 07:21PM
Cc: openstack@lists.launchpad.net \(openstack@lists.launchpad.net\)
openstack@lists.launchpad.net
Subject: Re: [Openstack] Comparing roles - case (in)sensitivity
I guess I'm looking
+2 … Synchronous calls out to a separate service (glance-api) which then makes
a synchronous call to a different service (glance-registry) all within a
service serving a synchronous call (nova-api) makes the world slow.
On Jun 7, 2012, at 10:00 PM, Gabe Westmaas wrote:
Hey all,
I was
*is* case sensitive. I'm in favor of moving other projects to a case-sensitive
approach for two main reasons:
1) If a role is a string, and comparing strings is inherently case-sensitive,
then role comparison would logically be case-sensitive
2) I get to do less work
Thoughts?
Brian Waldon
. Fairfax Drive Suite 200
Arlington, VA, 22203, USA
http://www.east.isi.edu/~jsuh
- Original Message -
From: Brian Waldon brian.wal...@rackspace.com
To: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
openstack@lists.launchpad.net
Sent: Friday, June 8, 2012 5:50:45 PM
Can you explain why?
On Jun 8, 2012, at 3:18 PM, Kiall Mac Innes wrote:
No, I'm suggesting they should all be treated as a single role. I.e. roles
should be case insensitive.
Thanks,
Kiall
Sent from my phone.
On Jun 8, 2012 11:16 p.m., Brian Waldon brian.wal...@rackspace.com wrote
Sent from my phone.
On Jun 8, 2012 11:20 p.m., Brian Waldon brian.wal...@rackspace.com wrote:
Can you explain why?
On Jun 8, 2012, at 3:18 PM, Kiall Mac Innes wrote:
No, I'm suggesting they should all be treated as a single role. I.e. roles
should be case insensitive.
Thanks,
Kiall
On May 24, 2012, at 4:12 AM, Mark Nottingham wrote:
The other limitation is having defined and registered patch formats. The IETF
is currently working on one for JSON; it should be progressing soon.
http://tools.ietf.org/html/draft-ietf-appsawg-json-patch
I guess I haven't done enough
Hey guys,
I'm considering using PATCH rather than PUT for image updates in the v2 Image
API, but I wanted to make sure there weren't any major blockers that I might be
missing. As far as I can tell, the python libraries we use in Glance support it
(httplib2, requests). However, I discovered
if PATCH is a viable option. Rails is
going to use it, so I feel like people are going to have to get on board
eventually.
Brian
On May 23, 2012, at 1:39 PM, Joshua Harlow wrote:
Is there anyway u can just make it a configuration option?
v2imagemethod = ‘PUT’...
On 5/23/12 1:22 PM, Brian
Relevant links:
https://review.openstack.org/#/c/7716/
http://tools.ietf.org/html/rfc5789
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/
On May 23, 2012, at 1:22 PM, Brian Waldon wrote:
Hey guys,
I'm considering using PATCH rather than
While I agree we need to make a better effort at triaging our bugs (some
projects more than others), I'm hesitant to fully open up bug triaging rights
to everyone. I doubt everyone who would start clicking those buttons have
enough information to make the right decisions. This is similar to why
Glance isn't able to authenticate who you are. What happens if you speak to
glance directly?
On May 10, 2012, at 8:20 AM, Leander Bessa Beernaert wrote:
Can anyone pinpoint what exactly is wrong with this. I've been stuck here for
the past three days, and nothing i do seems to be working :/
I wanted to send out a heads-up to let everyone know that I am now removing all
the old auth code from Nova
(https://blueprints.launchpad.net/nova/+spec/remove-deprecated-auth). This will
definitely be disruptive if you depend on this old code and haven't yet taken
the steps towards using
that I am doing this
right, or if it already exists and I did it wrong...
Thx :-)
On 5/2/12 3:57 PM, Brian Waldon brian.wal...@rackspace.com wrote:
Jay might have a better answer, but as far as I know, yes. You could probably
make the images stores truly pluggable (i.e. not needing
I think the path forward is first to gather information on what people are
already doing w.r.t. replication, which you have helped trigger with this
email. I'm definitely interested in seeing your solution. Once we get this
information out in the open, we need to explore these existing
I'd definitely go for option c here. I'm one of those Core Developers you
mention that wants less code in the core repos. We also need to make sure the
right people are maintaining that API code, which aren't necessarily the *-core
teams.
On May 2, 2012, at 1:02 PM, Vishvananda Ishaya wrote:
I've been thinking about how we can optimize the architecture of Glance while
providing more flexibility to the consumer of the API. Some of the goals I have
are:
1) Minimize request overhead - It feels wasteful to duplicate requests from the
glance-api to the glance-registry.
2) Divide
+2
On Apr 27, 2012, at 8:09 AM, Dan Prince wrote:
Russell Bryant wrote the Nova Qpid rpc implementation and is a member of the
Nova security team. He has been helping chipping away at reviews and
contributing to discussions for some time now.
I'd like to seem him Nova core so he can help
I typically run 'pip install -r tools/pip-requires -r tools/test-requires' from
the root directory. You could also manually translate those lists to a list of
ubuntu packages if you prefer not to use pip.
Brian
On Apr 17, 2012, at 5:49 AM, Scott Lavender wrote:
I have a Jenkins job setup to
The ability to add an external image was dropped when I removed the concept of
image locations. I wanted to rethink how locations worked and didn't realize
how much I was actually removing! 'copy_from' just hasn't been fit into the
spec yet. I want both of the features to be exposed through the
We all know developers don't love writing docs, and when it isn't easy it won't
get done. Unfortunately, that now means that we've shipped Essex without
appropriate documentation of our API extensions. We could really use some help
catching back up and getting these docs written, so if you've
the comment system in
the doc itself. I'll also be available at the summit to discuss this in an
unofficial capacity. There are still a few kinks to work out, but we're finally
getting started implementing this thing. Thanks to everyone who has helped out
so far!
Brian Waldon
APPENDIX A: Major
required by a client (e.g.,
https://github.com/openstack/python-novaclient/blob/master/novaclient/service_catalog.py).
Thanks,
Dan
On Tue, Apr 3, 2012 at 8:39 PM, Brian Waldon brian.wal...@rackspace.com
wrote:
In an effort to further align OpenStack API clients, Jay Pipes, Monty
is interested in playing with the new client, here it is:
https://github.com/openstack/python-glanceclient. You can either yell at me or
use Gerrit to fix anything I may have overlooked. Thanks!
Brian Waldon
___
Mailing list: https://launchpad.net
I would like to add that the complete lack of documentation makes the VSA code
unusable. I have no idea where to get started with it. The following bug has
been open and assigned for the past 6+ months:
https://bugs.launchpad.net/nova/+bug/835099. The fact that you are maintaining
a fork of
The image caching configuration is somewhat unique within Glance, as it is
needed by multiple wsgi apps. As you point out, that means you need to
duplicate your cache configuration in glance-api.conf and glance-cache.conf to
get everything to play well together. I'm going to update the docs to
Related links:
https://bugs.launchpad.net/nova/+bug/954490
https://review.openstack.org/#change,5377
On Mar 14, 2012, at 6:54 PM, Vishvananda Ishaya wrote:
Apologies if you receive this email twice, I sent the first one from the
wrong address.
Hello Everyone,
Last week during the
/#change,3526
Brian Waldon
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Actually the diagnostics command was not added in Essex, but it was converted
to a true extension. However it is part of the Admin API, which means for
Diablo you need to set the allow_admin_api flag on your nova-api node.
On Jan 24, 2012, at 9:41 AM, Kiall Mac Innes wrote:
Hi,
The
the diagnostics is
unsupported when using libvirt/kvm, it still errors out (but with a 500,
rather than 404)
Thanks,
Kiall
On Tue, Jan 24, 2012 at 5:56 PM, Brian Waldon brian.wal...@rackspace.com
wrote:
Actually the diagnostics command was not added in Essex, but it was converted
specs for both
right now (Glance v2 might actually be finalized), but I will work with you to
see what we can do.
Thanks!
Brian Waldon
On Jan 6, 2012, at 3:26 PM, Paul Querna wrote:
Hello,
I was wondering what people think about adding Cross-Origin Resource
Sharing Headers to all
?
2011/12/27 Brian Waldon brian.wal...@rackspace.com:
Hi Nachi!
You are 100% correct, we have not yet implemented that in Nova. I don't see
any bugs/blueprints referencing this, so maybe if one was created we could
make sure it gets done.
Thanks!
Brian
On Dec 26, 2011, at 11:48 PM, Nachi
, 2011, at 7:48 AM, Brian Waldon brian.wal...@rackspace.com wrote:
Hi Nachi!
You are 100% correct, we have not yet implemented that in Nova. I don't see
any bugs/blueprints referencing this, so maybe if one was created we could
make sure it gets done.
Thanks!
Brian
On Dec 26, 2011
Hi Nachi!
You are 100% correct, we have not yet implemented that in Nova. I don't see any
bugs/blueprints referencing this, so maybe if one was created we could make
sure it gets done.
Thanks!
Brian
On Dec 26, 2011, at 11:48 PM, Nachi Ueno wrote:
Hi folks
The doc says *All resizes are
Thanks for the input, Monty. So the reason I'm suggesting major only is due to
our extensions mechanism. We are using extensions to achieve our incremental,
non-breaking changes rather than using minor versioning. For example, we have a
keypairs extension in the v2 API. We shouldn't go to a
On Tue, 2011-12-20 at 10:35 -0500, Brian Waldon wrote:
So there obviously isn't one clear way to version a RESTful API. Not
every API is created equal, and therefore doesn't need the same
capabilities in its versioning mechanism. At this point, it is
important to determine what
on. In order for
OpenStack to be successful, we need to get these foundation pieces right!
Brian Waldon (bcwaldon)
[1] https://dev.twitter.com/docs
[2] http://developer.netflix.com/docs/REST_API_Conventions
[3] http://developer.github.com/v3/
[4] http://developers.facebook.com/docs/reference/rest/
[5
to docs.openstack.org).
Brian Waldon
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Unfortunately, January 26 is our feature freeze. Is there any way we can bump
this up?
On Dec 20, 2011, at 4:40 PM, Glen Campbell wrote:
The Ozone team at Rackspace has it in our current backlog, but we have not
started working on it yet. Probably will be around February, however.
On
I agree that we shouldn't delete snapshots. I'll file a bug and fix the
documentation assuming nobody else has a reason to keep the intended behavior
(http://docs.openstack.org/api/openstack-compute/1.1/content/Delete_Server-d1e2883.html)
Brian
On Dec 7, 2011, at 8:05 PM, Nachi Ueno wrote:
Brian
Thank you for your response.
How about params which is missing in docs?
accessIPv4
accessIPv6
adminPass
config_drive
security_groups
networks
blob
keyname
availability_zone
reservation_id
min_count
max_count
2011/12/1 Brian Waldon brian.wal...@rackspace.com:
Our consoles
I think option e is our best bet. It's the *only* option if we want to
efficiently separate our services (as Jason has pointed out).
Waldon
On Nov 29, 2011, at 10:52 AM, Devin Carlen wrote:
Hey Soren,
On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote:
SQLAlchemy does support looking
+1
On Nov 29, 2011, at 1:03 PM, Vishvananda Ishaya wrote:
Lorin has been a great contributor to Nova for a long time and has been
participating heavily in reviews over the past couple of months. I think he
would be a great addition to nova-core.
Vish
Vek has absolutely stepped up and started doing quite few reviews, so I'd like
to nominate him to be added to nova-core.
Waldon
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
I'd like to nominate Johannes for nova-core, as he has definitely been doing a
good number of reviews lately.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
it.
Thoughts?
-jOrGe W.
On Nov 4, 2011, at 3:08 PM, Brian Waldon wrote:
The nova-api team just had it's first meeting and I wanted to share with
everybody some important decisions that were made:
1) Team Definition
- The nova-api team is going to Own the design and implementation of Nova's
,
please delete it.
--
Brian Waldon
Cloud Software Developer
Rackspace Hosting
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
You should be able to continue to use novaclient with v1.0 in Diablo. Deploying
Essex will require you to transition off of v1.0.
Brian Waldon
On Oct 12, 2011, at 5:10 PM, Venkatesan, Ravikumar wrote:
Some of us at hp still use OS Nova Client V1.0 as nova boot command is not
working
it.
--
Brian Waldon
Cloud Software Developer
Rackspace Hosting
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https
On Oct 11, 2011, at 1:40 PM, Brian Waldon wrote:
I'm all for exposing only the major version in the URI (/v1). We have fallen
into a trap with v1.0 and v1.1 as they are not backckwards-compatible specs
while their versioning implies they are. I think we can have a whole
separate discussion
functionality through the API. This is how
we add optional features within Nova.
Cheers,
Mark.
On Mon, 2011-10-10 at 09:55 -0400, Brian Waldon wrote:
In talking with several people at the Design Summit about the
OpenStack Compute API, I have come to the conclusion that our current
method
it.
--
Brian Waldon
Cloud Software Developer
Rackspace Hosting
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
about the API being
composed solely of different method signatures available to interact with the
core objects would be valid if we wanted the API to own those objects. At the
end of the day, Nova is going to own an instance, not the API that exposes it.
Brian Waldon
featureset they have. When the minor
version is increased, we reset the revision number to 0.
I would assume that if we do agree on these conventions, they would only be a
suggestion, not a requirement. I really want to get this right, so I'm looking
forward to everybody's feedback!
Thanks!
Brian
of our
implementation.
Waldon
On Oct 10, 2011, at 9:55 AM, Brian Waldon wrote:
In talking with several people at the Design Summit about the OpenStack
Compute API, I have come to the conclusion that our current method of
versioning is broken. I would like to propose that as we move forward
. The behavior
should be dependent on the client's requested version.
The only thing that should not propagate is bugs.
On Oct 10, 2011, at 2:55 PM, Brian Waldon wrote:
In talking with several people at the Design Summit about the OpenStack
Compute API, I have come to the conclusion that our
://help.launchpad.net/ListHelp
This email may include confidential information. If you received it in error,
please delete it.
--
Brian Waldon
Cloud Software Developer
Rackspace Hosting
___
Mailing list: https://launchpad.net
Chris (comstud) has been a great help with reviews lately and has quite a bit
of knowledge of the system overall. I think he would add a great amount to the
team, so I'm proposing we add him to nova-core.
Brian Waldon
___
Mailing list: https
As Brian is temporarily out of the office, I'll answer for him. Here are a few
(major-version) differences I see in the 1.1 spec:
1) marker keyword replaces offset for pagination (functionally different, not
just a different name)
2) server addresses container structured differently
3) all
Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Friday, March 4, 2011 2:08pm
To: Brian Waldon brian.wal...@rackspace.com
Cc: Brian Lamar brian.la...@rackspace.com, openstack@lists.launchpad.net
openstack@lists.launchpad.net
Subject: Re: [Openstack] Multiple Versions in Openstack API
On Fri
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Multiple Versions in Openstack API
Brian Waldon wrote:
Currently, the Openstack API includes a Versions WSGI application. The
intended purpose is to detail all versions of the API that are reachable
by a client. Currently, it only supports
-Original Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Wednesday, February 16, 2011 5:09pm
To: Glen Campbell glen.campb...@rackspace.com
Cc: openstack@lists.launchpad.net openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1 ‹ server actions
On Wed,
99 matches
Mail list logo
