Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 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 personal, if that's what you meant.
> 
>   Differing ideas and opposing POVs are wonderful, IMO. Groupthink is 
> what should be avoided as unhealthy.
> 
> 
> 
> -- Ed Leafe
> 
> 

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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 personal, if that's what you meant.

Differing ideas and opposing POVs are wonderful, IMO. Groupthink is 
what should be avoided as unhealthy.



-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 insufficient for multi-zone deployments,
> > so no one will be deploying this until we sort it out and come up
> > with a better ID.
> 
> 
>   Because this is just one part of the process of creating a distributed 
> scheduler. The process for selecting a host for a new instance won't depend 
> on the type of PK used for that instance in a db table.

Sure, selecting a host for new instances doesn't depend on solving
the unique ID issue either. You can still work on this without the
partitioning, no?

It's only once the instance is created and we need to list and route
subsequent requests does the uniqueness issue (and ID type) come
up. For this I'm asking why bother implementing partitioning that
will be thrown away if we can finish working through a more robust
path and start working on that?

>   The only reason I brought it up was that Sandy pointed out this 
> uniqueness requirement, and we felt it would be a good idea to ask the list 
> if they had any good ideas about alternatives to range partitions.

Yeah, and this is an important issue we need to solve soon for the
multi-zone work.

> I prefaced my initial post with a disclaimer that I wasn't looking to 
> re-argue things that had already been discussed and agreed to, but I guess 
> most people missed that part. :)

I don't think anyone is arguing, all the discussion has been very
healthy IMHO. We've also not previously discussed or decided anything
at the multi-zone level either (at least nothing I was aware of),
only ID's within a zone.

I think all this is new and useful discussion. :)

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Justin Santa Barbara]

>
>  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 other
> than integer identifiers, it should not be too difficult to retrofit.
>

The type of a server @id in CloudServers is xsd:int, which is a 32-bit
signed integer:
http://docs.rackspacecloud.com/servers/api/v1.0/xsd/server.xsd

So if you have 1 billion integers per zone, you only get 2 zones.  You can
have 4 if you're willing to go negative, but surely it's too early in the
campaign. 

I think the only way long-term we're going to have CloudServers
v1.0 compatibility is by having a proxy that bridges between legacy APIs
(EC2 and CS) and future APIs (OpenStack).  I'm guessing that proxy will have
to be stateful to implement mappings of server IDs etc.  Yes, this sucks.
 But at some stage you have to say "you know, maybe 640KB wasn't enough, and
we have to make some changes"

How about this as a solution: use ranges as you suggest, but let the
starting points for the zone-ids that child-zones draw from be
customer-configured.  We're pushing the problem onto the end-user, but they
probably know best anyway, and we don't really expect anyone to use
sub-zones in anger anyway until Diablo or later, right?

Justin
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 
> use one/none. We can document the behavior as undefined.
> 
> I'm not sure that's a good thing ... the use case I was thinking of is the 
> customer using two providers:
> 
> The customer won't be happy that sometimes he gets status on Instance 
> 10,000,000,001 from Provider-A and sometimes from Provider-B. Or none at all.
> 
> If we append the DNS name of the provider, we bust RS 1.0 compatibility. 

I think this is fine. RS 1.0, just like the EC2 API, were not designed
with federation in mine. We should not try to jump through hoops to
force it if we have the luxury of defining the next API version and
supporting it more elegantly there.

As for backwards compatibility for RS 1.0/EC2, those APIs could
depend on a global mapping server for non-bursting zones to translate
nova-internal IDs (id.zone) to what they need (integer, etc.), but this
should not be a core component of Nova since it goes against our design
tenets. It should be deprecated (along with the APIs) and shutdown
in a timely manner once the new API and tools are available. Managing
resources in bursting zones would only be available through the new API
(along with other new features), so there will be plenty of incentive
for clients to change.

> Perhaps you can walk me through how you see the Cert check helping here 
> (assuming no prefix on id)?
> Or are we assuming that bursting is a RS x.0 API feature and things will 
> change then?

Yeah, the cert check verifies the zone nova.example.com can
return resource IDs named *.nova.example.com, all others should be
ignored. The ID's need the zone name suffix for it to make sense.

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack Design Summit Registration Open

[Andy Smith]

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 announce the opening of registration
>> > for our April 26-29, 2011 Design Summit conference in Santa Clara, CA at
>> > the Hyatt Regency. Confirmed speakers for the first 2 days of the event
>> > include NASA, Wikimedia, eBay, Intel, Citrix, Cloudscaling, GigaSpaces,
>> > KT, Gluster, Scalr, Arista Networks, Mach Technology, Rackspace, and
>> > Hyperstratus with the distance award to Paul Pettigrew the CEO of Mach
>> > Technology from Brisbane, Australia. Please register for the event here
>> > <
>> http://www.cvent.com/events/openstack-design-summit-spring-2011/event-summary-51c521e3af73406dbc548746c25423c4.aspx
>> >.
>>
>> Hey Stephen,
>>
>> There is a small error in the Agenda page on the website. On Day 2 it
>> only shows "Open Stack Conference" while we also have the Design Summit
>> starting on that day. We need to fix that ASAP so that people make the
>> right travel choices.
>>
>> The Event overview could also make it clearer that the event comes in
>> two overlapping flavors (Conference and Design Summit).
>>
>> Everyone:
>> The Design Summit starts on Wednesday and ends on Friday. Feel free to
>> come earlier to also attend the Conference on Tuesday (with Keynotes,
>> Technical and Community tracks)
>>
>
> Another minor error:
> The Event Overview page says:
>
>- When
>-
>
>04/26/11 9:00 am - 04/29/11 4:30 pm
>Central Time
>
> Surely you mean Pacific Time, not Central?
>
> -- Jacob
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] A single cross-zone database?

[Andy Smith]

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 the easiest first step. Zones are an additional
column or join table and implemented as a filter on the query for instances
and the like. Zones in this case being used largely to mean "grouping of
servers with some common, possibly distinct, property." We only support a
single level of 'zones' for the moment, no arbitrary nesting.
2. See whether that works, it probably will for the current scaling targets
and use cases.
3. To implement bursting/hybrid stuff, we then work on a data abstraction
for aggregating the results of remote calls, understanding that we expect
remote calls to have lower performance.

The blueprint as it stands (http://wiki.openstack.org/MultiClusterZones) is
following a 'turtles all the way down' approach that probably isn't really
appropriate for real world usage. In reality there are things that are
global level, things that are region level and things that are cluster
level.
 * A global service will be in charge of specific requests that need to be
global and have very specific and constrained scaling properties, perhaps
global dns management.
 * A region represents the largest unit of scaling, the maximum number of
nodes and services that can managed at time while meeting SLAs, including
the public endpoints, most things above region level need to be managed
client side: one does not expect to list all instances across all regions in
a single call, one expects to make three requests to the three regions one's
instances are in.
 * A cluster represents a grouping unit with common properties, either rack
commonality, capability commonality, or simply special case customers.
Subgroupings here may still be interesting or useful but are unlikely to be
necessary. Clusters are likely to share many things at the region level as
well as have individual cluster level concerns.

This design handles the needs of plenty of large organizations already and
is easy to move to piecemeal from our current codebase, the first step being
that zones are clusters and can share a regional registry (database) and
public endpoint while still having per-zone services (scheduler, et al).

--andy

On Wed, Mar 16, 2011 at 4:51 PM, Sandy Walsh wrote:

>  Yup, that's a fair assessment.
>
>  That said, even without SDB and caching it's going to be tight for Cactus
> anyway. There are lots of little issues that are cropping up once I got down
> to 100'.
>
>  -S
>
>  --
>  From: Justin Santa Barbara 
>
>  *
> *
> Sandy: Have I got the wrong end of the stick here?  Are these our choices?
>
>  Justin
>
>   Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack API - Where do I find ?

[Sheshadri Amathnadu]

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: Wednesday, March 23, 2011 6:11 PM
To: Sheshadri Amathnadu; openstack@lists.launchpad.net
Subject: RE: OpenStack API - Where do I find ?

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/python-novaclient

Perhaps someone else on the list can help you with the Storage API's?

Hope it helps!
-Sandy


From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Sheshadri Amathnadu [sheshadri.amathn...@huawei.com]
Sent: Wednesday, March 23, 2011 9:41 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] OpenStack API - Where do I find ?
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 Innovation Center, Corporate Research US

[cid:image002.png@01CBDF49.2A9B7970]
2330 Central Expressway,
Santa Clara, CA 95050, USA
Bldg # A �C Cube : A1-1135
D: 408-330-5177, F:408-330-5088
Email : sheshadri.amathn...@huawei.com
Website : http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!




Confidentiality Notice: This e-mail message (including any attached or

embedded documents) is intended for the exclusive and confidential use of the

individual or entity to which this message is addressed, and unless otherwise

expressly indicated, is confidential and privileged information of Rackspace.

Any dissemination, distribution or copying of the enclosed material is 
prohibited.

If you receive this transmission in error, please notify us immediately by 
e-mail

at ab...@rackspace.com, and delete the original message.

Your cooperation is appreciated.
<>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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 we sort it out and come up
> with a better ID.


Because this is just one part of the process of creating a distributed 
scheduler. The process for selecting a host for a new instance won't depend on 
the type of PK used for that instance in a db table.

The only reason I brought it up was that Sandy pointed out this 
uniqueness requirement, and we felt it would be a good idea to ask the list if 
they had any good ideas about alternatives to range partitions. I prefaced my 
initial post with a disclaimer that I wasn't looking to re-argue things that 
had already been discussed and agreed to, but I guess most people missed that 
part. :)


-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack API - Where do I find ?

[Sandy Walsh]

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/python-novaclient

Perhaps someone else on the list can help you with the Storage API's?

Hope it helps!
-Sandy


From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Sheshadri Amathnadu [sheshadri.amathn...@huawei.com]
Sent: Wednesday, March 23, 2011 9:41 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] OpenStack API - Where do I find ?

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 Innovation Center, Corporate Research US

[cid:image002.png@01CBDF49.2A9B7970]
2330 Central Expressway,
Santa Clara, CA 95050, USA
Bldg # A �C Cube : A1-1135
D: 408-330-5177, F:408-330-5088
Email : sheshadri.amathn...@huawei.com
Website : http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.

<>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Sandy Walsh]

> 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 to verify the authenticity of a namespace
before it is used. No other peer could register a zone with that
name unless the cert checks out. 

Hmm, yeah, you're right, the SSL cert approach should work for validating 
unique zone names. Funny, myself and pvo were talking about that route 
yesterday. 

But will it help us with the duplicates problem? ...

>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 
use one/none. We can document the behavior as undefined.

I'm not sure that's a good thing ... the use case I was thinking of is the 
customer using two providers:

The customer has his own Openstack deployment (range 0-1B) and outsources to 
Provider-A and Provider-B.
Sadly, Pro-A and Pro-B both use the default ID ranges for service providers 
(let's say 10-11B). 
The customer starts provisioning instances to both provider zones evenly ... 
pow, duplicates.

The customer won't be happy that sometimes he gets status on Instance 
10,000,000,001 from Provider-A and sometimes from Provider-B. Or none at all.

If we append the DNS name of the provider, we bust RS 1.0 compatibility. 

Perhaps you can walk me through how you see the Cert check helping here 
(assuming no prefix on id)?
Or are we assuming that bursting is a RS x.0 API feature and things will change 
then?

-S

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 ID.

Since we've reached MP freeze, and none of this is going to make it
into cactus, it seems to make the most sense to finish flushing this
out on the ML (I think we're close), discuss at the summit if needed,
and implement it once we have a consensus on a more robust solution.

-Eric

On Wed, Mar 23, 2011 at 08:24:29PM -0400, Ed Leafe wrote:
>   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 string value comprised of several meaningful bits of information, or 
> a UUID approach, or some combination of things that would address various 
> things in the operation of a zoned design. I think that this will make an 
> excellent discussion at next month's design summit!
> 
>   But the reality is that this needs to be developed now, under the 
> current design of integer PKs. Please note that the only concern here is how 
> to reconcile the Rackspace API requirement of globally unique instance IDs 
> with the current design of generating PKs in local databases at the compute 
> node level. To my understanding, there is no other alternative than 
> partitioning the available integer range across zones, so that each zone 
> generates its instance PKs starting from a different number, and spaced far 
> enough apart that they will never overlap.
> 
>   In the first post of this thread, I proposed a simple partitioning 
> system: allocating a range of integers for each zone, and asked for feedback 
> as to what people would think would be a reasonable estimate for the maximum 
> number of instances a zone would ever need to create. Most shared my distaste 
> for this sort of partitioning system, but no one offered an alternative that 
> would be workable given the current constraints. 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 other than integer 
> identifiers, it should not be too difficult to retrofit.
> 
>   Unless someone has a better idea... ;-)
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] OpenStack API - Where do I find ?

[Ken Pepple]

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.openstack.org/OpenStackAPI_1-1

You should probably look here for the storage api (AFAIK Swift is still 
tracking Cloud Files compatibility):
 http://docs.rackspacecloud.com/files/api/v1/cf-devguide-20100806.pdf

/k

---
Ken Pepple
http://ken.pepple.info
rabbityard.com



___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 / multi-zone). But hybrid clusters are a 
> different matter. 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 to verify the authenticity of a namespace
before it is used. No other peer could register a zone with that
name unless the cert checks out. 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 use one/none. We can document the behavior as undefined.

So, sure, you can still have duplicates within a zone (or other
namespace), but at least it's self contained and others peering with
it don't need to concern itself or worry about spoofing attacks within
it's own namespace.

> In the top-level zones of hybrid installations, all instances.get(id) calls 
> issued would have to assume they could get back more than one instance. Ugly, 
> but perhaps this is just the nature of the problem?

If we define the API for that call to only return a single instance,
it is up to the child zone to choose which one to send. If it tries
to return an array for a single ID, it would just be a protocol error
and fail.

-Eric

___
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] OpenStack API - Where do I find ?

[Sheshadri Amathnadu]

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 Innovation Center, Corporate Research US

[cid:image002.png@01CBDF49.2A9B7970]
2330 Central Expressway,
Santa Clara, CA 95050, USA
Bldg # A �C Cube : A1-1135
D: 408-330-5177, F:408-330-5088
Email : sheshadri.amathn...@huawei.com
Website : http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

<>___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Sandy Walsh]

(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 clusters are a different 
matter. Regardless of how we delineate it or which ID scheme we use, we have no 
way of detecting collisions.

In the top-level zones of hybrid installations, all instances.get(id) calls 
issued would have to assume they could get back more than one instance. Ugly, 
but perhaps this is just the nature of the problem?

This includes for 64-bit integer, 1-billion per zone approaches ... but so be 
it.

Let's just get something working.

-S


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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 string value comprised of several meaningful bits of information, or a UUID 
approach, or some combination of things that would address various things in 
the operation of a zoned design. I think that this will make an excellent 
discussion at next month's design summit!

But the reality is that this needs to be developed now, under the 
current design of integer PKs. Please note that the only concern here is how to 
reconcile the Rackspace API requirement of globally unique instance IDs with 
the current design of generating PKs in local databases at the compute node 
level. To my understanding, there is no other alternative than partitioning the 
available integer range across zones, so that each zone generates its instance 
PKs starting from a different number, and spaced far enough apart that they 
will never overlap.

In the first post of this thread, I proposed a simple partitioning 
system: allocating a range of integers for each zone, and asked for feedback as 
to what people would think would be a reasonable estimate for the maximum 
number of instances a zone would ever need to create. Most shared my distaste 
for this sort of partitioning system, but no one offered an alternative that 
would be workable given the current constraints. 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 other than integer identifiers, it should not be 
too difficult to retrofit.

Unless someone has a better idea... ;-)


-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 globally, infinitely, permanently unique.  
> > That's what UUIDs are for.  We can generate these randomly without any need 
> > for a central authority, and with no fear of collisions.  It would 
> > certainly be nice if my VM can leave my SoftLayer DC and arrive in my 
> > Rackspace DC and when it comes back I still know that it's the same VM.  
> > That's the OpenStack dream, right?
> 
> Hmm, I may have been swayed against UNC. Routing and caching can still be 
> layered on a UUID without having to parse it.

"If you ignore the security / trust issues..." but we can't ignore
them, so UUIDs alone are sufficient. Do we want this namespace per
zone, deployment, resource owner, or some other dimension?

I see the cases against per-zone with RHEL licensing, but pvo does
give an acceptable workaround. Besides that, I guess I don't see the
value in permanent instances. Tools, billing, etc. should work with a
changing working set. Having said that, I'd be ok with any of those as
namespace boundaries (although auth/owner gets nasty with federation),
as long as we have *something*.

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Paul Voccio]

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 if you were actually
contradicting yourself as it seemed such an odd thing for you to do. : )


>
>My view is that identity should be preserved as long as it's possible to
>do so.  A VM that moves around, gets resized, gets rebooted, etc, should
>have the same identity.
>
>By "identity" I mean that other pieces of software should be able to tell
>that it's the same thing.  A billing system should be able to say "that's
>the same VM that I saw before".  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 charging for one
>month, not two".  This is the current charging scheme for RHEL instances
>hosted on Rackspace Cloud
>(http://www.rackspace.com/cloud/blog/2010/08/31/red-hat-license-fee-for-ra
>ckspace-cloud-servers-changing-from-hourly-to-monthly/), not just a
>corner-case example.

I can speak to this particular example as it only charges you for the max
number of RedHat vms you run for the month. With the caveat of this is how
it was explained to me, please consider the scenario:

Launch 2, 
Terminate 2
Launch 5
Terminate 2
Launch 3 
Terminate All

You get billed for the hours plus 6 RHEL licenses since that was your
peak. In your example above, if you terminated then started another
instance, that¹s really 2 instances, with only one active at any time. If
you launched one with cloned data from the other one and both are active
at the same time, its really a additional instance and the operator can
bill accordingly. I don't suppose this really matters for the point your
making and I'll concede that.

>
>You can invent similar arguments for penetration detection systems ("that
>VM is acting the way that it used to") or any other system for enforcing
>policy.
>
>If you are using some kind of location- or path-based identifier for that
>VM, then client software has to be notified of and keep track of all the
>movement of the VM.  If you have a unique identifier, then clients don't
>have to do any of this.
>
>My point about the UI was that we shouldn't worry about how complex these
>IDs should be.  We should make sure that bits of software can talk to
>each other correctly and simply, and base our ID scheme on those needs.
>Once we've figured out what ID scheme we're using, it's _trivial_ for a
>UI or CLI to turn those ugly IDs into "Paul's Apache server" and "Ewan's
>build machine".
I would agree with this.

>
>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 globally, infinitely, permanently unique.
>That's what UUIDs are for.  We can generate these randomly without any
>need for a central authority, and with no fear of collisions.  It would
>certainly be nice if my VM can leave my SoftLayer DC and arrive in my
>Rackspace DC and when it comes back I still know that it's the same VM.
>That's the OpenStack dream, right?

Is it the ID that matters or the data inside the vm? I think its really
about the data. Consistent Ids would be nice though.

>
>I'm willing to accept that that's difficult to achieve, and I'd
>compromise on identity only being preserved within an ownership/trust
>boundary.  I really don't see why I should lose track of my VM when it
>moves from one zone to another within a given provider though.

If we were to go with UUIDs and using XenServer, I should be able to use
the uuid that it generates upon VM creation. I would almost ask your above
question for XenServer then. When I terminate and launch an VM on the same
machine, I should be able to give it the same uuid that I was just using,
but I can't. Maybe I can and I'm making it harder on myself :)

pvo


>
>Ewan.
>



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Sandy Walsh]

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 charging for one month, not two".  This is the current charging scheme 
> for RHEL instances hosted on Rackspace Cloud 
> (http://www.rackspace.com/cloud/blog/2010/08/31/red-hat-license-fee-for-rackspace-cloud-servers-changing-from-hourly-to-monthly/),
>  not just a corner-case example.

Good use cases.

> 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 globally, infinitely, permanently unique.  That's what 
> UUIDs are for.  We can generate these randomly without any need for a central 
> authority, and with no fear of collisions.  It would certainly be nice if my 
> VM can leave my SoftLayer DC and arrive in my Rackspace DC and when it comes 
> back I still know that it's the same VM.  That's the OpenStack dream, right?

Hmm, I may have been swayed against UNC. Routing and caching can still be 
layered on a UUID without having to parse it.

-S


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ewan Mellor]

> -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 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?
> >
> >
> 
> Where do we put the boundary on the preservation of id? Within the same
> deployment? Within the same zone topology? I'm not quite following the
> billing aspect. If you shut one down and start another that is a
> problem
> for billing?
> 
> You stated earlier today:
> "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!"
> 
> Is this really different? If the id changes, should the user care if it is
> presented in the same way with the same data? Am I missing something?

I certainly didn't intend for those statements to be contradictory.  I don't 
think that they are.

My view is that identity should be preserved as long as it's possible to do so. 
 A VM that moves around, gets resized, gets rebooted, etc, should have the same 
identity.

By "identity" I mean that other pieces of software should be able to tell that 
it's the same thing.  A billing system should be able to say "that's the same 
VM that I saw before".  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 charging for one month, not two".  This is the 
current charging scheme for RHEL instances hosted on Rackspace Cloud 
(http://www.rackspace.com/cloud/blog/2010/08/31/red-hat-license-fee-for-rackspace-cloud-servers-changing-from-hourly-to-monthly/),
 not just a corner-case example.

You can invent similar arguments for penetration detection systems ("that VM is 
acting the way that it used to") or any other system for enforcing policy.

If you are using some kind of location- or path-based identifier for that VM, 
then client software has to be notified of and keep track of all the movement 
of the VM.  If you have a unique identifier, then clients don't have to do any 
of this.

My point about the UI was that we shouldn't worry about how complex these IDs 
should be.  We should make sure that bits of software can talk to each other 
correctly and simply, and base our ID scheme on those needs.  Once we've 
figured out what ID scheme we're using, it's _trivial_ for a UI or CLI to turn 
those ugly IDs into "Paul's Apache server" and "Ewan's build machine".

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 globally, infinitely, permanently unique.  That's what UUIDs are for. 
 We can generate these randomly without any need for a central authority, and 
with no fear of collisions.  It would certainly be nice if my VM can leave my 
SoftLayer DC and arrive in my Rackspace DC and when it comes back I still know 
that it's the same VM.  That's the OpenStack dream, right?

I'm willing to accept that that's difficult to achieve, and I'd compromise on 
identity only being preserved within an ownership/trust boundary.  I really 
don't see why I should lose track of my VM when it moves from one zone to 
another within a given provider though.

Ewan.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Paul Voccio]

>
>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?
>
>

Where do we put the boundary on the preservation of id? Within the same
deployment? Within the same zone topology? I'm not quite following the
billing aspect. If you shut one down and start another that is a problem
for billing? 

You stated earlier today:
"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!"

Is this really different? If the id changes, should the user care if it is
presented in the same way with the same data? Am I missing something?

pvo
>



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ewan Mellor]

> 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 Multiple Zones
>
> > 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 point in trying to keep 
> the ID the same.  Great 
> point.

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?

Ewan.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] (no subject)

[Paul Voccio]

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 questions, you can usually find help in IRC
(#openstack on freenode) or on the mailing lists.

Goodluck,
pvo

On 3/23/11 6:42 AM, "sedrik daimary"  wrote:

>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 approach to understand Openstack compute (nova).
>
>___
>Mailing list: https://launchpad.net/~openstack
>Post to : openstack@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Thoughts on the Nova PTL

[Eric Day]

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 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 collaboration between diverse teams
>  - ensure resources are evenly allocated to meet release requirements
>* OpenStack Project Integration
>  - improve integration with other OpenStack components
>  - ensure the project is contributing to and using openstack-common
>  - help break out components into separate projects when needed
>* Long-Term Project Vision
>  - verify development meets basic design tenets
>  - make sure that project is actually deployable and usable
>  - maintain alignment between release requirements and long term goals
> 
>I'd like to explain my position on these responsibilities, why they are
>important, and how I see that they can be best fulfilled by a Project
>Technical Lead in Nova.  Obviously, the many specifics will be influenced
>by the design summit, but this should paint a picture of what I think is a
>good starting point for the future of Nova.  This isn't meant to be an
>exhaustive list, but rather a beginning.  Hopefully, my ideas can spark a
>bit of discussion to give the elected PTL a clear idea of what to expect.
> 
>Internal Project Communication
> 
>One of the most important jobs of the Nova PTL is to facilitate
>communication between the various teams that are working on the Nova code
>base.  The amount of different work going into Nova is already hard to
>track, and this will only become more difficult as more organizations and
>groups join.  The PTL needs to keep track of which teams are working in
>which areas, to ensure that the teams are able to communicate with each
>other, and to verify that the teams are keeping their specs and blueprints
>up to date.
> 
>To facilitate this, it seems vital to know who is on which team and their
>main development focus for the current release. Because it will be
>virtually impossible to track everyone individually, it will help for
>him or her to have a point of contact on each team.  He should also
>attempt to facilitate different teams working together if their
>development goals align.
> 
>A good example of a place that could benefit from attention by the PTL, is
>the oft-mentioned network refactor.  It has been progressing slowly
>because there are diverse teams working on it without sufficient
>coordination.  The PTL could help to organize a combined network team and
>help to select a team lead to drive the refactor.
> 
>OpenStack Project Integration
> 
>Another responsibility of the PTL is to make sure that Nova is
>well-integrated with the other openstack components.  The PTL needs to
>have a clear picture of new and needed features in glance and swift, as
>well as any new projects that are added to OpenStack.
> 
>It is also vital that we focus on common components over the next couple
>releases.  If we don't do this the projects will gradually grow apart, and
>it will be very difficult to present a coherent OpenStack deployment
>involving all of the projects.  The most important first-step in my mind
>is Authn/Authz.  A common authentication system will do wonders for
>keeping the projects aligned.
> 
>We have discussed beginning to break out components in the Diablo time
>frame.  We need to focus very early on the changes necessary to make
>this painless.  This includes minimizing the communication between
>compute, network, and volume, and ensuring that the components are using
>clear interfaces.
> 
>Long Term Project Vision
> 
>Finally, the PTL needs to maintain a holistic vision of the project and
>the long term vision.  This has less to with the technical implementation
>details, and more to do with making sure the project is successful and of
>high quality.  The PTL needs to constantly be asking two quesions:
> 
>  1) Is it deployable?
>  2) Is it usable?
> 
>For the project to succeed, we need a vehement yes to both of these. With
>the various groups working on features that are important to them, it is
>easy to forget that the it is the quality of the project that will
>determine the success or failure of OpenStack as a whole.  We must put
>extra focus in the following four areas:
> 
>Automated Testing
> 
>Automated Testing is the only way we can verify tha

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 most 
> likely be physically separate hardware, but nothing about zones makes that 
> mandatory. 

It does currently, I wasn't speaking specifically to Rackspace's
use case. Right now some network and volume code are not aware of
cross-zone issues, and instead assume they are the authority for things
like configured IP ranges. We can certainly change this, and if we
do want to allow proper instance migrations between zones, we would
need to allow instance IDs to change. I don't see the importance of
enabling cross-zone migrations (backup+restore seems sufficient). I
may be wrong, but if we did enable this functionality in the future,
I don't see a reason not to allow resource IDs to change.

Sounds like a design summit topic if folks feel we should support this.

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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 be physically separate hardware, but nothing about zones makes that 
mandatory. 


-- Ed Leafe


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Justin Santa Barbara]

>
> 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 point in trying to keep
the ID the same.  Great point.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Justin Santa Barbara]

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 like storing a 'redirect' pointer after a migration.
 I think it all boils down to our use-case for migrations:

   - If it's the cloud provider that notices that one machine is overloaded
   / failing / whatever and wants to move a VM to another host in the same
   zone, that should keep the same ID because it should be transparent to the
   user, and I think this shouldn't be a problem, because each zone has a DB.
   - If the cloud provider has a problem affecting an entire zone (e.g. 5
   more minutes of UPS power), can they live migrate those machines to another
   zone?  This could be problematic, and is where redirect pointers might have
   to come in.  So the 'parent zone' would have to know that 'childzone1' is
   down and those machines are potentially now scattered amongst other zones.
   - If it's the user that wants to migrate a machine e.g. because they are
   fed up with the AWS datacenter and want to go to a competitor, then we don't
   necessarily have to guarantee the same ID.  This presumes this is indeed a
   supported scenario; it may be that even if we make this easy, we don't
   support _live_ migration here.

Do we have any scoping on the use cases for migrations?

In my suggestion, I wasn't really talking about an external registry (other
than DNS to locate the top-level zones)  I don't think my proposed solution
addresses the issue of changing IDs in cross-zone migrations.

Looks like we might need an extended session for this at the Design Summit
:-)

Justin
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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, 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.

-Eric

On Wed, Mar 23, 2011 at 06:14:31PM +, Sandy Walsh wrote:
> 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 more about Justin's comment about an external registry.
> 
> Perhaps a glance-like entry with metadata that can change?
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited.
> If you receive this transmission in error, please notify us immediately by 
> e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Sandy Walsh]

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 more about Justin's comment about an external registry.

Perhaps a glance-like entry with metadata that can change?

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Eric Day]

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 read things like this, the DBA in me winces a little. Meaningful 
> PKs, compound PKs - they always end up being a Very Bad Thing. If you want to 
> add efficient DNS routing, that could be added as additional data about an 
> instance that is periodically updated up the zone structure along with the 
> other capability information, but until now we've passed on that as a 
> premature optimization. That was one of the major arguments in favor of the 
> global DB design.

We're talking about a number of partitioning schemes, reserved bits,
URNs, URIs, etc. Because of the namespace issue I believe we will
need some structure to our resource names.

> > Lets say you have api.rackspace.com (global aggregation zone),
> > rack1.dfw.rackspace.com (real zone running instances), and
> > bursty.customer.com (private zone). Bursty is a rackspace customer
> > and they want to leverage their private resources alongside the
> > public cloud, so they add bursty.customer.com as a private zone
> > for their Rackspace account. The api.rackspace.com server now gets
> > a terminate request for  and it needs to know where to route
> > the request. If we have a global namespace for instances (such as
> > UUIDs), rack1.dfw.rackspace.com and bursty.customer.com could both
> > have servers for  (most likely from bursty spoofing the ID). Now
> > api.rackspace.com doesn't know who to forward the request to.
> 
>   Even if this scenario were to happen, and nova tried to delete an 
> instance with a spoofed ID that did *not* belong to Bursty, it would fail due 
> to improper auth. Otherwise, even without zones/uuids/whatever, I could send 
> termination requests to the API with random IDs and delete any machines with 
> those IDs, whether I had rights to them or not. 

This implies the resource is now uniquely identified along with auth
credentials, which means the resource name cannot stand alone. If
we do have collisions due to spoofing, we're going to see ambiguity
issues crop up in other systems that don't have the auth context. I
strongly believe we need unique resource names that stand on our own
and don't depend on any other component such as auth.

>   In the current zone design, a request to terminate  would not be 
> handled by the outermost zone, since it wouldn't have instances, so it would 
> be forward to each child zone. This would repeat down the zone hierarchy 
> until either there were no more child zones, or a zone found that it had an 
> instance with that ID. In the Bursty example, two zones would find an 
> instance with that ID; one would fail due to auth, and the one owned by 
> Bursty would be terminated as requested. The only way more than one instance 
> would terminate would be if Bursty spoofed their own IDs, which would be 
> their problem, not ours.

I think the "In the current zone design" is my main concern. This
discussions is taking into account how things need to work in the
near future, not just now. We've punted on routing for now and are
simply sending the request to every zone, but this won't work in the
long run. If we had a large public cloud with hundreds of zones,
and thousands of bursting zones, things will get prohibitively
expensive. It's not that they won't function, it just may be
unreasonable response time.

-Eric

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Chris Behrens]

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 someone has 
injected a collision, I would be sending an action to more than 1 VM, not only 
the intended target.  I don't see how collisions can be made to work at all.

And yes, we're talking about spoofing (or really, purposefully colliding a 
known UUID).  I haven't seen any mention to anything else (although I may have 
missed it).  I'm certainly really not worried about machine generated UUIDs 
colliding, myself.

But what we're also talking about here is efficient routing.  Is it necessary?  
No.  Would it scale?  Yes.  A zone name or ID needs to be part of the 
identifier.  I prefer the DNS name idea, although prefixing UUIDs or reserving 
bits in a UUID could also work.

- Chris

On Mar 23, 2011, at 9:01 AM, Ed Leafe wrote:

> 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. There is no direct routing. Instead, a zone "knows" 
> about its instances and its child zones. If the zone receives a request for 
> some action involving a particular instance, it checks if it has that 
> instance among its compute nodes; if not, it forwards the request to each of 
> its child zones. That is repeated until the leaf zones are reached, and most 
> of those will respond with something akin to a 404, indicating that they 
> didn't handle the request. The zone that does have the requested instance, 
> though, will carry out the action and return the result of that action.
> 
>   The child zone responses are then aggregated. If all indicate 404, the 
> zone returns the same. If one child responds that it has handled the request, 
> that response is returned. This repeats back up the zone tree until the zone 
> that originally received the request has heard from all of its child zones 
> (or they timed out). 
> 
>   If there were to be a collision (i.e., two leaf nodes handling the 
> request), there are only two possibilities: either the authenticated user has 
> rights to those nodes, or they do not. If they do not, nothing will happen 
> beyond an authorization failure message. If they do have rights to both 
> instances, then the action will happen to both instances. Since the context 
> of this discussion is deliberate spoofing, my response would be "serves them 
> right". :)
> 
>   So it seems that spoofing should have no effect, assuming that our 
> authentication/authorization system is sound. If it isn't, then we have 
> bigger issues than just ID spoofing, since I could write a program to send 
> API delete requests for random instance IDs - no spoofing required.
> 
>   Without spoofing, let's be realistic: the chance of duplicate uuid 
> values colliding is much, much smaller than the chance of a meteorite 
> smashing into our data centers. From Wikipedia: "In other words, only after 
> generating 1 billion UUIDs every second for the next 100 years, the 
> probability of creating just one duplicate would be about 50%". I believe 
> that that is well beyond our scalability goals, so we can effectively ignore 
> the impact of non-spoofed collisions.
> 
> 
> -- Ed Leafe
> 
> 
> 


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Openstack API - Volumes?

[Chuck Thier]

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
blueprint/documentation for the API that I could take a look at?

And I agree with the others that it would be nice to get the Openstack API
side of things moving since it is a pretty core element and should be in
Cactus, but like I said, I'm not a core dev for nova, so what needs to be
done to get this going?

I also think that since this is a core piece that doesn't exist already, I
don't think it should be an extension and we should work on getting it in
there.

--
Chuck

On Mon, Mar 21, 2011 at 10:14 PM, Adam Johnson  wrote:

> Hey everyone,
>
> I wanted to bring up the topic of volumes in the OpenStack API.  I
> know there was some discussion about this before, but it seems to have
> faded on the ML.   I know Justinsb has done some work on this already,
> and has a branch here:
>
> https://code.launchpad.net/~justin-fathomdb/nova/justinsb-openstack-api-volumes
>
> Im wondering what the consensus is on what the API should look like,
> and when we could get this merged into Nova?
>
> Thanks,
> Adam Johnson
> Midokura
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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. There is no direct routing. Instead, a zone "knows" about 
its instances and its child zones. If the zone receives a request for some 
action involving a particular instance, it checks if it has that instance among 
its compute nodes; if not, it forwards the request to each of its child zones. 
That is repeated until the leaf zones are reached, and most of those will 
respond with something akin to a 404, indicating that they didn't handle the 
request. The zone that does have the requested instance, though, will carry out 
the action and return the result of that action.

The child zone responses are then aggregated. If all indicate 404, the 
zone returns the same. If one child responds that it has handled the request, 
that response is returned. This repeats back up the zone tree until the zone 
that originally received the request has heard from all of its child zones (or 
they timed out). 

If there were to be a collision (i.e., two leaf nodes handling the 
request), there are only two possibilities: either the authenticated user has 
rights to those nodes, or they do not. If they do not, nothing will happen 
beyond an authorization failure message. If they do have rights to both 
instances, then the action will happen to both instances. Since the context of 
this discussion is deliberate spoofing, my response would be "serves them 
right". :)

So it seems that spoofing should have no effect, assuming that our 
authentication/authorization system is sound. If it isn't, then we have bigger 
issues than just ID spoofing, since I could write a program to send API delete 
requests for random instance IDs - no spoofing required.

Without spoofing, let's be realistic: the chance of duplicate uuid 
values colliding is much, much smaller than the chance of a meteorite smashing 
into our data centers. From Wikipedia: "In other words, only after generating 1 
billion UUIDs every second for the next 100 years, the probability of creating 
just one duplicate would be about 50%". I believe that that is well beyond our 
scalability goals, so we can effectively ignore the impact of non-spoofed 
collisions.


-- Ed Leafe




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Chris Behrens]

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 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, compound PKs - they always end up being a Very Bad Thing. If you want to 
> add efficient DNS routing, that could be added as additional data about an 
> instance that is periodically updated up the zone structure along with the 
> other capability information, but until now we've passed on that as a 
> premature optimization. That was one of the major arguments in favor of the 
> global DB design.
> 
>> Lets say you have api.rackspace.com (global aggregation zone),
>> rack1.dfw.rackspace.com (real zone running instances), and
>> bursty.customer.com (private zone). Bursty is a rackspace customer
>> and they want to leverage their private resources alongside the
>> public cloud, so they add bursty.customer.com as a private zone
>> for their Rackspace account. The api.rackspace.com server now gets
>> a terminate request for  and it needs to know where to route
>> the request. If we have a global namespace for instances (such as
>> UUIDs), rack1.dfw.rackspace.com and bursty.customer.com could both
>> have servers for  (most likely from bursty spoofing the ID). Now
>> api.rackspace.com doesn't know who to forward the request to.
> 
>   Even if this scenario were to happen, and nova tried to delete an 
> instance with a spoofed ID that did *not* belong to Bursty, it would fail due 
> to improper auth. Otherwise, even without zones/uuids/whatever, I could send 
> termination requests to the API with random IDs and delete any machines with 
> those IDs, whether I had rights to them or not. 
> 
>   In the current zone design, a request to terminate  would not be 
> handled by the outermost zone, since it wouldn't have instances, so it would 
> be forward to each child zone. This would repeat down the zone hierarchy 
> until either there were no more child zones, or a zone found that it had an 
> instance with that ID. In the Bursty example, two zones would find an 
> instance with that ID; one would fail due to auth, and the one owned by 
> Bursty would be terminated as requested. The only way more than one instance 
> would terminate would be if Bursty spoofed their own IDs, which would be 
> their problem, not ours.
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Set your merge proposals to Work In Progress while you address fixes

[Thierry Carrez]

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 version uploaded at:
> https://code.launchpad.net/~ttx/+junk/reviewlist
> 
> It's very slow and probably very buggy, but you should be able to use
> the provided example.py to extract current "needs review" merge
> proposals, ordered using a default scoring algorithm.
> 
> I'll work on a prettier / sortable HTMLized view next week.

Now available in HTML/sortable form, refreshed every 30min:
http://wiki.openstack.org/reviewslist/

It's a bit fresh and untested, so it may fail horribly. I figured we
better have it available now rather than after FeatureFreeze.

Cheers,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ewan Mellor]

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 layer, that's what 
it's there for!

Ewan.

> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Sandy Walsh
> Sent: 23 March 2011 12:30
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Instance IDs and Multiple Zones
> 
> 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 the real driver is making something that is as-short-as-
> possible and mnemonic enough that a user could look at it and say "yup,
> that's mine". Personally, I find UUID's to be ugly monsters and think
> URN's are better for providing a mnemonic for remembering names.
> 
> Given: "6373-ba62-9847-feab-b72a-00dd" vs.
> "rax:ord:zone3:rack2:cust29:inst383" ... give me a URN anytime.
> However, this does pose security risks by exposing internal layouts.
> 
> We currently allow a user supplied friendly name but under-the-hood use
> the instance ID. Since customers use different auth credentials their
> instances live in different Projects and there is no conflict.
> Duplicate names are allowed across customers (even within customers?)
> Downside is there are no hints for routing from names.
> 
> On bursting:
> 
> Currently, the Instance ID is fabricated in the zone where the create()
> call was handled. This Instance ID is treated like a Reservation #
> which is returned to the user for later follow-up (since provisioning
> can take a while).
> 
> The way I currently envision bursting with zones is that the commercial
> zones would be the leaf zones in a deployment. That is, instances would
> be provisioned locally first (depending on Server Best Match) due to
> their low weight scores and ultimately "burst" through the bottom of
> the zone tree to the commercial cloud.
> 
> I think this works well. If I have a hybrid cloud and issue 'nova list'
> I would see something like:
> 
> "sleepy" - com:myco:development:inst1
> "dopey" - com:myco:development:inst2
> "blinky" - com:myco:development:inst3
> "inky" - rax:ord:zone3:rack2:cust293:inst393
> "pinky" - rax:ord:zone2:rack34:cust293:inst8746
> "clyde" - bobscloud:basement:shelf2:cust9:inst8
> 
> and get a good idea of what's what.
> 
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use
> of the
> individual or entity to which this message is addressed, and unless
> otherwise
> expressly indicated, is confidential and privileged information of
> Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
> prohibited.
> If you receive this transmission in error, please notify us immediately
> by e-mail
> at ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Sandy Walsh]

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 the real driver is making something that is as-short-as-possible and 
mnemonic enough that a user could look at it and say "yup, that's mine". 
Personally, I find UUID's to be ugly monsters and think URN's are better for 
providing a mnemonic for remembering names. 

Given: "6373-ba62-9847-feab-b72a-00dd" vs. "rax:ord:zone3:rack2:cust29:inst383" 
... give me a URN anytime. However, this does pose security risks by exposing 
internal layouts. 

We currently allow a user supplied friendly name but under-the-hood use the 
instance ID. Since customers use different auth credentials their instances 
live in different Projects and there is no conflict. Duplicate names are 
allowed across customers (even within customers?) Downside is there are no 
hints for routing from names.

On bursting: 

Currently, the Instance ID is fabricated in the zone where the create() call 
was handled. This Instance ID is treated like a Reservation # which is returned 
to the user for later follow-up (since provisioning can take a while).

The way I currently envision bursting with zones is that the commercial zones 
would be the leaf zones in a deployment. That is, instances would be 
provisioned locally first (depending on Server Best Match) due to their low 
weight scores and ultimately "burst" through the bottom of the zone tree to the 
commercial cloud. 

I think this works well. If I have a hybrid cloud and issue 'nova list' I would 
see something like:

"sleepy" - com:myco:development:inst1
"dopey" - com:myco:development:inst2
"blinky" - com:myco:development:inst3
"inky" - rax:ord:zone3:rack2:cust293:inst393
"pinky" - rax:ord:zone2:rack34:cust293:inst8746
"clyde" - bobscloud:basement:shelf2:cust9:inst8

and get a good idea of what's what.



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
at ab...@rackspace.com, and delete the original message.
Your cooperation is appreciated.


___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Let's get those features merged !

[Thierry Carrez]

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 list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Instance IDs and Multiple Zones

[Ed Leafe]

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, compound PKs - they always end up being a Very Bad Thing. If you want to 
add efficient DNS routing, that could be added as additional data about an 
instance that is periodically updated up the zone structure along with the 
other capability information, but until now we've passed on that as a premature 
optimization. That was one of the major arguments in favor of the global DB 
design.

> Lets say you have api.rackspace.com (global aggregation zone),
> rack1.dfw.rackspace.com (real zone running instances), and
> bursty.customer.com (private zone). Bursty is a rackspace customer
> and they want to leverage their private resources alongside the
> public cloud, so they add bursty.customer.com as a private zone
> for their Rackspace account. The api.rackspace.com server now gets
> a terminate request for  and it needs to know where to route
> the request. If we have a global namespace for instances (such as
> UUIDs), rack1.dfw.rackspace.com and bursty.customer.com could both
> have servers for  (most likely from bursty spoofing the ID). Now
> api.rackspace.com doesn't know who to forward the request to.

Even if this scenario were to happen, and nova tried to delete an 
instance with a spoofed ID that did *not* belong to Bursty, it would fail due 
to improper auth. Otherwise, even without zones/uuids/whatever, I could send 
termination requests to the API with random IDs and delete any machines with 
those IDs, whether I had rights to them or not. 

In the current zone design, a request to terminate  would not be 
handled by the outermost zone, since it wouldn't have instances, so it would be 
forward to each child zone. This would repeat down the zone hierarchy until 
either there were no more child zones, or a zone found that it had an instance 
with that ID. In the Bursty example, two zones would find an instance with that 
ID; one would fail due to auth, and the one owned by Bursty would be terminated 
as requested. The only way more than one instance would terminate would be if 
Bursty spoofed their own IDs, which would be their problem, not ours.


-- Ed Leafe




___
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] (no subject)

[sedrik daimary]

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 approach to understand Openstack compute (nova).

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] Let's get those features merged !

[Salvatore Orlando]

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: 23 March 2011 11:03
To: openstack@lists.launchpad.net
Subject: [Openstack] Let's get those features merged !

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...

Proposers should make sure they quickly fix the remarks that are reported in 
reviews.

Priority list, as a reminder:
https://code.launchpad.net/~jaypipes/glance/checksum/+merge/52569
https://code.launchpad.net/~rackspace-titan/nova/openstack-api-versioned-controllers/+merge/53748
https://code.launchpad.net/~sandy-walsh/nova/zones3/+merge/52565
https://code.launchpad.net/~openstack-gd/nova/libvirt-multinic-nova/+merge/53871
https://code.launchpad.net/~cerberus/nova/xs_resize/+merge/53903
https://code.launchpad.net/~sandy-walsh/nova/zones4/+merge/53726
https://code.launchpad.net/~citrix-openstack/nova/vmware-vsphere-support/+merge/53060
https://code.launchpad.net/~citrix-openstack/nova/xenapi-netinject-prop/+merge/49798
https://code.launchpad.net/~zulcss/nova/nova-lxc/+merge/51469
https://code.launchpad.net/~citrix-openstack/nova/xenapi-vlan-network-manager/+merge/53660
https://code.launchpad.net/~rackspace-titan/nova/extensions/+merge/53675
https://code.launchpad.net/~bcwaldon/nova/osapi-flavors-links/+merge/54263
https://code.launchpad.net/~bcwaldon/nova/osapi-versions-links/+merge/54265
https://code.launchpad.net/~blamar/nova/openstack-api-1-1-images/+merge/53942
https://code.launchpad.net/~bcwaldon/nova/osapi-servers-links/+merge/54264
https://code.launchpad.net/~rackspace-titan/nova/openstack-api-markers/+merge/53943
https://code.launchpad.net/~rackspace-titan/nova/metadata_v1.1/+merge/53952

--
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

___
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] Let's get those features merged !

[Thierry Carrez]

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...

Proposers should make sure they quickly fix the remarks that are
reported in reviews.

Priority list, as a reminder:
https://code.launchpad.net/~jaypipes/glance/checksum/+merge/52569
https://code.launchpad.net/~rackspace-titan/nova/openstack-api-versioned-controllers/+merge/53748
https://code.launchpad.net/~sandy-walsh/nova/zones3/+merge/52565
https://code.launchpad.net/~openstack-gd/nova/libvirt-multinic-nova/+merge/53871
https://code.launchpad.net/~cerberus/nova/xs_resize/+merge/53903
https://code.launchpad.net/~sandy-walsh/nova/zones4/+merge/53726
https://code.launchpad.net/~citrix-openstack/nova/vmware-vsphere-support/+merge/53060
https://code.launchpad.net/~citrix-openstack/nova/xenapi-netinject-prop/+merge/49798
https://code.launchpad.net/~zulcss/nova/nova-lxc/+merge/51469
https://code.launchpad.net/~citrix-openstack/nova/xenapi-vlan-network-manager/+merge/53660
https://code.launchpad.net/~rackspace-titan/nova/extensions/+merge/53675
https://code.launchpad.net/~bcwaldon/nova/osapi-flavors-links/+merge/54263
https://code.launchpad.net/~bcwaldon/nova/osapi-versions-links/+merge/54265
https://code.launchpad.net/~blamar/nova/openstack-api-1-1-images/+merge/53942
https://code.launchpad.net/~bcwaldon/nova/osapi-servers-links/+merge/54264
https://code.launchpad.net/~rackspace-titan/nova/openstack-api-markers/+merge/53943
https://code.launchpad.net/~rackspace-titan/nova/metadata_v1.1/+merge/53952

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Re: [Openstack] vmware-vsphere-support requires suds on the Hudson machine

[Soren Hansen]

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 file as part of the patch, but
> that’s obviously not being used in the Hudson run.  Who’s in charge of this
> machine?
>
>
>
> Thanks,
>
>
>
> Ewan.
>
>
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Soren Hansen
Ubuntu Developerhttp://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/
___
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] vmware-vsphere-support requires suds on the Hudson machine

[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 file as part of the patch, but that's obviously 
not being used in the Hudson run.  Who's in charge of this machine?

Thanks,

Ewan.

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp