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 t
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 person
On Wed, Mar 23, 2011 at 09:15:38PM -0400, Ed Leafe wrote:
> 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 insufficie
>
> 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 someth
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 ju
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 wrote:
> On Fri, Mar 11, 2011 at 12:25 AM, Thierry Carrez wrote:
>
>> Stephen Spector wrote:
>> > The OpenStack community is proud to announc
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 t
Thanks a lot Sandy, that helps. Appreciate your quick response.
I just found this link for Storage API’s. Hope I’m on the right page.
http://docs.openstack.org/openstack-object-storage/developer/content/ch03.html
Thanks,
Sheshadri
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: Wednes
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 un
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:
https://github.com/rackspace
> 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 all
Hi Ed,
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 we sort it out and come up
with a better I
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:
http://wiki
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 prov
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 In
(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 hybri
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 st
On Wed, Mar 23, 2011 at 11:09:01PM +, Sandy Walsh wrote:
> From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> > To your point about the boundary of preservation of ID, that's a good
> > question. If you ignore the security / trust issues, then the obvious
> > answer is that IDs should be global
Thanks for the clarification. I wasn't sure if you were actually
contradicting yourself as it seemed such an odd thing for you to do. : )
More below!
>
>I certainly didn't intend for those statements to be contradictory. I
>don't think that they are.
Thanks for the clarification. I wasn't sure
From: Ewan Mellor [ewan.mel...@eu.citrix.com]
> For example, if I charge my customers for a month of usage, even if they only
> run the VM for a part of that month, then my billing system needs to be able
> to say "that VM has moved from here to here, but it's actually the same VM,
> so I'm cha
> -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
>
>I don't agree at all. There are many good reasons to preserve the
>identity of a VM even when it's IP or location changes. Billing, for
>example. Access control. Intrusion detection.
>
>Just because I move a VM from one place to another, why would I expect
>its identity to change?
>
>
Wh
> 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 ID
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 any
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
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 zone
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
>
> 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, ...). A cross-zone migration
> will be more of a copy+delete than a proper move.
+1 on this. If the IP is changing, there's little p
Indeed, migrations are a major fly in the ointment for any strategy for
meaningful naming (i.e. anything that doesn't use a central DB). It's not
clear to me with cross-zone migrations that we (a) can keep the same ID and
(b) want to keep the same ID even if we could...
We could look at tricks li
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 fine,
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 m
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.
>
>
>
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 so
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
bluepr
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. The
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.
On Mar 23, 2011, at 5:15 AM, 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 name
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 th
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
__
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 la
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 t
Salvatore Orlando wrote:
> Will you consider some help from non-core team members?
Every review helps! But we'll still need two core approvals before we
can finally merge the feature...
--
Thierry Carrez (ttx)
Release Manager, OpenStack
___
Mailing l
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 read things like this, the DBA in me winces a little. Meaningful
PKs,
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 ap
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
Sent
Hey everyone,
We have two days left before FeatureFreeze, and still have 17 targeted
feature branches proposed (8 of which related to openstack-api-1.1).
This is a bit worrying, so core team members should all (if possible)
spend time on reviews during this push, don't wait for your review day...
I'm on it.
mtaylor and myself are usually good bets for this sort of thing.
2011/3/23 Ewan Mellor
> 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 fil
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 ma
47 matches
Mail list logo
