+1
On Mon, Feb 6, 2012 at 4:48 PM, Matt Dietz matt.di...@rackspace.com wrote:
Hey guys,
Dragon has really stepped up lately on reviewing patches into Nova, and
has a ton of knowledge around Nova proper, so I propose he be added to Nova
core. I think he'd be a great addition to the team.
on C:
On Sep 2, 2011, at 10:32 AM, Paul Voccio wrote:
My first thought was to do a singled fixed disk and never resize that
disk at all. If you need space, you have to use a volume service.
Ultimately, I don't think this the right approach either, but it solves
the initial use case
John,
We were just discussing this problem the other day. I'm hesitant to mute
people, but the chaos is hard to follow. I often have to go back and read
the logs to study what people's opinions are. I would be interested in
trying some of your suggestions with the appropriate time for comments
Wouldn't this mean that versions of the API for projects would then have a
version that is reflective of the release and not a spec number? Version
1.1 doesn't mean anything in Diablo if it doesn't adhere to the 1.1 guide?
The api would be versioned for diablo and we would start a new version
Vish,
We've talked about this idea in the past and I agree this works for *nix
hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB. If
we went with a 10gb base disk solution this obviously won't work. Even if we
went with a 20gb partition it could become a problem as users
On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote:
2011/9/2 Paul Voccio openst...@substation9.com:
Vish,
We've talked about this idea in the past and I agree this works for *nix
hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB.
Yikes.
Tell me
, Chris Behrens
chris.behr...@rackspace.comwrote:
On Sep 2, 2011, at 8:07 AM, Paul Voccio wrote:
On Fri, Sep 2, 2011 at 8:01 AM, Soren Hansen so...@linux2go.dk wrote:
[...]
The potential for filesystem bugs that could bring the host down gives
me the heebie jeebies. I really, really don't
Thorsten,
I'll take a run at these since I wrote the blueprint. It was initially
more of a placeholder that was going to get filled out later but Vish
bumped the priority before we (Ozone) was ready to move forward. I haven't
talked to Chris in regards to his implementation and I haven't seen the
We'll probably have to tackle Instance migration (which is a
implementation detail of host evacuation). I'll update the BP today.
pvo
On 5/18/11 4:59 AM, Thierry Carrez thie...@openstack.org wrote:
Hello Nova developers,
In the plan that Vish came up with for Diablo[1], we have a number of
+1
On 5/11/11 3:01 PM, Ed Leafe ed.le...@rackspace.com wrote:
On May 11, 2011, at 1:06 PM, Jay Pipes wrote:
Subject says it all. I think Brian's demonstrated that his code
reviews are thoughtful and thorough, and he knows the OpenStack API
controller stuff as well as anyone else I believe.
+1
On 5/11/11 3:02 PM, Ed Leafe e...@leafe.com wrote:
On May 11, 2011, at 1:07 PM, Jay Pipes wrote:
Mark's been a very good reviewer and an invaluable resource on the API
side, particularly regarding serialization. I propose he join
nova-core.
+1
-- Ed Leafe
Are these really the official openstack forums? I didn't get the
impression that this was settled. Didn't we bypass some processes here?
On 5/3/11 2:49 PM, Jordan Rinke jor...@openstack.org wrote:
Ladies and Gentlemen... welcome to the official OpenStack Forums!
http://forums.openstack.org
Hi Eldar,
There was a good discussion at the summit in regards to how this is going
to be represented. Jay Pipes and Jorge Williams were on point (I think)
for pushing this topic forward. Hopefully one of them can reply here with
their findings.
Pvo
On 5/3/11 6:29 PM, Eldar Nugaev
Why should they be secret?
From: Sebastian Stadil sebast...@scalr.commailto:sebast...@scalr.com
Date: Fri, 15 Apr 2011 10:11:42 -0700
To: Soren Hansen so...@openstack.orgmailto:so...@openstack.org
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
+1
On 4/15/11 2:55 PM, Jay Pipes jaypi...@gmail.com wrote:
Hi all,
Ed Leafe (dabo) has been one of those developers that has stepped up
to the plate in code reviews and mailing list discussions. I'd like to
propose he join nova-core.
Cheers,
jay
Jay,
I think that discussion will be one of the more popular talks at the
summit. Looking forward to the discussion. I know a lot of devs will be
happy to see this.
pvo
On 4/8/11 4:21 PM, Jay Pipes jaypi...@gmail.com wrote:
All,
In an effort to speed up our code development processes, reduce
Bittu,
I would start by reading the docs at http://docs.openstack.org/. Then I
would check out the bzr/LP tutorial that Soren put together here:
http://wiki.openstack.org/LifeWithBzrAndLaunchpad.
Once you've gone through those docs, it should get you moving in the right
direction. If you have
I agree with the sentiment that integers aren't the way to go long term.
The current spec of the api does introduce some interesting problems to
this discussion. All can be solved. The spec calls for the api to return
an id and a password upon instance creation. This means the api isn't
, and all ids have always been strings.
Justin
On Tue, Mar 22, 2011 at 12:20 PM, Paul Voccio
paul.voc...@rackspace.commailto:paul.voc...@rackspace.com wrote:
I agree with the sentiment that integers aren't the way to go long term.
The current spec of the api does introduce some interesting problems
, Ed Leafe ed.le...@rackspace.com wrote:
On Mar 16, 2011, at 12:23 PM, Paul Voccio wrote:
Not only is this expensive, but there is no way I can see at the moment
to do pagination, which is what makes this really expensive. If someone
asked for an entire list of all their instances
For Cactus, I'm with Justin and Sandy on #1 to get something working.
Justin — you said earlier that you're not sure this is going to be a problem.
From experience, this is a problem with trying to query all the instances
across zones for Rackspace now. Sandy and others including myself have
Eric,
I think that¹s an interesting proposal. I think I'll try to put something
together to visual this.
pvo
On 3/1/11 8:14 PM, Eric Day e...@oddments.org wrote:
For that query you would, but not all. If you want to create a new
instance for project1 you would:
Jesse,
I agree that some implementations can want to have a single endpoint. I think
this is doable with a simple proxy that can pass requests back to each service
apis. This can also be accomplished by having configuration variables in your
bindings to talk to something that looks like the
George,
What hypervisor are you using? I'm guessing kvm, but not totally sure. I
know the behavior for XenServer is to keep the the instances available
after a reboot. Can you show some examples of what you're talking about
with versions?
Thanks,
Pvo
On 2/24/11 1:49 AM, Thierry Carrez
Justin,
I think you hit upon the reason of why I think it was approved and reverted.
Because it hadn't been talked about in a blueprint or a mail sent to the list
(I think I'm up to date on the threads) and a patch landed means other
alternatives weren't considered before pushing it through to
More inline. I trimmed your agrees.
On 2/18/11 10:27 AM, Jay Pipes jaypi...@gmail.com wrote:
5) Interested developers can get involved in only the services that
they care about without worrying about other services.
Not quite sure how this has to do with REST vs. AMQP... AMQP is simply
the
09:10:19 -0800
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc: Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com,
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re
I wanted to put out into the open where we think the evolution of the apis will
go over the next few releases. This is by no means the only way to do this, but
I thought it would be a start of conversation.
http://wiki.openstack.org/api_transition
I also wanted to clear up some confusion that
Not sure what the etiquette is for removing someone. Michael Gundlach is still
listed but is no longer participating.
pvo
From: Joshua McKenty j...@piston.ccmailto:j...@piston.cc
Date: Wed, 16 Feb 2011 16:51:56 -0800
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc
Thoughts below:
From: Justin Santa Barbara jus...@fathomdb.commailto:jus...@fathomdb.com
Date: Mon, 14 Feb 2011 14:32:52 -0800
To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Compute API 1.1
Some thoughts...
General:
* Are we
Eric,
Just looking at the http operations. Shouldn't the calls be around the
account then the queue?
GET /$account_id/queue/id to list all the queues
GET /$account_id/queue/id/message/id
Am I off here? Thoughts?
pvo
On 2/14/11 5:07 PM, Eric Day e...@oddments.org wrote:
I've summarized
Thoughts below
From: Justin Santa Barbara jus...@fathomdb.commailto:jus...@fathomdb.com
Date: Mon, 14 Feb 2011 15:40:04 -0800
To: Paul Voccio paul.voc...@rackspace.commailto:paul.voc...@rackspace.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
openstack
?
On 2/14/11 6:56 PM, Eric Day e...@oddments.org wrote:
On Tue, Feb 15, 2011 at 12:49:01AM +, Paul Voccio wrote:
Dropping the account_id, would this also assume that there can be more
than one queue per account?
Yeah. Think of the queue name as an extra namespace layer much like
a swift
would like to continue the conversation around a metadata service and
what it could look like. I think its a solution we can all benefit from.
Pvo
On 2/11/11 3:18 PM, Scott Moser smo...@ubuntu.com wrote:
On Fri, 11 Feb 2011, Paul Voccio wrote:
Below.
On 2/11/11 2:30 PM, Scott Moser smo
Diego,
Due to our networking topology, having a vlan per customer isn't really
feasible. Most switches are limited at 4k or 8k or even 32k. With more
customers than these switches can reasonably accommodate, having a single
vlan per customer either limits the portability within a cloud or limits
John,
I would agree with putting deployability at the top of the list. Right now, it
is operational from a developers point of view. I think a true operations team
would struggle supporting it at scale.
A change I might suggest in priority is moving the API up in the list. While
the OS API is
36 matches
Mail list logo