After reading Thierry's blog post on what he expects from the Nova PTL, I
started to consider what I think the PTL's job should be. As I see it, a
Project Technical Lead has three main responsibilities:
* Internal Project Communication
- minimize duplication of work
- facilitate
The vmware-vsphere-support branch has been approved for merge (thanks Jay and
Rick!) Before it will merge, we need to install suds on the Hudson machine.
It's put into the pip-requires file as part of the patch, but that's obviously
not being used in the Hudson run. Who's in charge of this
I'm on it.
mtaylor and myself are usually good bets for this sort of thing.
2011/3/23 Ewan Mellor ewan.mel...@eu.citrix.com
The vmware-vsphere-support branch has been approved for merge (thanks Jay
and Rick!) Before it will merge, we need to install suds on the Hudson
machine. It’s put
Hi Thierry,
Will you consider some help from non-core team members?
Salvatore
-Original Message-
From: openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net
[mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net]
On Behalf Of Thierry Carrez
Hi John,
My name is Bittu and i have recently joined the mailing list of
Openstack. When i heard about OpenStack it sound really interesting.
So i want to contribute to OpenStack Compute but before that i want to
study the architecture of Openstack compute. Can u please give me
advice of how to
Good conversation guys. Certainly something we need to get settled out sooner
than later.
On naming:
No matter how we shake it out (prefixes, mac address, time, etc), we're
essentially fabricating our own form of UUID ... trying to pick some unique
qualifier(s) to avoid collisions.
I think
We shouldn't keep tainting this argument with concerns about whether the IDs
are readable or not. We have UIs and CLIs to make things readable for humans.
We have to accept that, on the scales we care about, any unique ID is going to
be incomprehensible to a human. Rely on your presentation
On Mar 23, 2011, at 8:46 AM, Ewan Mellor wrote:
We have to accept that, on the scales we care about, any unique ID is going
to be incomprehensible to a human. Rely on your presentation layer, that's
what it's there for!
+1
-- Ed Leafe
Thierry Carrez wrote:
Jay Pipes wrote:
If you think there is value in it, I can spend some cycles to generate a
more ordered to-review list using launchpad API (looking up linked
branches/bugs to evaluate each BMP priority).
I might have to kiss you at the summit if you did this.
First
On Mar 23, 2011, at 11:28 AM, Chris Behrens wrote:
How would the admin API know which ID to work with if there are collisions?
Eric's point is that we'd not know where to route the request.
This reflects a fundamental misunderstanding of the way inter-zone
communication works.
Now that I have had a chance to look into this a little more, I realize
that I had missed the connection of talking about the volume functionality
missing in the Openstack Rest API (versus the EC2 api that was already
there).
Justin: Sorry I'm a bit late to the game on this, but is there a
You have a fundamental misunderstanding of my fundamental understanding of how
inter-zone communication works. :) I understand how it works. I'm asking
about an admin API that has privileges for actions for all VMs. As an ISP, I
want to disable a particular VM because it's being 'bad'. If
Hi Ed,
On Wed, Mar 23, 2011 at 08:15:54AM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 1:55 AM, Eric Day wrote:
If we provide some structure to the IDs, such as DNS names, we not only
solve this namespacing problem but we also get a much more efficient
routing mechanism.
When I
Pvo brought up a good use case for naming a little while ago: Migrations.
If we use the instance id (assume UNC) to provide hints to the target zone,
this means the instance id would need to change should the instance move
locations. That's a no-no by everyone's measure.
So, now I'm thinking
I asked for further details in IRC, which started a discussion
there. To sum up, most folks agree migrations within a zone won't
require a new instance ID. Nothing changes except the compute host
it's running on. Migrations outside of a zone would require a new
instance ID, but this should be
On Mar 23, 2011, at 3:00 PM, Eric Day wrote:
Migrations outside of a zone would require a new
instance ID, but this should be fine, since other things would also
change (such as IP, available volumes, ...).
That's probably true in the Rackspace use case, as zones would most
likely
On Wed, Mar 23, 2011 at 07:40:20PM +, Ed Leafe wrote:
Migrations outside of a zone would require a new
instance ID, but this should be fine, since other things would also
change (such as IP, available volumes, ...).
That's probably true in the Rackspace use case, as zones would
Well said Vish, this would be a great wiki entry for folks to reference
in the future. :)
While Nova probably needs the most coordination due to it's developer
base, these of course apply to all other projects.
-Eric
On Tue, Mar 22, 2011 at 11:55:17PM -0700, Vishvananda Ishaya wrote:
After
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
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-
bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Justin Santa
Barbara
Sent: 23 March 2011 19:22
To: Eric Day
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IDs and
-Original Message-
From: Paul Voccio [mailto:paul.voc...@rackspace.com]
Sent: 23 March 2011 22:19
To: Ewan Mellor; Justin Santa Barbara; Eric Day
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Instance IDs and Multiple Zones
I don't agree at all. There are many good
OK, time for everyone to step back and take a deep breath.
There are many implications of the earlier design decision to use
integer PKs for database entries. Most who have responded here, myself
included, have indicated that they would prefer that this be changed to either
a
(sorry Eric, meant to send to the list)
-S
From: Eric Day [e...@oddments.org]
Do we want this namespace per zone, deployment, resource owner, or some other
dimension?
Good question. We can prevent collisions at the zone level and within a
deployment (single provider / multi-zone). But hybrid
Hello,
I’m looking into OpenStack Compute and Storage API’s and could not find one
where all the API’s are listed and what each API’s will look like and the
purpose of it.
I appreciate if somebody can point me to the right direction.
Thanks,
Sheshadri Amathnadu
Sr. Platform Developer
Huawei
On Thu, Mar 24, 2011 at 12:23:42AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Do we want this namespace per zone, deployment, resource owner, or some
other dimension?
Good question. We can prevent collisions at the zone level and within a
deployment (single provider /
On Mar 23, 2011, at 5:41 PM, Sheshadri Amathnadu wrote:
I’m looking into OpenStack Compute and Storage API’s and could not find one
where all the API’s are listed and what each API’s will look like and the
purpose of it.
Start here for OpenStack 1.1 Compute API:
From: Eric Day [e...@oddments.org]
On Thu, Mar 24, 2011 at 12:23:42AM +, Sandy Walsh wrote:
Regardless of how we delineate it or which ID scheme we use, we have no way
of detecting collisions.
Why not? Some schemes such as the ID.DNS name + ssl cert check I
mentioned before allow us
Hi Sheshadri,
Openstack compute (nova) supports both the Amazon EC2 API and the Rackspace 1.0
API currently.
The RS API spec is available here:
http://docs.rackspacecloud.com/servers/api/v1.0/cs-devguide-20110112.pdf
There is a python client library available here:
On Mar 23, 2011, at 8:59 PM, Eric Day wrote:
May I ask what is the point of doing this if it won't make cactus and
we're just going to replace it in a month or two? I think we all agree
that 64-bit integer IDs are insufficient for multi-zone deployments,
so no one will be deploying this until
Coming back from a long break and getting back up to speed.
I believe Sandy and I spoke about this at decent length before, the proposal
that I understood we both walked away happy with was this:
1. As a first step, implement it with a single db, because that is what we
already have and what is
Sorry if I am just way out of the loop here, but where do we submit talk
proposals / sign up for a talk?
On Sun, Mar 20, 2011 at 4:18 PM, Mandelson, Jacob j...@midokura.jp wrote:
On Fri, Mar 11, 2011 at 12:25 AM, Thierry Carrez thie...@openstack.orgwrote:
Stephen Spector wrote:
The
Hi Sandy,
On Thu, Mar 24, 2011 at 01:01:18AM +, Sandy Walsh wrote:
From: Eric Day [e...@oddments.org]
Within that zone Nova will prevent collisions, but if things are really
broken (accident or on purpose)
and it starts returning duplicate resource IDs, peer zones can choose to just
So I'm going to implement a partition of 1 billion integers per zone,
which should allow for approximately 1 billion zones, given a 64 bit integer
for the PK. This should be workable for now, and after the design summit,
when we've come to a consensus on changing the API to accept something
On Mar 23, 2011, at 9:54 PM, Eric Day wrote:
I don't think anyone is arguing, all the discussion has been very
healthy IMHO.
Of course we are arguing - presenting evidence for a particular
position in an effort to persuade is argument. The arguments have not become
heated or
Ok. :) The original statement felt like it was written with negative
connotations, and I just wanted to say I think it's all been positive.
-Eric
On Wed, Mar 23, 2011 at 10:09:50PM -0400, Ed Leafe wrote:
On Mar 23, 2011, at 9:54 PM, Eric Day wrote:
I don't think anyone is arguing, all the
35 matches
Mail list logo
