Interesting ... do I get back an instance object or just a key/value dict?
Is the attraction not having complex/multi-package client libraries to import?
If the client was: obvious to download, easy to install/update and had a full
object model ... would that be better?
-S
On Fri, Mar 04, 2011 at 01:35:48PM -0600, Monsyne Dragon wrote:
> I think, really, we are getting off on a tangent here. The purpose
> of multitenant is to have a label ('account' or 'project' or
> whatever ) that we tag resources (instances, etc) in nova with
> so that we can group together us
On Fri, Mar 4, 2011 at 1:43 PM, Greg wrote:
> :) Okay, I stand corrected on the tests passing part; that was a jab though
> it did take a while to get there.
> I now back away from auth once again, as I have so many times before...
Well, it still wasn't a great branch.
If it had just been a plu
>
> The usages system (which is dependant on this) ... It has not been coded
> yet, since it is dependant on this multitenant bp. It *is* scheduled, and
> approved for the cactus release, for which merge-prop freeze is in ~2
> weeks.
>
Ouch. Even though it's approved though, my understanding is
On 3/4/11 2:13 PM, Justin Santa Barbara wrote:
I think, really, we are getting off on a tangent here. The purpose
of multitenant is to have a label ('account' or 'project' or
whatever ) that we tag resources (instances, etc) in nova with
so that we can group together usage r
On 03/03/2011 03:32 PM, John Purrier wrote:
> Updates to the OpenStack Governance Model have been made and are published
> here: http://wiki.openstack.org/Governance/Model.
These changes are positive, and correct some problems with the current
model.
But, I have issues with the process.
* This w
Actually if you use XML and provide a schema you have zero parsing in Java,
.Net and any other language that provides strong support for XML binding. It's
actually a lot easier to use than serialization.
We serve two kinds of clients: Those that love XML and those that love JSON.
It's been my
On Fri, Mar 4, 2011 at 2:55 PM, Brian Waldon wrote:
> While a middleware solution for the "limited" functionality would
> technically work, I think most of us would agree it should not be
> implemented as middleware. It can be done much more efficiently at the
> datastore level, especially with th
>
>
>> I think, really, we are getting off on a tangent here. The purpose of
> multitenant is to have a label ('account' or 'project' or whatever )
> that we tag resources (instances, etc) in nova with so that we can group
> together usage reports, etc, that go to some system outside of openst
While a middleware solution for the "limited" functionality would technically
work, I think most of us would agree it should not be implemented as
middleware. It can be done much more efficiently at the datastore level,
especially with the introduction of "marker".
As for shared_ip_groups, I
All this talk about auth and making the API easy for developers to use got me
thinking.
The two most popular formats for APIs are XML and JSON.
XML is language neutral and sort of painful to read by a human. And writing an
XML parser sucks. It's not hard, but it's time consuming and annoying.
On Mar 4, 2011, at 1:25 PM, Jorge Williams wrote:
> I don't want this to deteriorate into a flame war but let's get our facts
> straight:
>
> 1) It completely integrated with the existing auth system and it integrated
> with our default Auth component.
> 2) All tests passed. I was looking o
On 3/4/11 11:53 AM, Eric Day wrote:
On Thu, Mar 03, 2011 at 06:36:14PM -0600, Monsyne Dragon wrote:
On 3/3/11 5:51 PM, Eric Day wrote:
Getting into this a bit more, I'm not sure this is something that
should be the default. For CloudServers v1.0 token auth compatibility,
I'm not even sure this
On Mar 4, 2011, at 12:09 PM, Greg wrote:
> On Mar 4, 2011, at 11:05, Jorge Williams wrote:
>
>>
>> though we removed the details of this part at the request of the swift team.
>>Khaled implement this code to support both the default auth component
>> and to integrate the blueprint with
On Fri, Mar 4, 2011 at 1:33 PM, Brian Waldon wrote:
> 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:
OK. Either Brian is good ;)
> 1) marker keyword replaces offset for pagination (functionally different,
> not
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 con
On Fri, Mar 4, 2011 at 12:28 PM, Brian Lamar wrote:
> Unfortunately v1.0 -> v1.1 is not a minor version increase (despite the
> names).
Ah, ok.
>> then if the v1.1 servers/ endpoint only *extends* the 1.0 version
>> /servers endpoint and doesn't break it, then you could have:
>
> This works for
On Fri, Mar 4, 2011 at 11:03 AM, Glen Campbell
wrote:
> Thanks, Jay ‹ I'll take your suggestion and break these up; in fact, we
> were planning on doing that as the next step, and we have a team here at
> Rackspace that's planning on working on them. We plan on implementing
> these using the 1.1 e
On Fri, Mar 4, 2011 at 10:50 AM, Dan Prince wrote:
> Hi Jay,
>
> Would it be better to have stuff like this go into a bug report? For that
> matter should anything that helps us reach parity with the Cloud Servers v1.0
> spec be a bug report or a blueprint?
No, blueprint is totally fine. I enco
On Mar 4, 2011, at 11:05, Jorge Williams wrote:
>
> though we removed the details of this part at the request of the swift team.
> Khaled implement this code to support both the default auth component and
> to integrate the blueprint with swift. The response to our blueprint, from
> the
On Thu, Mar 03, 2011 at 06:36:14PM -0600, Monsyne Dragon wrote:
> On 3/3/11 5:51 PM, Eric Day wrote:
> >Getting into this a bit more, I'm not sure this is something that
> >should be the default. For CloudServers v1.0 token auth compatibility,
> >I'm not even sure this is the best path. It seems li
> But, unless I'm mistaken, there is only a single call to the auth
> server on the first request. If we go with a Swift model (which is
> similar to the proposed solution from Vish and Andy, but not quite the
> same), the auth server returns the storage-management-url after
> authenticating the us
On Fri, Mar 04, 2011 at 09:46:16AM -0500, Jay Pipes wrote:
> Are you proposing that an entity always be the owner of something?
I'm proposing every resources has an owner.
> If so, I dislike using the term "entity", since entity does not imply
> ownership. I'd prefer "owner" or "account", since t
> Good points above.
>
> Also good point :)
>
> Yup.
>
> Yes, you have a vote, and yes, it counts.
Thank you very much :)
> Would the best option be if the OpenStack API supported both auth
> mechanisms (signature, basic HTTP) and allowed the deployers to pick
> which ones were best for which
Unfortunately v1.0 -> v1.1 is not a minor version increase (despite the names).
> then if the v1.1 servers/ endpoint only *extends* the 1.0 version
> /servers endpoint and doesn't break it, then you could have:
This works for minor versions, but not major versions which have different
object for
On Thu, Mar 3, 2011 at 12:20 PM, Eric Day wrote:
> We should support old versions. The API layers should be a very thin
> layer over what the Nova internal API provides, so even if we have
> v1.0, v1.1, etc. subdirectories in the API and do full code copying,
> it should be a fairly minimal mappin
On Mar 4, 2011, at 10:29 AM, Jay Pipes wrote:
> Would the best option be if the OpenStack API supported both auth
> mechanisms (signature, basic HTTP) and allowed the deployers to pick
> which ones were best for which clients? For instance, if OpenStack
> supported both auth mechanisms simultaneo
On Thu, Mar 3, 2011 at 3:59 PM, Michael Mayo wrote:
> I was thinking more of a "sniff someone's traffic and perform those same
> requests again" sort of attack. But then again, I'm an iPhone guy and not a
> security expert :)
> In the end, I'm simply advocating that we reduce the number of HTTP r
On Thu, Mar 3, 2011 at 3:33 PM, Michael Mayo wrote:
> Here are my thoughts, as a client developer:
> 1. Hit auth server first for token, then hit compute and storage endpoints
> This is fairly simple, but there are a couple of problems with it:
> a. It's not very curl or browser friendly (you have
Thanks, Jay ‹ I'll take your suggestion and break these up; in fact, we
were planning on doing that as the next step, and we have a team here at
Rackspace that's planning on working on them. We plan on implementing
these using the 1.1 extensions mechanism initially, and thus are not
planning on syn
Hi Jay,
Would it be better to have stuff like this go into a bug report? For that
matter should anything that helps us reach parity with the Cloud Servers v1.0
spec be a bug report or a blueprint?
I like the dependency graphs we get with Blueprint's as it helps track how
close we are to reachi
Totally agree with this. So long as if you do support caching, compression,
etc. you do so as specified.
Brian, you might want to go ahead and distribute your WSGI middleware as is
anyway. It may be useful for small deployments, and who knows someone may take
it up as a project and make it m
Does anyone else feel it's a bit late to be targeting new blueprints
for Cactus since we're 2 weeks from branch merge proposal freeze?
http://wiki.openstack.org/CactusReleaseSchedule
-jay
On Wed, Mar 2, 2011 at 4:11 PM, Dan Prince wrote:
> We created a blueprint on adding support for password g
On Thu, Mar 3, 2011 at 11:06 AM, Brian Lamar wrote:
> Part of the API specification says that the OpenStack API supports gzip
> compression in requests and responses. I have an extremely simple WSGI
> middleware implementation of this finished, but it does not support streaming
> which could po
Hi Eric, interesting proposal. Comments inline.
On Tue, Mar 1, 2011 at 9:14 PM, Eric Day wrote:
> For that query you would, but not all. If you want to create a new
> instance for project1 you would:
>
> nova.openstack.org/v1.1/project1/servers
>
> Or if you wanted to reboot instance X in project
Hi Glen,
I've read through the wiki page and although I think the individual
commands are worthy commands to add to the API, I don't see why this
is all being bunched into (yet another) API. I think if you broke out
these commands into individual blueprints:
* Contributors could have already comp
On Thu, Mar 3, 2011 at 4:42 PM, Zed A. Shaw wrote:
> On Thu, Mar 03, 2011 at 12:03:28PM -0800, Vishvananda Ishaya wrote:
>> There have been numerous mailing list discussions about common auth methods.
>> I feel like we end up devolving into theoretical discussions at some point,
>> and I find i
I agree that, while it's a pain, supporting old versions of the API is the best
way to grow adoption. For many shops, simply supporting OpenStack API is a
large engineering effort ... having to revisit it every version update might
bust the camels back. Easy to see why Amazon goes back so far.
Hi all,
Is there any plan to allow booting from volumes, rather than ephemeral
local instance stores?
How about supporting a BIOS bootloader e.g.
http://libvirt.org/formatdomain.html#elementsOSBIOS rather than direct
kernel boot.
Cheers,
Dan
___
Maili
39 matches
Mail list logo
