Re: [Openstack] Entities in OpenStack Auth

[Michael Barton]

> Swift
>
> Swift has the concept of accounts, users, and groups. An account
> contains users, and a user can belong to groups. Accounts names have an
> abstraction layer, so while you may login with account "example.com",
> the account name used within swift is a UUID with a prefix.
>
> By default, a user belongs to a group for the user "user:account"
> and a group for the account "account". The other group names can
> be arbitrary strings, so they may be other account names, users,
> or some application-specific term.
>
> All operations are done in the context of a user and account. A user
> may not be a member of the account it's acting on since resources
> can specify ACLs, this is especially true for public resources (where
> user is undefined or anonymous).


To be clear, users in swift are entirely a function of the auth
middleware.  Once you get past middleware, swift only has a concept of
accounts, which are designated in the URL.  The middleware decides
whether or not you have access to that account based on info in the
request (or combined with metadata stored in swift, which is how ACLs
are implemented).

The Cloud Files installation, for example, has no concept of multiple
users in an account, because its authentication system doesn't.

-- Mike

___
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] server affinity

[Jorge Williams]

Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe user 
defined properties.  That's it.  So in that case, I agree with Brian that we 
shouldn't be overloading that functionality by performing some action based on 
user-defined metadata.

Speaking more generally though, any attribute that you associate with a 
resource can be thought of as metadata as well.  Isn't the name of an instance 
metadata about the instance?  Should operators be able to define arbitrary 
metadata and then be able to act on it in some way?  I think so, that's a very 
powerful feature. That said,  I would be cautious about exposing this as an 
arbitrary set of name value pairs because it provides a means by which you can 
bypass the contract and that will cause grief for our clients.  Additionally, 
there's the possibility of clashing metadata names between deployments.  The 
idea behind extensions is that you can define arbitrary metadata about a 
resource, while maintaining a contract and while avoiding conflicts with other 
operators/deployments/implementations.  I should note that the approach really 
isn't that different from AWS in that essentially as an operator you use a 
prefix to separate your metadata from customer metadata...the prefix is simply 
defined by the extension and  you can present your metadata in a separate 
attribute or element in the message.

Given that, I'm still a little fuzzy about whether we've reached a decision as 
to whether affinity id:

1) Should be part of the core Compute API
2) Should be a more general concept that may span different services, as Eric 
Day proposes 
3) Should be introduced as an extension, which can later be promoted to the 
core...or not :-)

As Erik Carlin noted, instances with the same affinity id will likely be placed 
in the same public subnet in Rackspace. Other operators may interpret affinity 
id differently. Is that concept general enough to be in the core?  I'd rather 
not introduce something in the core and then have to take it out.

-jOrGe W.


On Mar 1, 2011, at 11:26 AM, Mark Washenberger wrote:

> Are we using the name metadata to describe a different feature than the one 
> that exists in the CloudServers api?
> 
> It seems like a different feature for the user-properties metadata to have 
> meaning to the api other than "store this information so I can read it later".
> 
> "Justin Santa Barbara"  said:
> 
>> ___
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>> We decided in the merge to call it Metadata, despite being fully aware of
>> the semantic issues, because that's what the CloudServers / OpenStack API
>> uses.
>> 
>> There are many better terms, but for the sake of avoiding a Tower of Babel,
>> let's just call it Metadata.
>> 
>> 
>> 
>> On Tue, Mar 1, 2011 at 6:56 AM, Sandy Walsh wrote:
>> 
>>> Was just speaking with dabo about this and we agree that metadata is a bad
>>> name for this capability.
>>> 
>>> I don't really care about what we call it, but metadata has some
>>> preconceived notions/meanings. Perhaps Criteria?
>>> 
>>> Currently we have *some* criteria for creating a new instance on the
>>> Openstack API side: flavors and operating system. But I think the OS API
>>> payload allows for additional "criteria" to be passed in with the request
>>> (not sure).
>>> 
>>> Eventually all this stuff will have to make it to the Scheduler for
>>> Server-Best-Match/Zone-Best-Match. That's somewhere on our task list for
>>> Cactus :/
>>> 
>>> $0.02
>>> 
>>> -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
>>> 
>> 
> 
> 
> 
> ___
> 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.launc

Re: [Openstack] server affinity

[Sandy Walsh]

I think these additional/optional request parameters (aka metadata) should just 
be part of the context that is created when a command is issued and passed 
around for all services to use as needed. 

So I guess that would be a vote for #2

-S

From:  Jorge Williams [jorge.willi...@rackspace.com]
Sent: Wednesday, March 02, 2011 8:40 AM

Given that, I'm still a little fuzzy about whether we've reached a decision as 
to whether affinity id:

1) Should be part of the core Compute API
2) Should be a more general concept that may span different services, as Eric 
Day proposes
3) Should be introduced as an extension, which can later be promoted to the 
core...or not :-)


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] State of OpenStack Auth

[Jorge Williams]

Soren,

Really good question about why we didn't use cookies. There are two problems 
that I see with cookies.

1)  Weak support in HTTP client libraries.  HTTP libs tend to not handle them 
at all or to not handle them correctly. In the Java world,  for example, 
java.net.* doesn't handle cookies very well. There are certainly other libs 
that handle them, but a whole bunch of software is built on top of java.net.* 
including some popular REST libraries.
2)  Say you make a request and don't include your cookie in it. A typical 
webapp will simply redirect you to a login form.  But what should happen in a 
REST API?  Should you get a 401?  I think it's a little fuzzy how we would 
handle this correctly.

If you want browser support -- and personally I think all of our APIs should be 
browser friendly -- I think the best approach is to support an establish scheme 
like HTTP Basic or Digest.  These schemes have great client lib support.  They 
are supported in a friendly way by browsers.  And they don't break HTTP 
semantics, so you don't get a redirect when you should be getting a request for 
credentials.

That said, I really feel we should take a pluggable approach to authentication 
so that we can let operators and clients decide what they need.

-jOrGe W.


On Mar 1, 2011, at 3:08 PM, Eric Day wrote:

> On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote:
>> 2011/3/1 Eric Day :
>>> Well, hopefully with a shared, modular service, we can add a token
>>> module that uses cookies instead. :)
>> 
>> Sure :) I was just hoping to extract whatever wisdom might have been
>> behind the decision to seemingly reinvent the concept of cookies.
>> Perhaps there's some reason to avoid cookies I'm missing... Sorry,
>> didn't mean to hijack your thread :)
> 
> That's what this thread is for, figure out what we have and what do
> we want? :)
> 
> Perhaps Jorge or someone else on the Rackspace auth side can share
> some reasons for the decisions?
> 
> -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



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] server affinity

[Mark Washenberger]

> [W]e
> shouldn't be overloading that functionality by performing some action based on
> user-defined metadata.

That is exactly what I've been trying to say, but you have stated it much more 
succinctly. Thanks!

My specific concern is with quotas. If the current osapi metadata is overloaded 
with api functionality, then it muddies the concept of quotas. Admins who run 
nova probably don't want the server affinity feature to count against the 
general metadata quota.

Because of this, I don't think server affinity should be part of the metadata 
(specifically defined as the metadata attribute in 
nova.compute.api.API::create). 

This doesn't really have any effect on which of Jorge's options we choose, 
though, so /unhijack.

"Jorge Williams"  said:

> Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe user
> defined properties.  That's it.  So in that case, I agree with Brian that we
> shouldn't be overloading that functionality by performing some action based on
> user-defined metadata.
> 
> Speaking more generally though, any attribute that you associate with a 
> resource
> can be thought of as metadata as well.  Isn't the name of an instance metadata
> about the instance?  Should operators be able to define arbitrary metadata and
> then be able to act on it in some way?  I think so, that's a very powerful
> feature. That said,  I would be cautious about exposing this as an arbitrary 
> set
> of name value pairs because it provides a means by which you can bypass the
> contract and that will cause grief for our clients.  Additionally, there's the
> possibility of clashing metadata names between deployments.  The idea behind
> extensions is that you can define arbitrary metadata about a resource, while
> maintaining a contract and while avoiding conflicts with other
> operators/deployments/implementations.  I should note that the approach really
> isn't that different from AWS in that essentially as an operator you use a 
> prefix
> to separate your metadata from customer metadata...the prefix is simply 
> defined by
> the extension and  you can present your metadata in a separate attribute or
> element in the message.
> 
> Given that, I'm still a little fuzzy about whether we've reached a decision 
> as to
> whether affinity id:
> 
> 1) Should be part of the core Compute API
> 2) Should be a more general concept that may span different services, as Eric 
> Day
> proposes
> 3) Should be introduced as an extension, which can later be promoted to the
> core...or not :-)
> 



___
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] State of OpenStack Auth

[Soren Hansen]

2011/3/2 Jorge Williams :
> 1)  Weak support in HTTP client libraries.

a) This surprises me. I definitely remember using cookies with several
different http libraries.

b) There is *no* support for the current alternative, since it's
something that was made up for this particular purpose. If people use
http libriaries that do support cookies, they get Rackspace Cloud API
auth support for free. If not, they simply have to do it manually in a
manner elmost identical to what they have to do now, except with a
different HTTP header name.

> HTTP libs tend to not handle them at all or to not handle them correctly. In 
>the Java world,  for example, java.net.* doesn't handle cookies very well. 
>There are certainly other libs that handle them, but a whole bunch of software 
>is built on top of java.net.* including some popular REST libraries.

What if we supported cookes on the server side, but noted in the API
docs that broken clients can pass the it as the X-Auth-Token header?

> 2)  Say you make a request and don't include your cookie in it. A typical 
> webapp will simply redirect you to a login form.  But what should happen in a 
> REST API?  Should you get a 401?  I think it's a little fuzzy how we would 
> handle this correctly.

401 sounds reasonable. If the client says it Accepts: text/html, we
could redirect it somewhere useful. If not, just leave the response
empty. How does that sound?

> If you want browser support -- and personally I think all of our APIs should 
> be browser friendly -- I think the best approach is to support an establish 
> scheme like HTTP Basic or Digest.  These schemes have great client lib 
> support.  They are supported in a friendly way by browsers.  And they don't 
> break HTTP semantics, so you don't get a redirect when you should be getting 
> a request for credentials.

That would certainly work. I was just specifically wondering why we're
doing something that has semantics extremely close to cookies, yet
don't use cookies. Whatever it is we do that makes it possible to do
stuff directly in a browser sounds great to me. :)


-- 
Soren Hansen
Ubuntu Developer    http://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

Re: [Openstack] State of OpenStack Auth

[Jorge Williams]

We can certainly try your suggestions but I think the path of least resistance 
is to support an existing authentication scheme.  You're right in stating that 
the semantics are extremely close to cookies.  I'd note that http auth schemes 
almost always work in the exact same way -- that is client keeps track of the 
data, you get the header on every request, etc.

-jOrGe W.


On Mar 2, 2011, at 8:17 AM, Soren Hansen wrote:

2011/3/2 Jorge Williams 
mailto:jorge.willi...@rackspace.com>>:
1)  Weak support in HTTP client libraries.

a) This surprises me. I definitely remember using cookies with several
different http libraries.

b) There is *no* support for the current alternative, since it's
something that was made up for this particular purpose. If people use
http libriaries that do support cookies, they get Rackspace Cloud API
auth support for free. If not, they simply have to do it manually in a
manner elmost identical to what they have to do now, except with a
different HTTP header name.

 HTTP libs tend to not handle them at all or to not handle them correctly. In 
the Java world,  for example, java.net.* doesn't handle cookies very well. 
There are certainly other libs that handle them, but a whole bunch of software 
is built on top of java.net.* including some popular REST libraries.

What if we supported cookes on the server side, but noted in the API
docs that broken clients can pass the it as the X-Auth-Token header?

2)  Say you make a request and don't include your cookie in it. A typical 
webapp will simply redirect you to a login form.  But what should happen in a 
REST API?  Should you get a 401?  I think it's a little fuzzy how we would 
handle this correctly.

401 sounds reasonable. If the client says it Accepts: text/html, we
could redirect it somewhere useful. If not, just leave the response
empty. How does that sound?

If you want browser support -- and personally I think all of our APIs should be 
browser friendly -- I think the best approach is to support an establish scheme 
like HTTP Basic or Digest.  These schemes have great client lib support.  They 
are supported in a friendly way by browsers.  And they don't break HTTP 
semantics, so you don't get a redirect when you should be getting a request for 
credentials.

That would certainly work. I was just specifically wondering why we're
doing something that has semantics extremely close to cookies, yet
don't use cookies. Whatever it is we do that makes it possible to do
stuff directly in a browser sounds great to me. :)


--
Soren Hansen
Ubuntu Developerhttp://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/



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

[Openstack] OpenStack Compute 1.1

[Jorge Williams]

Hey guys,

New version of OpenStack Compute 1.1 is out.

PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
WebHelp: http://docs.openstack.org/openstack-compute/developer/content/

See the "Document Change History" section for a list of changes.

The API is now in Launchpad in the openstack-manuals project.   I checked it in 
3 stages

1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running on 
Rackspace
2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
OpenStack 
3) Open Stack Compute 1.1 (3/1/11):  This is the current version

I did this so that you can run diffs against the three versions and see exactly 
what's changed.  From now on all changes are going directly into Launchpad.

I've gotten a lot of suggestions over the past couple of weeks, and I've tried 
to take them all into account.  There are still a couple of changes coming 
based on those suggestions but they're not very big -- mostly cosmetic.

I realize we're still having a debate about "affinity id".  Affinity id is 
still mentioned in the spec, but I'm totally open to removing it if we decide 
that's not the best approach.

I appreciate your input.  You can contribute by leaving comments in the WebHelp 
version (I don't think enterpad is going to work for this sort of thing).  Or 
if  you find something broken, or want to make another change, you can make 
changes to the openstack-manuals project submit a merge request.

Thanks,

jOrGe W.

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] State of OpenStack Auth

[Michael Barton]

> a secure channel too, but if not attacks are less severe since they
> are limited to reply attacks only (the request and parameters are used
> as part of the signature). We can easily support both (and others),
> but we need to understand the needs and constraints of each.

HMAC is sort of appealing for Swift, since it'd let people choose to
use HTTP instead of HTTPS for data that's not sensitive.

-- Mike

___
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 Compute 1.1

[Justin Santa Barbara]

Looks like some good changes.  Where is this in launchpad, so the community
can help develop it?  For example, I'm willing to document the reservation
of the aws: prefix.

Justin




On Wed, Mar 2, 2011 at 8:29 AM, Jorge Williams  wrote:

>
> Hey guys,
>
> New version of OpenStack Compute 1.1 is out.
>
> PDF:
> http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
>
> See the "Document Change History" section for a list of changes.
>
> The API is now in Launchpad in the openstack-manuals project.   I checked
> it in 3 stages
>
> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running
> on Rackspace
> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on
> OpenStack
> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
>
> I did this so that you can run diffs against the three versions and see
> exactly what's changed.  From now on all changes are going directly into
> Launchpad.
>
> I've gotten a lot of suggestions over the past couple of weeks, and I've
> tried to take them all into account.  There are still a couple of changes
> coming based on those suggestions but they're not very big -- mostly
> cosmetic.
>
> I realize we're still having a debate about "affinity id".  Affinity id is
> still mentioned in the spec, but I'm totally open to removing it if we
> decide that's not the best approach.
>
> I appreciate your input.  You can contribute by leaving comments in the
> WebHelp version (I don't think enterpad is going to work for this sort of
> thing).  Or if  you find something broken, or want to make another change,
> you can make changes to the openstack-manuals project submit a merge
> request.
>
> Thanks,
>
> jOrGe W.
>
> 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 Compute 1.1

[Michael Mayo]

Should comments/suggestions go in this email thread or in the comments sections 
of the web help?  I hate to spam this list :)

Mike

On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:

> 
> Hey guys,
> 
> New version of OpenStack Compute 1.1 is out.
> 
> PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> 
> See the "Document Change History" section for a list of changes.
> 
> The API is now in Launchpad in the openstack-manuals project.   I checked it 
> in 3 stages
> 
> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running on 
> Rackspace
> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
> OpenStack 
> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> 
> I did this so that you can run diffs against the three versions and see 
> exactly what's changed.  From now on all changes are going directly into 
> Launchpad.
> 
> I've gotten a lot of suggestions over the past couple of weeks, and I've 
> tried to take them all into account.  There are still a couple of changes 
> coming based on those suggestions but they're not very big -- mostly cosmetic.
> 
> I realize we're still having a debate about "affinity id".  Affinity id is 
> still mentioned in the spec, but I'm totally open to removing it if we decide 
> that's not the best approach.
> 
> I appreciate your input.  You can contribute by leaving comments in the 
> WebHelp version (I don't think enterpad is going to work for this sort of 
> thing).  Or if  you find something broken, or want to make another change, 
> you can make changes to the openstack-manuals project submit a merge request.
> 
> Thanks,
> 
> jOrGe W.
> 
> 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

Mike Mayo
901-299-9306
@greenisus




___
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] server affinity

[Eric Day]

Well said Jorge. I think we're all in agreement that we need a way
to add both user-defined metadata and service-specific metadata (and
possibly deployment-specific metadata). I think Justin was working
on the metadata mechanisms assuming it would support both based on
prefix. If we don't want to overload metadata and use prefixes to
differentiate between users, providers, and so forth, we should add
another collection to resources. For example:

metadata = [
  "user:comment": "This is Eric's dev server"
  "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Would become:

user_metadata = ["comment": "This is Eric's dev server"]
service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Or don't use metadata for service metadata at all and put directly
in the instance object/record:

instance.id = 100
instance.network = 42
instance.affinity_id = rack4.dc2.east.rackspace.com
# instance.metadata is user-defined metadata only.
instance.metadata = ["comment": "This is Eric's dev server"]

Now the arguments stated by many folks is that "service_metadata"
is really instance properties or instance attributes and should
instead be part of the instance object/record directly (like size,
flavor id, etc. are). I don't disagree, but unfortunately there is
a little more overhead since we're using a structured data store,
and this requires an alter table for every change at this point. It's
more difficult to introduce, test, and remove service attributes. If
we want deployments to be able to define service-specific metadata
and use that in pluggable schedulers, a DB schema change is not a
very elegant way to support this.

So the questions are:

Do we need to support variable service metadata? If so, where should
it go?

If in a key/value list, should existing instance properties be moved
into this format as well?

If in a key/value list, should it just be a prefix in a general
metadata list (and user metadata has a 'user' prefix)?

-Eric

On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
> > [W]e
> > shouldn't be overloading that functionality by performing some action based 
> > on
> > user-defined metadata.
> 
> That is exactly what I've been trying to say, but you have stated it much 
> more succinctly. Thanks!
> 
> My specific concern is with quotas. If the current osapi metadata is 
> overloaded with api functionality, then it muddies the concept of quotas. 
> Admins who run nova probably don't want the server affinity feature to count 
> against the general metadata quota.
> 
> Because of this, I don't think server affinity should be part of the metadata 
> (specifically defined as the metadata attribute in 
> nova.compute.api.API::create). 
> 
> This doesn't really have any effect on which of Jorge's options we choose, 
> though, so /unhijack.
> 
> "Jorge Williams"  said:
> 
> > Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe 
> > user
> > defined properties.  That's it.  So in that case, I agree with Brian that we
> > shouldn't be overloading that functionality by performing some action based 
> > on
> > user-defined metadata.
> > 
> > Speaking more generally though, any attribute that you associate with a 
> > resource
> > can be thought of as metadata as well.  Isn't the name of an instance 
> > metadata
> > about the instance?  Should operators be able to define arbitrary metadata 
> > and
> > then be able to act on it in some way?  I think so, that's a very powerful
> > feature. That said,  I would be cautious about exposing this as an 
> > arbitrary set
> > of name value pairs because it provides a means by which you can bypass the
> > contract and that will cause grief for our clients.  Additionally, there's 
> > the
> > possibility of clashing metadata names between deployments.  The idea behind
> > extensions is that you can define arbitrary metadata about a resource, while
> > maintaining a contract and while avoiding conflicts with other
> > operators/deployments/implementations.  I should note that the approach 
> > really
> > isn't that different from AWS in that essentially as an operator you use a 
> > prefix
> > to separate your metadata from customer metadata...the prefix is simply 
> > defined by
> > the extension and  you can present your metadata in a separate attribute or
> > element in the message.
> > 
> > Given that, I'm still a little fuzzy about whether we've reached a decision 
> > as to
> > whether affinity id:
> > 
> > 1) Should be part of the core Compute API
> > 2) Should be a more general concept that may span different services, as 
> > Eric Day
> > proposes
> > 3) Should be introduced as an extension, which can later be promoted to the
> > core...or not :-)
> > 
> 
> 
> 
> ___
> 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] Entities in OpenStack Auth

[Eric Day]

On Wed, Mar 02, 2011 at 05:07:04AM -0600, Michael Barton wrote:
> > Swift
> >
> > Swift has the concept of accounts, users, and groups. An account
> > contains users, and a user can belong to groups. Accounts names have an
> > abstraction layer, so while you may login with account "example.com",
> > the account name used within swift is a UUID with a prefix.
> >
> > By default, a user belongs to a group for the user "user:account"
> > and a group for the account "account". The other group names can
> > be arbitrary strings, so they may be other account names, users,
> > or some application-specific term.
> >
> > All operations are done in the context of a user and account. A user
> > may not be a member of the account it's acting on since resources
> > can specify ACLs, this is especially true for public resources (where
> > user is undefined or anonymous).
> 
> 
> To be clear, users in swift are entirely a function of the auth
> middleware.  Once you get past middleware, swift only has a concept of
> accounts, which are designated in the URL.  The middleware decides
> whether or not you have access to that account based on info in the
> request (or combined with metadata stored in swift, which is how ACLs
> are implemented).
> 
> The Cloud Files installation, for example, has no concept of multiple
> users in an account, because its authentication system doesn't.

Thanks for the clarification. Perhaps I should restate my proposal
in terms of 'accounts' instead of 'entities', as this already maps
closely to what Swift does.

-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] server affinity

[Justin Santa Barbara]

Thanks Eric: +1, and I appreciate the peace-brokering :-)

I'm not wedded to the idea of putting "service metadata" into the same
collection as "user metadata"; it just seems like a reasonable approach to
me.  But it's more important to me that we agree on something, than that we
agree on the "best" thing!

My votes:

> Do we need to support variable service metadata?

+1  We saw a few people pop up on the list with their own use cases (e.g.
GPUs) when I proposed this originally.

> If so, where should it go?

+1 for re-using the same "Metadata" collection, with an "openstack:" prefix.
 Like it or not, we really have no choice but to reserve the "aws:" prefix,
and to be compatible with anything AWS decides to use this for in future.

> If in a key/value list, should existing instance properties be moved into
this format as well?

-1 (for now): We'd still have to support the separate properties for the
front end APIs.  We'd probably not want to refactor the database schema.
 However, the code can internally harmonize all the properties into a single
collection, which might make routing & processing requests easier.  We could
also support passing e.g. the instance types through the key/value
collection instead of the 'legacy' explicit parameter method in the
OpenStack API. However, I don't think we should change anything here yet,
until we have a clear rationale for doing so.  (Though this rationale might
arise quickly, e.g. multi-cluster-in-a-region)

> If in a key/value list, should it just be a prefix in a general metadata
list (and user metadata has a 'user' prefix)?

+1, but I don't think that we should require user metadata to be prefixed
(at least externally!)  We should reserve the "aws:" and "openstack:"
prefixes asap.  I'm going to propose a doc change to reserve the "aws:"
prefix - I think we have no choice in the matter, and I haven't seen any
objections.


Justin






On Wed, Mar 2, 2011 at 9:43 AM, Eric Day  wrote:

> Well said Jorge. I think we're all in agreement that we need a way
> to add both user-defined metadata and service-specific metadata (and
> possibly deployment-specific metadata). I think Justin was working
> on the metadata mechanisms assuming it would support both based on
> prefix. If we don't want to overload metadata and use prefixes to
> differentiate between users, providers, and so forth, we should add
> another collection to resources. For example:
>
> metadata = [
>  "user:comment": "This is Eric's dev server"
>  "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]
>
> Would become:
>
> user_metadata = ["comment": "This is Eric's dev server"]
> service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com
> "]
>
> Or don't use metadata for service metadata at all and put directly
> in the instance object/record:
>
> instance.id = 100
> instance.network = 42
> instance.affinity_id = rack4.dc2.east.rackspace.com
> # instance.metadata is user-defined metadata only.
> instance.metadata = ["comment": "This is Eric's dev server"]
>
> Now the arguments stated by many folks is that "service_metadata"
> is really instance properties or instance attributes and should
> instead be part of the instance object/record directly (like size,
> flavor id, etc. are). I don't disagree, but unfortunately there is
> a little more overhead since we're using a structured data store,
> and this requires an alter table for every change at this point. It's
> more difficult to introduce, test, and remove service attributes. If
> we want deployments to be able to define service-specific metadata
> and use that in pluggable schedulers, a DB schema change is not a
> very elegant way to support this.
>
> So the questions are:
>
> Do we need to support variable service metadata? If so, where should
> it go?
>
> If in a key/value list, should existing instance properties be moved
> into this format as well?
>
> If in a key/value list, should it just be a prefix in a general
> metadata list (and user metadata has a 'user' prefix)?
>
> -Eric
>
> On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
> > > [W]e
> > > shouldn't be overloading that functionality by performing some action
> based on
> > > user-defined metadata.
> >
> > That is exactly what I've been trying to say, but you have stated it much
> more succinctly. Thanks!
> >
> > My specific concern is with quotas. If the current osapi metadata is
> overloaded with api functionality, then it muddies the concept of quotas.
> Admins who run nova probably don't want the server affinity feature to count
> against the general metadata quota.
> >
> > Because of this, I don't think server affinity should be part of the
> metadata (specifically defined as the metadata attribute in
> nova.compute.api.API::create).
> >
> > This doesn't really have any effect on which of Jorge's options we
> choose, though, so /unhijack.
> >
> > "Jorge Williams"  said:
> >
> > > Metadata in the OpenStack Compute/Cloud Servers  API is meant to
> 

Re: [Openstack] server affinity

[Brian Lamar]

Wait, are we all in agreement that we need user-defined metadata and 
service-specific metadata? I do agree that the data store isn't conducive to 
adding arbitrary metadata due to the rigidness of our DB, but how often are we 
going to be adding new attributes?

I guess my main question is where is the line between a new metadata attribute 
and an instance-specific property? I suppose you could say then I'm all for 
your third and final example.

-Original Message-
From: "Eric Day" 
Sent: Wednesday, March 2, 2011 12:43pm
To: "Mark Washenberger" 
Cc: "openstack@lists.launchpad.net" 
Subject: Re: [Openstack] server affinity

Well said Jorge. I think we're all in agreement that we need a way
to add both user-defined metadata and service-specific metadata (and
possibly deployment-specific metadata). I think Justin was working
on the metadata mechanisms assuming it would support both based on
prefix. If we don't want to overload metadata and use prefixes to
differentiate between users, providers, and so forth, we should add
another collection to resources. For example:

metadata = [
  "user:comment": "This is Eric's dev server"
  "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Would become:

user_metadata = ["comment": "This is Eric's dev server"]
service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"]

Or don't use metadata for service metadata at all and put directly
in the instance object/record:

instance.id = 100
instance.network = 42
instance.affinity_id = rack4.dc2.east.rackspace.com
# instance.metadata is user-defined metadata only.
instance.metadata = ["comment": "This is Eric's dev server"]

Now the arguments stated by many folks is that "service_metadata"
is really instance properties or instance attributes and should
instead be part of the instance object/record directly (like size,
flavor id, etc. are). I don't disagree, but unfortunately there is
a little more overhead since we're using a structured data store,
and this requires an alter table for every change at this point. It's
more difficult to introduce, test, and remove service attributes. If
we want deployments to be able to define service-specific metadata
and use that in pluggable schedulers, a DB schema change is not a
very elegant way to support this.

So the questions are:

Do we need to support variable service metadata? If so, where should
it go?

If in a key/value list, should existing instance properties be moved
into this format as well?

If in a key/value list, should it just be a prefix in a general
metadata list (and user metadata has a 'user' prefix)?

-Eric

On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
> > [W]e
> > shouldn't be overloading that functionality by performing some action based 
> > on
> > user-defined metadata.
> 
> That is exactly what I've been trying to say, but you have stated it much 
> more succinctly. Thanks!
> 
> My specific concern is with quotas. If the current osapi metadata is 
> overloaded with api functionality, then it muddies the concept of quotas. 
> Admins who run nova probably don't want the server affinity feature to count 
> against the general metadata quota.
> 
> Because of this, I don't think server affinity should be part of the metadata 
> (specifically defined as the metadata attribute in 
> nova.compute.api.API::create). 
> 
> This doesn't really have any effect on which of Jorge's options we choose, 
> though, so /unhijack.
> 
> "Jorge Williams"  said:
> 
> > Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe 
> > user
> > defined properties.  That's it.  So in that case, I agree with Brian that we
> > shouldn't be overloading that functionality by performing some action based 
> > on
> > user-defined metadata.
> > 
> > Speaking more generally though, any attribute that you associate with a 
> > resource
> > can be thought of as metadata as well.  Isn't the name of an instance 
> > metadata
> > about the instance?  Should operators be able to define arbitrary metadata 
> > and
> > then be able to act on it in some way?  I think so, that's a very powerful
> > feature. That said,  I would be cautious about exposing this as an 
> > arbitrary set
> > of name value pairs because it provides a means by which you can bypass the
> > contract and that will cause grief for our clients.  Additionally, there's 
> > the
> > possibility of clashing metadata names between deployments.  The idea behind
> > extensions is that you can define arbitrary metadata about a resource, while
> > maintaining a contract and while avoiding conflicts with other
> > operators/deployments/implementations.  I should note that the approach 
> > really
> > isn't that different from AWS in that essentially as an operator you use a 
> > prefix
> > to separate your metadata from customer metadata...the prefix is simply 
> > defined by
> > the extension and  you can present your metadata in a separate attribute or
> > element in the message

Re: [Openstack] Entities in OpenStack Auth

[Brian Lamar]

I like this idea, but I have some concerns about the feasibility of 
successfully differentiating between users and projects. While it's easy to 
query one data store and then the next, perhaps we can avoid this issue by 
assigning unique identifiers to resources?

Show all servers in project1:
 GET http://nova.openstack.org/v1.1/servers?project=project1

Show "Instance X":
 GET http://nova.openstack.org/v1.1/servers/-F5*ovBi-=rYdW3leIGY

Show all servers available to current user:
 GET http://nova.openstack.org/v1.1/servers

Unique identifiers for items, while many feel they are cumbersome, provide a 
couple benefits I can think of off the top of my head:

1) Easy permalinks (ability to re-name everything else about the server without 
worrying about the URL changing)

2) Public URLs no longer need any other identifying information because they 
are now unique.

Problems include things like me not knowing the intricacies of the OpenStack 
database which might make my first example more difficult. Also, some people 
like URLs to be readable and/or memorable.


-Original Message-
From: "Eric Day" 
Sent: Tuesday, March 1, 2011 9:14pm
To: "Justin Santa Barbara" 
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Entities in OpenStack Auth

For that query you would, but not all. If you want to create a new
instance for project1 you would:

nova.openstack.org/v1.1/project1/servers

Or if you wanted to reboot instance X in project1:

nova.openstack.org/v1.1/project1/servers/X

Note that the following resource is not the same as the last, since
justin wouldn't be the owner for instance X, project1 would be:

nova.openstack.org/v1.1/justin/servers/X

I think searches will always have special cases with filter options,
but for identifying a canonical URL for a resource, having the entity
name of the owner in there seems correct.

The main thing I'm trying to figure out is whether to use an extra
entity in the path for new service URLs. Swift does and Nova does not,
and it would be nice to have some consistency. I see the benefits of
both, and in Swift's case it needs to for simple public URLs (where
there is no user context).

-Eric

On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote:
>If we're always going to pass the same user-id token (for a particular
>user), what's the value in passing it at all?  Why not get it from the
>authentication token?
>e.g. my X-Auth-Token could look like:  "justinsb
>project1,project2,project3 5OPr9UR2xk32K9ArAjO562e" (i.e. my username,
>projects and a crypto signature)
>Justin
> 
>On Tue, Mar 1, 2011 at 5:51 PM, Eric Day  wrote:
> 
>  Hi Justin,
>  On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote:
>  >However, what I don't understand is how I can query my servers in
>  project1
>  >and project2 (but not those in project3). *The only way I could see
>  is
>  >doing something like this:
>  >*nova.openstack.org/v1.1/project1+project2/servers.
>  >I agree that REST paths aren't themselves hacky in the
>  single-project
>  >case, but I don't yet grok the multi-project query. *Of the 3
>  options I do
>  >grok, I see (c) as the least hacky.
> 
>  I would probably say use nova.openstack.org/v1.1/justin/servers with
>  one or more filter parameters in the URL or body as you mention. This
>  something to consider across all services, not just nova. AFAIK
>  Swift doesn't support queries across multiple accounts right now,
>  so I'd like to hear their thoughts on it as well.
>  -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



___
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 Compute 1.1

[Eric Day]

Thanks Jorge, this looks good. The 'affinityId' name is better than
'location' as I've been using to describe it. I propose affinity ID
be a common (optional) property among all openstack services when
it makes sense, so I would suggest we add it to network, volume, and
if the swift guys are up for it, swift objects. :)  I don't think it
makes sense for glance, but will for burrow.

Thanks for putting this in the docs repo too!

-Eric

On Wed, Mar 02, 2011 at 08:42:11AM -0800, Justin Santa Barbara wrote:
>Looks like some good changes.  Where is this in launchpad, so the
>community can help develop it?  For example, I'm willing to document the
>reservation of the aws: prefix.
>Justin
> 
>On Wed, Mar 2, 2011 at 8:29 AM, Jorge Williams
> wrote:
> 
>  Hey guys,
> 
>  New version of OpenStack Compute 1.1 is out.
> 
>  PDF:
>   http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
>  WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> 
>  See the "Document Change History" section for a list of changes.
> 
>  The API is now in Launchpad in the openstack-manuals project.   I
>  checked it in 3 stages
> 
>  1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're
>  running on Rackspace
>  2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared
>  on OpenStack
>  3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> 
>  I did this so that you can run diffs against the three versions and see
>  exactly what's changed.  From now on all changes are going directly into
>  Launchpad.
> 
>  I've gotten a lot of suggestions over the past couple of weeks, and I've
>  tried to take them all into account.  There are still a couple of
>  changes coming based on those suggestions but they're not very big --
>  mostly cosmetic.
> 
>  I realize we're still having a debate about "affinity id".  Affinity id
>  is still mentioned in the spec, but I'm totally open to removing it if
>  we decide that's not the best approach.
> 
>  I appreciate your input.  You can contribute by leaving comments in the
>  WebHelp version (I don't think enterpad is going to work for this sort
>  of thing).  Or if  you find something broken, or want to make another
>  change, you can make changes to the openstack-manuals project submit a
>  merge request.
> 
>  Thanks,
> 
>  jOrGe W.
> 
>  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


___
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] Entities in OpenStack Auth

[Eric Day]

Hi Brian,

The proposal abstracts 'users' and 'projects' to just 'entities',
although we may want to use 'accounts' since this already maps to how
swift works. So a user is an account, a project is an account, and
accounts can give access to other accounts (possibly with specific
roles). Therefore the query to list all servers in "project1" is
really deployment specific, and could just be:

GET http://nova.openstack.org/v1.1/project1/servers

Which is just an application of the generic:

GET http://nova.openstack.org/v1.1//servers

As I mentioned before, we'll probably want search options for depth
so it can include nested accounts and filters. For example:

GET http://nova.openstack.org/v1.1/user1/servers?depth=2&filter=proj1,proj2

Here user1, proj1, and proj2 are all account names.

As for unique IDs, this again is something we should probably try to
be consistent on across services. With nova today, ID's are only unique
within a cluster (shared DB instance), so two clusters would currently
clash. We need something more than just a unique ID when we start
connecting public and private clouds. You can't control the unique ID
generation so a bad private cloud could start duplicating 'unique'
ID's on purpose. We need some namespace to prevent these collisions
and limit the damage, and account seems like the most appropriate
(and matches what Swift does, so there is some consistency).

-Eric

On Wed, Mar 02, 2011 at 01:45:43PM -0500, Brian Lamar wrote:
> I like this idea, but I have some concerns about the feasibility of 
> successfully differentiating between users and projects. While it's easy to 
> query one data store and then the next, perhaps we can avoid this issue by 
> assigning unique identifiers to resources?
> 
> Show all servers in project1:
>  GET http://nova.openstack.org/v1.1/servers?project=project1
> 
> Show "Instance X":
>  GET http://nova.openstack.org/v1.1/servers/-F5*ovBi-=rYdW3leIGY
> 
> Show all servers available to current user:
>  GET http://nova.openstack.org/v1.1/servers
> 
> Unique identifiers for items, while many feel they are cumbersome, provide a 
> couple benefits I can think of off the top of my head:
> 
> 1) Easy permalinks (ability to re-name everything else about the server 
> without worrying about the URL changing)
> 
> 2) Public URLs no longer need any other identifying information because they 
> are now unique.
> 
> Problems include things like me not knowing the intricacies of the OpenStack 
> database which might make my first example more difficult. Also, some people 
> like URLs to be readable and/or memorable.
> 
> 
> -Original Message-
> From: "Eric Day" 
> Sent: Tuesday, March 1, 2011 9:14pm
> To: "Justin Santa Barbara" 
> Cc: openstack@lists.launchpad.net
> Subject: Re: [Openstack] Entities in OpenStack Auth
> 
> For that query you would, but not all. If you want to create a new
> instance for project1 you would:
> 
> nova.openstack.org/v1.1/project1/servers
> 
> Or if you wanted to reboot instance X in project1:
> 
> nova.openstack.org/v1.1/project1/servers/X
> 
> Note that the following resource is not the same as the last, since
> justin wouldn't be the owner for instance X, project1 would be:
> 
> nova.openstack.org/v1.1/justin/servers/X
> 
> I think searches will always have special cases with filter options,
> but for identifying a canonical URL for a resource, having the entity
> name of the owner in there seems correct.
> 
> The main thing I'm trying to figure out is whether to use an extra
> entity in the path for new service URLs. Swift does and Nova does not,
> and it would be nice to have some consistency. I see the benefits of
> both, and in Swift's case it needs to for simple public URLs (where
> there is no user context).
> 
> -Eric
> 
> On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote:
> >If we're always going to pass the same user-id token (for a particular
> >user), what's the value in passing it at all?  Why not get it from the
> >authentication token?
> >e.g. my X-Auth-Token could look like:  "justinsb
> >project1,project2,project3 5OPr9UR2xk32K9ArAjO562e" (i.e. my username,
> >projects and a crypto signature)
> >Justin
> > 
> >On Tue, Mar 1, 2011 at 5:51 PM, Eric Day  wrote:
> > 
> >  Hi Justin,
> >  On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara wrote:
> >  >However, what I don't understand is how I can query my servers in
> >  project1
> >  >and project2 (but not those in project3). *The only way I could 
> > see
> >  is
> >  >doing something like this:
> >  >*nova.openstack.org/v1.1/project1+project2/servers.
> >  >I agree that REST paths aren't themselves hacky in the
> >  single-project
> >  >case, but I don't yet grok the multi-project query. *Of the 3
> >  options I do
> >  >grok, I see (c) as the least hacky.
> > 
> >  I would probably say use nova.openstack.org/v1.1/just

Re: [Openstack] server affinity

[Eric Day]

On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote:
> Wait, are we all in agreement that we need user-defined metadata and 
> service-specific metadata? I do agree that the data store isn't conducive to 
> adding arbitrary metadata due to the rigidness of our DB, but how often are 
> we going to be adding new attributes?
> 
> I guess my main question is where is the line between a new metadata 
> attribute and an instance-specific property? I suppose you could say then I'm 
> all for your third and final example.

The line is no core code in nova will ever look at user-metadata. If it
does need to, it should either be service-metadata or simply an object
property. There is a need for some deployments to define metadata
that can be used in the pluggable scheduler (as Justin mentioned,
things like GPU tags), but this should not be in the same namespace as
user-metadata or count against the user-metadata quota. Do we want to
require deployments to alter the DB schema, provide a service-metadata
table, or use reserved prefixes in the same table as user-metadata?

I'm split between the last two.

-Eric

> 
> -Original Message-
> From: "Eric Day" 
> Sent: Wednesday, March 2, 2011 12:43pm
> To: "Mark Washenberger" 
> Cc: "openstack@lists.launchpad.net" 
> Subject: Re: [Openstack] server affinity
> 
> Well said Jorge. I think we're all in agreement that we need a way
> to add both user-defined metadata and service-specific metadata (and
> possibly deployment-specific metadata). I think Justin was working
> on the metadata mechanisms assuming it would support both based on
> prefix. If we don't want to overload metadata and use prefixes to
> differentiate between users, providers, and so forth, we should add
> another collection to resources. For example:
> 
> metadata = [
>   "user:comment": "This is Eric's dev server"
>   "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]
> 
> Would become:
> 
> user_metadata = ["comment": "This is Eric's dev server"]
> service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"]
> 
> Or don't use metadata for service metadata at all and put directly
> in the instance object/record:
> 
> instance.id = 100
> instance.network = 42
> instance.affinity_id = rack4.dc2.east.rackspace.com
> # instance.metadata is user-defined metadata only.
> instance.metadata = ["comment": "This is Eric's dev server"]
> 
> Now the arguments stated by many folks is that "service_metadata"
> is really instance properties or instance attributes and should
> instead be part of the instance object/record directly (like size,
> flavor id, etc. are). I don't disagree, but unfortunately there is
> a little more overhead since we're using a structured data store,
> and this requires an alter table for every change at this point. It's
> more difficult to introduce, test, and remove service attributes. If
> we want deployments to be able to define service-specific metadata
> and use that in pluggable schedulers, a DB schema change is not a
> very elegant way to support this.
> 
> So the questions are:
> 
> Do we need to support variable service metadata? If so, where should
> it go?
> 
> If in a key/value list, should existing instance properties be moved
> into this format as well?
> 
> If in a key/value list, should it just be a prefix in a general
> metadata list (and user metadata has a 'user' prefix)?
> 
> -Eric
> 
> On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
> > > [W]e
> > > shouldn't be overloading that functionality by performing some action 
> > > based on
> > > user-defined metadata.
> > 
> > That is exactly what I've been trying to say, but you have stated it much 
> > more succinctly. Thanks!
> > 
> > My specific concern is with quotas. If the current osapi metadata is 
> > overloaded with api functionality, then it muddies the concept of quotas. 
> > Admins who run nova probably don't want the server affinity feature to 
> > count against the general metadata quota.
> > 
> > Because of this, I don't think server affinity should be part of the 
> > metadata (specifically defined as the metadata attribute in 
> > nova.compute.api.API::create). 
> > 
> > This doesn't really have any effect on which of Jorge's options we choose, 
> > though, so /unhijack.
> > 
> > "Jorge Williams"  said:
> > 
> > > Metadata in the OpenStack Compute/Cloud Servers  API is meant to describe 
> > > user
> > > defined properties.  That's it.  So in that case, I agree with Brian that 
> > > we
> > > shouldn't be overloading that functionality by performing some action 
> > > based on
> > > user-defined metadata.
> > > 
> > > Speaking more generally though, any attribute that you associate with a 
> > > resource
> > > can be thought of as metadata as well.  Isn't the name of an instance 
> > > metadata
> > > about the instance?  Should operators be able to define arbitrary 
> > > metadata and
> > > then be able to act on it in some way?  I think so, that's a very po

Re: [Openstack] server affinity

[Eric Day]

On Wed, Mar 02, 2011 at 10:27:33AM -0800, Justin Santa Barbara wrote:
>I'm not wedded to the idea of putting "service metadata" into the same
>collection as "user metadata"; it just seems like a reasonable approach to
>me. *But it's more important to me that we agree on something, than that
>we agree on the "best" thing!

Hopefully the two are the same. :)

>> If in a key/value list, should existing instance properties be
>moved*into this format as well?
>-1 (for now): We'd still have to support the separate properties for the
>front end APIs. *We'd probably not want to refactor the database schema.
>*However, the code can internally harmonize all the properties into a
>single collection, which might make routing & processing requests easier.
>*We could also support passing e.g. the instance types through the
>key/value collection instead of the 'legacy' explicit parameter method in
>the OpenStack API. However, I don't think we should change anything here
>yet, until we have a clear rationale for doing so. *(Though this rationale
>might arise quickly, e.g. multi-cluster-in-a-region)

Yeah, this is nasty and probably won't or shouldn't happen, but I
thought I'd mention it. We may want to define 'core-properties' as
those already in the instance table (along with others worthy of it)
and 'service-metadata' as things not referenced directly in the core
code, but used in plugin hooks like the scheduler. User-metadata is
never referenced by nova code.

>>*If in a key/value list, should it just be a prefix in a general*metadata
>list (and user metadata has a 'user' prefix)?
>+1, but I don't think that we should require user metadata to be prefixed
>(at least externally!) *We should reserve the "aws:" and "openstack:"
>prefixes asap. *I'm going to propose a doc change to reserve the "aws:"
>prefix - I think we have no choice in the matter, and I haven't seen any
>objections.

To clarify, the user would not need to apply the prefix or
ever see it, that's just an internal thing we add/remove when
processing requests. Without an internal prefix, a user could add
'openstack:...=...' and possibly confuse things, so always having an
internal prefix allows our metadata handling methods remain simple.

-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] server affinity

[Todd Willey]

I like prefixed names that are grouped in with user metadata.

On Wed, Mar 2, 2011 at 1:30 PM, Eric Day  wrote:
> On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote:
>> Wait, are we all in agreement that we need user-defined metadata and 
>> service-specific metadata? I do agree that the data store isn't conducive to 
>> adding arbitrary metadata due to the rigidness of our DB, but how often are 
>> we going to be adding new attributes?
>>
>> I guess my main question is where is the line between a new metadata 
>> attribute and an instance-specific property? I suppose you could say then 
>> I'm all for your third and final example.
>
> The line is no core code in nova will ever look at user-metadata. If it
> does need to, it should either be service-metadata or simply an object
> property. There is a need for some deployments to define metadata
> that can be used in the pluggable scheduler (as Justin mentioned,
> things like GPU tags), but this should not be in the same namespace as
> user-metadata or count against the user-metadata quota. Do we want to
> require deployments to alter the DB schema, provide a service-metadata
> table, or use reserved prefixes in the same table as user-metadata?
>
> I'm split between the last two.
>
> -Eric
>
>>
>> -Original Message-
>> From: "Eric Day" 
>> Sent: Wednesday, March 2, 2011 12:43pm
>> To: "Mark Washenberger" 
>> Cc: "openstack@lists.launchpad.net" 
>> Subject: Re: [Openstack] server affinity
>>
>> Well said Jorge. I think we're all in agreement that we need a way
>> to add both user-defined metadata and service-specific metadata (and
>> possibly deployment-specific metadata). I think Justin was working
>> on the metadata mechanisms assuming it would support both based on
>> prefix. If we don't want to overload metadata and use prefixes to
>> differentiate between users, providers, and so forth, we should add
>> another collection to resources. For example:
>>
>> metadata = [
>>   "user:comment": "This is Eric's dev server"
>>   "openstack:affinity_id": "rack4.dc2.east.rackspace.com"]
>>
>> Would become:
>>
>> user_metadata = ["comment": "This is Eric's dev server"]
>> service_metadata = ["openstack:affinity_id": "rack4.dc2.east.rackspace.com"]
>>
>> Or don't use metadata for service metadata at all and put directly
>> in the instance object/record:
>>
>> instance.id = 100
>> instance.network = 42
>> instance.affinity_id = rack4.dc2.east.rackspace.com
>> # instance.metadata is user-defined metadata only.
>> instance.metadata = ["comment": "This is Eric's dev server"]
>>
>> Now the arguments stated by many folks is that "service_metadata"
>> is really instance properties or instance attributes and should
>> instead be part of the instance object/record directly (like size,
>> flavor id, etc. are). I don't disagree, but unfortunately there is
>> a little more overhead since we're using a structured data store,
>> and this requires an alter table for every change at this point. It's
>> more difficult to introduce, test, and remove service attributes. If
>> we want deployments to be able to define service-specific metadata
>> and use that in pluggable schedulers, a DB schema change is not a
>> very elegant way to support this.
>>
>> So the questions are:
>>
>> Do we need to support variable service metadata? If so, where should
>> it go?
>>
>> If in a key/value list, should existing instance properties be moved
>> into this format as well?
>>
>> If in a key/value list, should it just be a prefix in a general
>> metadata list (and user metadata has a 'user' prefix)?
>>
>> -Eric
>>
>> On Wed, Mar 02, 2011 at 08:59:09AM -0500, Mark Washenberger wrote:
>> > > [W]e
>> > > shouldn't be overloading that functionality by performing some action 
>> > > based on
>> > > user-defined metadata.
>> >
>> > That is exactly what I've been trying to say, but you have stated it much 
>> > more succinctly. Thanks!
>> >
>> > My specific concern is with quotas. If the current osapi metadata is 
>> > overloaded with api functionality, then it muddies the concept of quotas. 
>> > Admins who run nova probably don't want the server affinity feature to 
>> > count against the general metadata quota.
>> >
>> > Because of this, I don't think server affinity should be part of the 
>> > metadata (specifically defined as the metadata attribute in 
>> > nova.compute.api.API::create).
>> >
>> > This doesn't really have any effect on which of Jorge's options we choose, 
>> > though, so /unhijack.
>> >
>> > "Jorge Williams"  said:
>> >
>> > > Metadata in the OpenStack Compute/Cloud Servers  API is meant to 
>> > > describe user
>> > > defined properties.  That's it.  So in that case, I agree with Brian 
>> > > that we
>> > > shouldn't be overloading that functionality by performing some action 
>> > > based on
>> > > user-defined metadata.
>> > >
>> > > Speaking more generally though, any attribute that you associate with a 
>> > > resource
>> > > can be thought of as metadata as well

Re: [Openstack] Entities in OpenStack Auth

[Glen Campbell]

According to the proposed API 1.1 spec, it *does* use an extra element in
the path to indicate the account; this is (presumably) returned by the
auth system:

http://servers.api.openstack.org/v1.1/1234/servers/12

Where "1234" is the account ID (actually a token, I believe) and "12" is
the server ID. 

See p. 5 of the latest API 1.1 doc.




On 3/1/11 8:14 PM, "Eric Day"  wrote:

>For that query you would, but not all. If you want to create a new
>instance for project1 you would:
>
>nova.openstack.org/v1.1/project1/servers
>
>Or if you wanted to reboot instance X in project1:
>
>nova.openstack.org/v1.1/project1/servers/X
>
>Note that the following resource is not the same as the last, since
>justin wouldn't be the owner for instance X, project1 would be:
>
>nova.openstack.org/v1.1/justin/servers/X
>
>I think searches will always have special cases with filter options,
>but for identifying a canonical URL for a resource, having the entity
>name of the owner in there seems correct.
>
>The main thing I'm trying to figure out is whether to use an extra
>entity in the path for new service URLs. Swift does and Nova does not,
>and it would be nice to have some consistency. I see the benefits of
>both, and in Swift's case it needs to for simple public URLs (where
>there is no user context).
>
>-Eric
>
>On Tue, Mar 01, 2011 at 06:00:12PM -0800, Justin Santa Barbara wrote:
>>If we're always going to pass the same user-id token (for a
>>particular
>>user), what's the value in passing it at all?  Why not get it from
>>the
>>authentication token?
>>e.g. my X-Auth-Token could look like:  "justinsb
>>project1,project2,project3 5OPr9UR2xk32K9ArAjO562e" (i.e. my
>>username,
>>projects and a crypto signature)
>>Justin
>> 
>>On Tue, Mar 1, 2011 at 5:51 PM, Eric Day  wrote:
>> 
>>  Hi Justin,
>>  On Tue, Mar 01, 2011 at 05:14:42PM -0800, Justin Santa Barbara
>>wrote:
>>  >However, what I don't understand is how I can query my
>>servers in
>>  project1
>>  >and project2 (but not those in project3). *The only way I
>>could see
>>  is
>>  >doing something like this:
>>  >*nova.openstack.org/v1.1/project1+project2/servers.
>>  >I agree that REST paths aren't themselves hacky in the
>>  single-project
>>  >case, but I don't yet grok the multi-project query. *Of the 3
>>  options I do
>>  >grok, I see (c) as the least hacky.
>> 
>>  I would probably say use nova.openstack.org/v1.1/justin/servers
>>with
>>  one or more filter parameters in the URL or body as you mention.
>>This
>>  something to consider across all services, not just nova. AFAIK
>>  Swift doesn't support queries across multiple accounts right now,
>>  so I'd like to hear their thoughts on it as well.
>>  -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



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] Entities in OpenStack Auth

[Eric Day]

On Wed, Mar 02, 2011 at 07:43:08PM +, Glen Campbell wrote:
> According to the proposed API 1.1 spec, it *does* use an extra element in
> the path to indicate the account; this is (presumably) returned by the
> auth system:
> 
> http://servers.api.openstack.org/v1.1/1234/servers/12
> 
> Where "1234" is the account ID (actually a token, I believe) and "12" is
> the server ID. 
> 
> See p. 5 of the latest API 1.1 doc.

Thanks, I saw Jorge pointed that out earlier as well. With that,
this discussion is more focused on how this maps to 'users' and
'projects' in nova and how to list servers (or any resource) across
multiple accounts.

> On 3/1/11 8:14 PM, "Eric Day"  wrote:
> 
> >For that query you would, but not all. If you want to create a new
> >instance for project1 you would:
> >
> >nova.openstack.org/v1.1/project1/servers
> >
> >Or if you wanted to reboot instance X in project1:
> >
> >nova.openstack.org/v1.1/project1/servers/X
> >
> >Note that the following resource is not the same as the last, since
> >justin wouldn't be the owner for instance X, project1 would be:
> >
> >nova.openstack.org/v1.1/justin/servers/X
> >
> >I think searches will always have special cases with filter options,
> >but for identifying a canonical URL for a resource, having the entity
> >name of the owner in there seems correct.
> >
> >The main thing I'm trying to figure out is whether to use an extra
> >entity in the path for new service URLs. Swift does and Nova does not,
> >and it would be nice to have some consistency. I see the benefits of
> >both, and in Swift's case it needs to for simple public URLs (where
> >there is no user context).
> >
> >-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 Compute API for Cactus (critical!)

[Eric Day]

I havn't seen much activity on this, so though I'd do a quick brain
dump of what I'm aware of:


Auth/global:
* Ability to lockout a user for some time period after failed auth.
* Describe zones and regions (replaced with Sandy's zone work).

Admin
* Describe instance types (list flavors).
* CRUD users and projects (should not be in nova, should be in common
  auth middleware/server project).
* Associate roles between users and projects (probably belongs in
  common auth project too).

Compute
* CRUD key pairs.
* Reference stored key pairs for injection.
* Console output (this is just a dump, not an ajax console).
* Ajax console works differently between ec2 and OS (I think).
* Metadata handler for booting instances. Not needed if we switch to
  only using guest agents or injection.
* Attach and detach volumes.
* Attach and detach floating IP addresses (this is not the same as
  shared IP groups).
* Associate and disassociate with network security groups.
* Connect with VPNs.

Network
* CRUD floating IP addresses.
* CRUD security groups.
* CRUD VPNs

Volume
* CRUD Volumes.


I'm not sure if image management via new glance and what ec2 provides
is ready yet, or if the semantics of all server actions are the
same. I'll let the reseident experts weigh in there.

-Eric

On Mon, Feb 28, 2011 at 02:16:20PM -0600, John Purrier wrote:
>Has anyone done a gap analysis against the proposed OpenStack Compute API
>and a) the implemented code, and b) the EC2 API?
> 
> 
> 
>It looks like we have had a breakdown in process, as the community review
>process of the proposed spec has not generated discussion of the missing
>aspects of the proposed spec.
> 
> 
> 
>Here is what we said on Feb 3 as the goal for Cactus:
> 
> 
> 
>OpenStack Compute API completed. We need to complete a working set of
>API's that are consistent and inclusive of all the exposed functionality.
> 
> 
> 
>We need to *very* quickly identify the missing elements that are required
>in the OpenStack Compute API, and then discuss how we mobilize to get this
>work done for Cactus. As this is the #1 priority for this release there
>are implications on milestones dates depending on the results of this
>exercise. The 1.1 spec should be complete and expose all current Nova
>functionality (superset of EC2/RS).
> 
> 
> 
>Dendrobates, please take the lead on this, anyone who can help please
>coordinate with Rick. Can we get a fairly complete view by EOD tomorrow?
>Please set up a wiki page to identify the gaps, I suggest 3 columns
>(Actual code / EC2 / OpenStack Compute).
> 
> 
> 
>Thanks,
> 
> 
> 
>John

> ___
> 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 Compute 1.1

[Rick Clark]

Jorge,
I thought this was supposed released as Creative Commons.  All I can
find is the text below, which is not open.  I think this is not
appropriate for something released as a part of openstack.

Rick



API v1.1 (03/01/11)
Copyright © 2009-2011 Rackspace US, Inc. All rights reserved.
This document is intended for software developers interested in
developing applications using the OpenStack Compute Application
Programming Interface (API). The document is for informational purposes
only and is provided “AS IS.”
RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, AS TO THE ACCURACY OR
COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO
MAKE CHANGES TO SPECIFICATIONS AND
PRODUCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. RACKSPACE
SERVICES OFFERINGS ARE SUBJECT TO CHANGE
WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF
ANY SERVICES MENTIONED HEREIN. EXCEPT AS SET
FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS AND/OR CLOUD TERMS OF
SERVICE, RACKSPACE ASSUMES NO LIABILITY
WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO
ITS SERVICES INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NONINFRINGEMENT.
Except as expressly provided in any written license agreement from
Rackspace, the furnishing of this document does not give you any
license to patents, trademarks, copyrights, or other intellectual property.
Rackspace®, Rackspace logo and Fanatical Support® are registered service
marks of Rackspace US, Inc. All other product names and
trademarks used in this document are for identification purposes only
and are property of their respective owners.


On 03/02/2011 10:29 AM, Jorge Williams wrote:
> 
> Hey guys,
> 
> New version of OpenStack Compute 1.1 is out.
> 
> PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> 
> See the "Document Change History" section for a list of changes.
> 
> The API is now in Launchpad in the openstack-manuals project.   I checked it 
> in 3 stages
> 
> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running on 
> Rackspace
> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
> OpenStack 
> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> 
> I did this so that you can run diffs against the three versions and see 
> exactly what's changed.  From now on all changes are going directly into 
> Launchpad.
> 
> I've gotten a lot of suggestions over the past couple of weeks, and I've 
> tried to take them all into account.  There are still a couple of changes 
> coming based on those suggestions but they're not very big -- mostly cosmetic.
> 
> I realize we're still having a debate about "affinity id".  Affinity id is 
> still mentioned in the spec, but I'm totally open to removing it if we decide 
> that's not the best approach.
> 
> I appreciate your input.  You can contribute by leaving comments in the 
> WebHelp version (I don't think enterpad is going to work for this sort of 
> thing).  Or if  you find something broken, or want to make another change, 
> you can make changes to the openstack-manuals project submit a merge request.
> 
> Thanks,
> 
> jOrGe W.
> 
> 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




signature.asc
Description: OpenPGP digital signature
___
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] State of OpenStack Auth

[Soren Hansen]

2011/3/2 Michael Barton :
> HMAC is sort of appealing for Swift, since it'd let people choose to
> use HTTP instead of HTTPS for data that's not sensitive.

I'd like to just mention this blog post:

   http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

tl;dr quote:

If you stop reading now you only need to remember one thing:
SSL/TLS is not computationally expensive any more.


Just sayin'. :)


-- 
Soren Hansen
Ubuntu Developer    http://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] Management API

[Glen Campbell]

There's been some discussion of an admin/management API and what functions 
would be provided there. I've been tasked with handling the technical 
coordination of implementing Nova at Rackspace, and have thus been identifying 
gaps between functionality that our current system provides and those provided 
by Nova.

I've created a preliminary proposal at http://wiki.openstack.org/NovaAdminAPI – 
this is still somewhat early, but I want to make sure that the OpenStack 
community has the opportunity to provide feedback.

My expectations are that management API features will fall into two categories: 
(1) those that would be generally useful to anyone who deploys OpenStack 
Compute, and (2) those that are specific to Rackspace's needs (or perhaps 
another service provider). One of the goals of this discussion is to identify 
those different features. While all these features will initially be 
implemented using the API 1.1 extensions mechanism, those that fall into 
category (1) may be migrated to Nova-core in the near future, while (2) will 
remain Rackspace-specific extensions.

Glen Campbell



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] State of OpenStack Auth

[Michael Barton]

On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen  wrote:
> I'd like to just mention this blog post:
>
>   http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
> tl;dr quote:
>
>    If you stop reading now you only need to remember one thing:
>    SSL/TLS is not computationally expensive any more.

Oh, thank goodness.  I had this dream where it took a non-trivial
amount of infrastructure to get many tens of gbps of SSL throughput.

- Mike

___
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] OS API server password generation

[Dan Prince]

We created a blueprint on adding support for password generation when creating 
servers. This is needed for Openstack API/Cloud Servers API v1.0 parity.

We are anxious to get this work started so if you are interested please review 
the following:
 
 https://blueprints.launchpad.net/nova/+spec/openstack-api-server-passwords
 
 http://etherpad.openstack.org/openstack-api-server-passwords

Dan Prince


___
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] State of OpenStack Auth

[Soren Hansen]

2011/3/2 Michael Barton :
> On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen  wrote:
>> I'd like to just mention this blog post:
>>
>>   http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> tl;dr quote:
>>
>>    If you stop reading now you only need to remember one thing:
>>    SSL/TLS is not computationally expensive any more.
> Oh, thank goodness.  I had this dream where it took a non-trivial
> amount of infrastructure to get many tens of gbps of SSL throughput.

Oh, how I love sarcasm.

I don't know this for a fact, since I have no way to measure how much
traffic various companies generate, but I get the impression Google
deals with a fair bit of network traffic. At least enough that I pay
attention when they're sharing their experiences in doing so. Their
analysis looks pretty good. Can you point out some of the weak spots
or perhaps explain why it doesn't apply to our use cases?

-- 
Soren Hansen
Ubuntu Developer    http://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

Re: [Openstack] OpenStack Compute 1.1

[Anne Gentle]

Ok, you win the sharp eyes award. :) The front cover also has the Rackspace
logo rather than the OpenStack logo. The PDF just needs to be re-built using
the Apache license indicator. Jorge built that output capability for
OpenStack specifically, but he just didn't re-run the PDF build yet - we
noticed it and decided to push the PDF out anyway in the interest of time.
Look for an updated PDF with the correct licensing indicated.

Anne

*Anne Gentle*
a...@openstack.org
 my blog  | my
book|
LinkedIn  |
Delicious|
Twitter 
On Wed, Mar 2, 2011 at 2:27 PM, Rick Clark  wrote:

> Jorge,
> I thought this was supposed released as Creative Commons.  All I can
> find is the text below, which is not open.  I think this is not
> appropriate for something released as a part of openstack.
>
> Rick
>
>
>
> API v1.1 (03/01/11)
> Copyright © 2009-2011 Rackspace US, Inc. All rights reserved.
> This document is intended for software developers interested in
> developing applications using the OpenStack Compute Application
> Programming Interface (API). The document is for informational purposes
> only and is provided “AS IS.”
> RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR
> IMPLIED, AS TO THE ACCURACY OR
> COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO
> MAKE CHANGES TO SPECIFICATIONS AND
> PRODUCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. RACKSPACE
> SERVICES OFFERINGS ARE SUBJECT TO CHANGE
> WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF
> ANY SERVICES MENTIONED HEREIN. EXCEPT AS SET
> FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS AND/OR CLOUD TERMS OF
> SERVICE, RACKSPACE ASSUMES NO LIABILITY
> WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO
> ITS SERVICES INCLUDING, BUT NOT LIMITED
> TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
> PURPOSE, AND NONINFRINGEMENT.
> Except as expressly provided in any written license agreement from
> Rackspace, the furnishing of this document does not give you any
> license to patents, trademarks, copyrights, or other intellectual property.
> Rackspace®, Rackspace logo and Fanatical Support® are registered service
> marks of Rackspace US, Inc. All other product names and
> trademarks used in this document are for identification purposes only
> and are property of their respective owners.
>
>
> On 03/02/2011 10:29 AM, Jorge Williams wrote:
> >
> > Hey guys,
> >
> > New version of OpenStack Compute 1.1 is out.
> >
> > PDF:
> http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> > WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> >
> > See the "Document Change History" section for a list of changes.
> >
> > The API is now in Launchpad in the openstack-manuals project.   I checked
> it in 3 stages
> >
> > 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're
> running on Rackspace
> > 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on
> OpenStack
> > 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> >
> > I did this so that you can run diffs against the three versions and see
> exactly what's changed.  From now on all changes are going directly into
> Launchpad.
> >
> > I've gotten a lot of suggestions over the past couple of weeks, and I've
> tried to take them all into account.  There are still a couple of changes
> coming based on those suggestions but they're not very big -- mostly
> cosmetic.
> >
> > I realize we're still having a debate about "affinity id".  Affinity id
> is still mentioned in the spec, but I'm totally open to removing it if we
> decide that's not the best approach.
> >
> > I appreciate your input.  You can contribute by leaving comments in the
> WebHelp version (I don't think enterpad is going to work for this sort of
> thing).  Or if  you find something broken, or want to make another change,
> you can make changes to the openstack-manuals project submit a merge
> request.
> >
> > Thanks,
> >
> > jOrGe W.
> >
> > 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
> > Unsubs

Re: [Openstack] server affinity

[Jorge Williams]

On Mar 2, 2011, at 11:43 AM, Eric Day wrote:

> Now the arguments stated by many folks is that "service_metadata"
> is really instance properties or instance attributes and should
> instead be part of the instance object/record directly (like size,
> flavor id, etc. are). I don't disagree, but unfortunately there is
> a little more overhead since we're using a structured data store,
> and this requires an alter table for every change at this point.
> It's more difficult to introduce, test, and remove service attributes. If
> we want deployments to be able to define service-specific metadata
> and use that in pluggable schedulers, a DB schema change is not a
> very elegant way to support this.

How you store the data internally and how you present it in the API are two 
different issues.  You don't necessarily have to store extension data where you 
store standard attributes in order to present things as instance properties. 
You can store this data in a completely different table or in a flat file, or 
in memory, whatever.  You can have middle ware that inserts it into the object 
before you present it to the user.  In fact this is a big plus because it makes 
extensions plug-able and because it allows each one to map it's data as it sees 
fit.


-jOrGe W.


___
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] server affinity

[Eric Day]

On Wed, Mar 02, 2011 at 09:48:27PM +, Jorge Williams wrote:
> On Mar 2, 2011, at 11:43 AM, Eric Day wrote:
> > Now the arguments stated by many folks is that "service_metadata"
> > is really instance properties or instance attributes and should
> > instead be part of the instance object/record directly (like size,
> > flavor id, etc. are). I don't disagree, but unfortunately there is
> > a little more overhead since we're using a structured data store,
> > and this requires an alter table for every change at this point.
> > It's more difficult to introduce, test, and remove service attributes. If
> > we want deployments to be able to define service-specific metadata
> > and use that in pluggable schedulers, a DB schema change is not a
> > very elegant way to support this.
> 
> How you store the data internally and how you present it in the API are two 
> different issues.  You don't necessarily have to store extension data where 
> you store standard attributes in order to present things as instance 
> properties. You can store this data in a completely different table or in a 
> flat file, or in memory, whatever.  You can have middle ware that inserts it 
> into the object before you present it to the user.  In fact this is a big 
> plus because it makes extensions plug-able and because it allows each one to 
> map it's data as it sees fit.

Agreed, but we're talking about how to actually store both in
nova. Justin added a metadata table in the nova.db SQL schema, but
we're trying to decide if that should be user only (and add another
table) or both user and service with prefixes. The 1.1 API spec won't
change either way.

-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] server affinity

[Jorge Williams]

On Mar 2, 2011, at 3:54 PM, Eric Day wrote:

> On Wed, Mar 02, 2011 at 09:48:27PM +, Jorge Williams wrote:
>> On Mar 2, 2011, at 11:43 AM, Eric Day wrote:
>>> Now the arguments stated by many folks is that "service_metadata"
>>> is really instance properties or instance attributes and should
>>> instead be part of the instance object/record directly (like size,
>>> flavor id, etc. are). I don't disagree, but unfortunately there is
>>> a little more overhead since we're using a structured data store,
>>> and this requires an alter table for every change at this point.
>>> It's more difficult to introduce, test, and remove service attributes. If
>>> we want deployments to be able to define service-specific metadata
>>> and use that in pluggable schedulers, a DB schema change is not a
>>> very elegant way to support this.
>> 
>> How you store the data internally and how you present it in the API are two 
>> different issues.  You don't necessarily have to store extension data where 
>> you store standard attributes in order to present things as instance 
>> properties. You can store this data in a completely different table or in a 
>> flat file, or in memory, whatever.  You can have middle ware that inserts it 
>> into the object before you present it to the user.  In fact this is a big 
>> plus because it makes extensions plug-able and because it allows each one to 
>> map it's data as it sees fit.
> 
> Agreed, but we're talking about how to actually store both in
> nova. Justin added a metadata table in the nova.db SQL schema, but
> we're trying to decide if that should be user only (and add another
> table) or both user and service with prefixes. The 1.1 API spec won't
> change either way.
> 
> -Eric

Got 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] OpenStack Compute 1.1

[Jorge Williams]

https://launchpad.net/openstack-manuals

On Mar 2, 2011, at 10:42 AM, Justin Santa Barbara wrote:

Looks like some good changes.  Where is this in launchpad, so the community can 
help develop it?  For example, I'm willing to document the reservation of the 
aws: prefix.

Justin




On Wed, Mar 2, 2011 at 8:29 AM, Jorge Williams 
mailto:jorge.willi...@rackspace.com>> wrote:

Hey guys,

New version of OpenStack Compute 1.1 is out.

PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
WebHelp: http://docs.openstack.org/openstack-compute/developer/content/

See the "Document Change History" section for a list of changes.

The API is now in Launchpad in the openstack-manuals project.   I checked it in 
3 stages

1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running on 
Rackspace
2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
OpenStack
3) Open Stack Compute 1.1 (3/1/11):  This is the current version

I did this so that you can run diffs against the three versions and see exactly 
what's changed.  From now on all changes are going directly into Launchpad.

I've gotten a lot of suggestions over the past couple of weeks, and I've tried 
to take them all into account.  There are still a couple of changes coming 
based on those suggestions but they're not very big -- mostly cosmetic.

I realize we're still having a debate about "affinity id".  Affinity id is 
still mentioned in the spec, but I'm totally open to removing it if we decide 
that's not the best approach.

I appreciate your input.  You can contribute by leaving comments in the WebHelp 
version (I don't think enterpad is going to work for this sort of thing).  Or 
if  you find something broken, or want to make another change, you can make 
changes to the openstack-manuals project submit a merge request.

Thanks,

jOrGe W.

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




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] OpenStack Compute 1.1

[Jorge Williams]

I'd prefer the comments sections so that we have a reference when we discuss. 
But hey, I'll take suggestions from anywhere :-)

-jOrGe W.

On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:

> Should comments/suggestions go in this email thread or in the comments 
> sections of the web help?  I hate to spam this list :)
> 
> Mike
> 
> On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
> 
>> 
>> Hey guys,
>> 
>> New version of OpenStack Compute 1.1 is out.
>> 
>> PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
>> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
>> 
>> See the "Document Change History" section for a list of changes.
>> 
>> The API is now in Launchpad in the openstack-manuals project.   I checked it 
>> in 3 stages
>> 
>> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running 
>> on Rackspace
>> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
>> OpenStack 
>> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
>> 
>> I did this so that you can run diffs against the three versions and see 
>> exactly what's changed.  From now on all changes are going directly into 
>> Launchpad.
>> 
>> I've gotten a lot of suggestions over the past couple of weeks, and I've 
>> tried to take them all into account.  There are still a couple of changes 
>> coming based on those suggestions but they're not very big -- mostly 
>> cosmetic.
>> 
>> I realize we're still having a debate about "affinity id".  Affinity id is 
>> still mentioned in the spec, but I'm totally open to removing it if we 
>> decide that's not the best approach.
>> 
>> I appreciate your input.  You can contribute by leaving comments in the 
>> WebHelp version (I don't think enterpad is going to work for this sort of 
>> thing).  Or if  you find something broken, or want to make another change, 
>> you can make changes to the openstack-manuals project submit a merge request.
>> 
>> Thanks,
>> 
>> jOrGe W.
>> 
>> 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
> 
> Mike Mayo
> 901-299-9306
> @greenisus
> 
> 
> 



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] OpenStack Compute API for Cactus (critical!)

[Devin Carlen]

added a few inline

On Mar 2, 2011, at 12:24 PM, Eric Day wrote:

> I havn't seen much activity on this, so though I'd do a quick brain
> dump of what I'm aware of:
> 
> 
> Auth/global:
> * Ability to lockout a user for some time period after failed auth.
> * Describe zones and regions (replaced with Sandy's zone work).
> 
> Admin
> * Describe instance types (list flavors).
> * CRUD users and projects (should not be in nova, should be in common
>  auth middleware/server project).
> * Associate roles between users and projects (probably belongs in
>  common auth project too).
* Start/stop/list running vpns (cloudpipe)

> 
> Compute
> * CRUD key pairs.
> * Reference stored key pairs for injection.
> * Console output (this is just a dump, not an ajax console).
> * Ajax console works differently between ec2 and OS (I think).
> * Metadata handler for booting instances. Not needed if we switch to
>  only using guest agents or injection.
> * Attach and detach volumes.
> * Attach and detach floating IP addresses (this is not the same as
>  shared IP groups).
> * Associate and disassociate with network security groups.
> * Connect with VPNs.
> 
> Network
> * CRUD floating IP addresses.
> * CRUD security groups.
> * CRUD VPNs
> 
> Volume
> * CRUD Volumes.

Security Groups (dashboard supports but is disabled at the moment)
* CRUD Security Groups
* CRUD Authorization rules

> 
> 
> I'm not sure if image management via new glance and what ec2 provides
> is ready yet, or if the semantics of all server actions are the
> same. I'll let the reseident experts weigh in there.
> 
> -Eric
> 
> On Mon, Feb 28, 2011 at 02:16:20PM -0600, John Purrier wrote:
>>   Has anyone done a gap analysis against the proposed OpenStack Compute API
>>   and a) the implemented code, and b) the EC2 API?
>> 
>> 
>> 
>>   It looks like we have had a breakdown in process, as the community review
>>   process of the proposed spec has not generated discussion of the missing
>>   aspects of the proposed spec.
>> 
>> 
>> 
>>   Here is what we said on Feb 3 as the goal for Cactus:
>> 
>> 
>> 
>>   OpenStack Compute API completed. We need to complete a working set of
>>   API's that are consistent and inclusive of all the exposed functionality.
>> 
>> 
>> 
>>   We need to *very* quickly identify the missing elements that are required
>>   in the OpenStack Compute API, and then discuss how we mobilize to get this
>>   work done for Cactus. As this is the #1 priority for this release there
>>   are implications on milestones dates depending on the results of this
>>   exercise. The 1.1 spec should be complete and expose all current Nova
>>   functionality (superset of EC2/RS).
>> 
>> 
>> 
>>   Dendrobates, please take the lead on this, anyone who can help please
>>   coordinate with Rick. Can we get a fairly complete view by EOD tomorrow?
>>   Please set up a wiki page to identify the gaps, I suggest 3 columns
>>   (Actual code / EC2 / OpenStack Compute).
>> 
>> 
>> 
>>   Thanks,
>> 
>> 
>> 
>>   John
> 
>> ___
>> 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


___
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 Compute 1.1

[Justin Santa Barbara]

Thanks.  Merge proposed :-)
https://code.launchpad.net/~justin-fathomdb/openstack-manuals/doc-reserve-metadata-prefix/+merge/51974

Justin




On Wed, Mar 2, 2011 at 2:16 PM, Jorge Williams  wrote:

>  https://launchpad.net/openstack-manuals
>
>  On Mar 2, 2011, at 10:42 AM, Justin Santa Barbara wrote:
>
>  Looks like some good changes.  Where is this in launchpad, so the
> community can help develop it?  For example, I'm willing to document the
> reservation of the aws: prefix.
>
>  Justin
>
>
>
>
> On Wed, Mar 2, 2011 at 8:29 AM, Jorge Williams <
> jorge.willi...@rackspace.com> wrote:
>
>>
>> Hey guys,
>>
>> New version of OpenStack Compute 1.1 is out.
>>
>> PDF:
>> http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
>> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
>>
>> See the "Document Change History" section for a list of changes.
>>
>> The API is now in Launchpad in the openstack-manuals project.   I checked
>> it in 3 stages
>>
>> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running
>> on Rackspace
>> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on
>> OpenStack
>> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
>>
>> I did this so that you can run diffs against the three versions and see
>> exactly what's changed.  From now on all changes are going directly into
>> Launchpad.
>>
>> I've gotten a lot of suggestions over the past couple of weeks, and I've
>> tried to take them all into account.  There are still a couple of changes
>> coming based on those suggestions but they're not very big -- mostly
>> cosmetic.
>>
>> I realize we're still having a debate about "affinity id".  Affinity id is
>> still mentioned in the spec, but I'm totally open to removing it if we
>> decide that's not the best approach.
>>
>> I appreciate your input.  You can contribute by leaving comments in the
>> WebHelp version (I don't think enterpad is going to work for this sort of
>> thing).  Or if  you find something broken, or want to make another change,
>> you can make changes to the openstack-manuals project submit a merge
>> request.
>>
>> Thanks,
>>
>> jOrGe W.
>>
>> 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
>>
>
>
> 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] OpenStack Compute 1.1

[Justin Santa Barbara]

Surely we should work on LaunchPad, just like the rest of the OpenStack
deliverables?

I just filed a merge proposal, so we'll see if this process works!


On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams  wrote:

> I'd prefer the comments sections so that we have a reference when we
> discuss. But hey, I'll take suggestions from anywhere :-)
>
> -jOrGe W.
>
> On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:
>
> > Should comments/suggestions go in this email thread or in the comments
> sections of the web help?  I hate to spam this list :)
> >
> > Mike
> >
> > On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
> >
> >>
> >> Hey guys,
> >>
> >> New version of OpenStack Compute 1.1 is out.
> >>
> >> PDF:
> http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> >> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> >>
> >> See the "Document Change History" section for a list of changes.
> >>
> >> The API is now in Launchpad in the openstack-manuals project.   I
> checked it in 3 stages
> >>
> >> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're
> running on Rackspace
> >> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared
> on OpenStack
> >> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> >>
> >> I did this so that you can run diffs against the three versions and see
> exactly what's changed.  From now on all changes are going directly into
> Launchpad.
> >>
> >> I've gotten a lot of suggestions over the past couple of weeks, and I've
> tried to take them all into account.  There are still a couple of changes
> coming based on those suggestions but they're not very big -- mostly
> cosmetic.
> >>
> >> I realize we're still having a debate about "affinity id".  Affinity id
> is still mentioned in the spec, but I'm totally open to removing it if we
> decide that's not the best approach.
> >>
> >> I appreciate your input.  You can contribute by leaving comments in the
> WebHelp version (I don't think enterpad is going to work for this sort of
> thing).  Or if  you find something broken, or want to make another change,
> you can make changes to the openstack-manuals project submit a merge
> request.
> >>
> >> Thanks,
> >>
> >> jOrGe W.
> >>
> >> 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
> >
> > Mike Mayo
> > 901-299-9306
> > @greenisus
> >
> >
> >
>
>
>
> 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 Compute 1.1

[Jorge Williams]

Absolutely if you have changes to the doc make a merge proposal.  I'm still 
getting used to the process, but I'll review.

If you just want to discuss or make a suggestion or whatever use the comments 
section.

-jOrGe W.

On Mar 2, 2011, at 4:25 PM, Justin Santa Barbara wrote:

Surely we should work on LaunchPad, just like the rest of the OpenStack 
deliverables?

I just filed a merge proposal, so we'll see if this process works!


On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams 
mailto:jorge.willi...@rackspace.com>> wrote:
I'd prefer the comments sections so that we have a reference when we discuss. 
But hey, I'll take suggestions from anywhere :-)

-jOrGe W.

On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:

> Should comments/suggestions go in this email thread or in the comments 
> sections of the web help?  I hate to spam this list :)
>
> Mike
>
> On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
>
>>
>> Hey guys,
>>
>> New version of OpenStack Compute 1.1 is out.
>>
>> PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
>> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
>>
>> See the "Document Change History" section for a list of changes.
>>
>> The API is now in Launchpad in the openstack-manuals project.   I checked it 
>> in 3 stages
>>
>> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running 
>> on Rackspace
>> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
>> OpenStack
>> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
>>
>> I did this so that you can run diffs against the three versions and see 
>> exactly what's changed.  From now on all changes are going directly into 
>> Launchpad.
>>
>> I've gotten a lot of suggestions over the past couple of weeks, and I've 
>> tried to take them all into account.  There are still a couple of changes 
>> coming based on those suggestions but they're not very big -- mostly 
>> cosmetic.
>>
>> I realize we're still having a debate about "affinity id".  Affinity id is 
>> still mentioned in the spec, but I'm totally open to removing it if we 
>> decide that's not the best approach.
>>
>> I appreciate your input.  You can contribute by leaving comments in the 
>> WebHelp version (I don't think enterpad is going to work for this sort of 
>> thing).  Or if  you find something broken, or want to make another change, 
>> you can make changes to the openstack-manuals project submit a merge request.
>>
>> Thanks,
>>
>> jOrGe W.
>>
>> 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
>
> Mike Mayo
> 901-299-9306
> @greenisus
>
>
>



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




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: 

[Openstack] Multiple Versions in Openstack API

[Brian Waldon]

Currently, the Openstack API includes a Versions WSGI application. The intended 
purpose is to detail all versions of the API that are reachable by a client. 
Currently, it only supports "v1.0." As we move towards the Cactus release, we 
need to add support for the new "v1.1" specification. The intention of the 
Versions app seems to be to deploy multiple versions of the OS API within the 
same codebase. Since these two versions have significant differences, having to 
support each in the same code seems unnatural.
 
With the existing approach, versioning could be accomplished multiple ways: 
version-specific "if" statements, version-specific class hierarchies, etc. I 
feel this is inelegant and could be accomplished a much cleaner way. I propose 
we move the responsibilities of the Versions app out of the nova codebase and 
into the hands of the operator of the api endpoints. With this approach, the 
code would not unnecessarily increase in complexity as more versions of the api 
are released. The major drawback of this strategy is that each release of 
Openstack Compute could support a single OS API version.
 
As we are slated to have our first multi-version OS API release in Cactus, I 
would like to see us reach a consensus as soon as posible. Any and all feedback 
is welcome!
 
Brian Waldon___
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 Compute 1.1

[Michael Mayo]

I have no idea how to work with docbkx, and my suggestions/questions will be 
scattered throughout the API, so a merge probably wouldn't make sense in my 
case.  I'm going to go with comments on WebHelp for now unless folks don't like 
that.

Basically, I'm coming at this from an API consumer/usability perspective.  


On Mar 2, 2011, at 2:25 PM, Justin Santa Barbara wrote:

> Surely we should work on LaunchPad, just like the rest of the OpenStack 
> deliverables?
> 
> I just filed a merge proposal, so we'll see if this process works!
> 
> 
> On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams  
> wrote:
> I'd prefer the comments sections so that we have a reference when we discuss. 
> But hey, I'll take suggestions from anywhere :-)
> 
> -jOrGe W.
> 
> On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:
> 
> > Should comments/suggestions go in this email thread or in the comments 
> > sections of the web help?  I hate to spam this list :)
> >
> > Mike
> >
> > On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
> >
> >>
> >> Hey guys,
> >>
> >> New version of OpenStack Compute 1.1 is out.
> >>
> >> PDF:  http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
> >> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
> >>
> >> See the "Document Change History" section for a list of changes.
> >>
> >> The API is now in Launchpad in the openstack-manuals project.   I checked 
> >> it in 3 stages
> >>
> >> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're running 
> >> on Rackspace
> >> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
> >> OpenStack
> >> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
> >>
> >> I did this so that you can run diffs against the three versions and see 
> >> exactly what's changed.  From now on all changes are going directly into 
> >> Launchpad.
> >>
> >> I've gotten a lot of suggestions over the past couple of weeks, and I've 
> >> tried to take them all into account.  There are still a couple of changes 
> >> coming based on those suggestions but they're not very big -- mostly 
> >> cosmetic.
> >>
> >> I realize we're still having a debate about "affinity id".  Affinity id is 
> >> still mentioned in the spec, but I'm totally open to removing it if we 
> >> decide that's not the best approach.
> >>
> >> I appreciate your input.  You can contribute by leaving comments in the 
> >> WebHelp version (I don't think enterpad is going to work for this sort of 
> >> thing).  Or if  you find something broken, or want to make another change, 
> >> you can make changes to the openstack-manuals project submit a merge 
> >> request.
> >>
> >> Thanks,
> >>
> >> jOrGe W.
> >>
> >> 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
> >
> > Mike Mayo
> > 901-299-9306
> > @greenisus
> >
> >
> >
> 
> 
> 
> 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
> 

Mike Mayo
901-299-9306
@greenisus



___
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] OS API server password generation

[Ed Leafe]

On Mar 2, 2011, at 4:11 PM, Dan Prince wrote:

> We created a blueprint on adding support for password generation when 
> creating servers. This is needed for Openstack API/Cloud Servers API v1.0 
> parity.
> 
> We are anxious to get this work started so if you are interested please 
> review the following:
>  
> https://blueprints.launchpad.net/nova/+spec/openstack-api-server-passwords
>  
> http://etherpad.openstack.org/openstack-api-server-passwords

There is a basic password generator in nova/utils.py. It returns a 
combination of digits and letters to whatever length you request. There is no 
pretension of being the last word in high security, but it should be equivalent 
to the current default password generation in Cloud Servers.



-- 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] OS API server password generation

[Justin Santa Barbara]

I think we need the option _not_ to inject a password (e.g. if I'm on Linux
and am going to use SSH private keys, or if I have another higher-security
means of accessing my server)  Does the API support this (yet)?

Also, I know security through obscurity isn't really security, but if we're
open source, I think we must have "strong" password generation, whatever may
or may not have been the case in the past.  I suggest beefing up the
generate_password function to make use of os.urandom (which I know isn't
perfect either, but is probably secure enough for anyone willing to rely on
a password)

Justin




On Wed, Mar 2, 2011 at 4:52 PM, Ed Leafe  wrote:

> On Mar 2, 2011, at 4:11 PM, Dan Prince wrote:
>
> > We created a blueprint on adding support for password generation when
> creating servers. This is needed for Openstack API/Cloud Servers API v1.0
> parity.
> >
> > We are anxious to get this work started so if you are interested please
> review the following:
> >
> >
> https://blueprints.launchpad.net/nova/+spec/openstack-api-server-passwords
> >
> > http://etherpad.openstack.org/openstack-api-server-passwords
>
> There is a basic password generator in nova/utils.py. It returns a
> combination of digits and letters to whatever length you request. There is
> no pretension of being the last word in high security, but it should be
> equivalent to the current default password generation in Cloud Servers.
>
>
>
> -- 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 Compute 1.1

[Michael Mayo]

Okay, I've littered the WebHelp with comments.  There are too many different 
topics in there for it to make sense as a single email to this list.



On Mar 2, 2011, at 4:33 PM, Michael Mayo wrote:

> I have no idea how to work with docbkx, and my suggestions/questions will be 
> scattered throughout the API, so a merge probably wouldn't make sense in my 
> case.  I'm going to go with comments on WebHelp for now unless folks don't 
> like that.
> 
> Basically, I'm coming at this from an API consumer/usability perspective.  
> 
> 
> On Mar 2, 2011, at 2:25 PM, Justin Santa Barbara wrote:
> 
>> Surely we should work on LaunchPad, just like the rest of the OpenStack 
>> deliverables?
>> 
>> I just filed a merge proposal, so we'll see if this process works!
>> 
>> 
>> On Wed, Mar 2, 2011 at 2:17 PM, Jorge Williams 
>>  wrote:
>> I'd prefer the comments sections so that we have a reference when we 
>> discuss. But hey, I'll take suggestions from anywhere :-)
>> 
>> -jOrGe W.
>> 
>> On Mar 2, 2011, at 11:16 AM, Michael Mayo wrote:
>> 
>> > Should comments/suggestions go in this email thread or in the comments 
>> > sections of the web help?  I hate to spam this list :)
>> >
>> > Mike
>> >
>> > On Mar 2, 2011, at 8:29 AM, Jorge Williams wrote:
>> >
>> >>
>> >> Hey guys,
>> >>
>> >> New version of OpenStack Compute 1.1 is out.
>> >>
>> >> PDF:  
>> >> http://docs.openstack.org/openstack-compute/developer/cs-devguide.pdf
>> >> WebHelp: http://docs.openstack.org/openstack-compute/developer/content/
>> >>
>> >> See the "Document Change History" section for a list of changes.
>> >>
>> >> The API is now in Launchpad in the openstack-manuals project.   I checked 
>> >> it in 3 stages
>> >>
>> >> 1) Cloud Servers 1.0 :  This is the version of Cloud Servers we're 
>> >> running on Rackspace
>> >> 2) Open Stack Compute 1.1 (2/9/11) :  This is the version first shared on 
>> >> OpenStack
>> >> 3) Open Stack Compute 1.1 (3/1/11):  This is the current version
>> >>
>> >> I did this so that you can run diffs against the three versions and see 
>> >> exactly what's changed.  From now on all changes are going directly into 
>> >> Launchpad.
>> >>
>> >> I've gotten a lot of suggestions over the past couple of weeks, and I've 
>> >> tried to take them all into account.  There are still a couple of changes 
>> >> coming based on those suggestions but they're not very big -- mostly 
>> >> cosmetic.
>> >>
>> >> I realize we're still having a debate about "affinity id".  Affinity id 
>> >> is still mentioned in the spec, but I'm totally open to removing it if we 
>> >> decide that's not the best approach.
>> >>
>> >> I appreciate your input.  You can contribute by leaving comments in the 
>> >> WebHelp version (I don't think enterpad is going to work for this sort of 
>> >> thing).  Or if  you find something broken, or want to make another 
>> >> change, you can make changes to the openstack-manuals project submit a 
>> >> merge request.
>> >>
>> >> Thanks,
>> >>
>> >> jOrGe W.
>> >>
>> >> 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
>> >
>> > Mike Mayo
>> > 901-299-9306
>> > @greenisus
>> >
>> >
>> >
>> 
>> 
>> 
>> 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
>> 
> 
> Mike Mayo
> 901-299-9306
> @greenisus
> 
> 
> 
> ___
> Mailing list: https://launch

Re: [Openstack] OS API server password generation

[Ed Leafe]

On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:

> Also, I know security through obscurity isn't really security, but if we're 
> open source, I think we must have "strong" password generation, whatever may 
> or may not have been the case in the past.  I suggest beefing up the 
> generate_password function to make use of os.urandom (which I know isn't 
> perfect either, but is probably secure enough for anyone willing to rely on a 
> password)

The general process (at least in Rackspace Cloud Servers) is to create 
an initial root password which we then display for the instance owner; he/she 
can then shell in and change it to whatever they like. So I think that at best 
the os.urandom generator should be an option, with the less secure but easier 
to communicate password scheme also available.


-- 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] OS API server password generation

[Justin Santa Barbara]

We should be "secure out of the box", and not require the user to change
their password or manually lock down SSH to disable password auth.

A secure password would still be just as readable: I was thinking we'd use
the secure bytes to generate a readable password (either using them as a
seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can
skip some of the trickier letter pairs e.g. 1/I or 0/O.



On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe  wrote:

> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
>
> > Also, I know security through obscurity isn't really security, but if
> we're open source, I think we must have "strong" password generation,
> whatever may or may not have been the case in the past.  I suggest beefing
> up the generate_password function to make use of os.urandom (which I know
> isn't perfect either, but is probably secure enough for anyone willing to
> rely on a password)
>
> The general process (at least in Rackspace Cloud Servers) is to
> create an initial root password which we then display for the instance
> owner; he/she can then shell in and change it to whatever they like. So I
> think that at best the os.urandom generator should be an option, with the
> less secure but easier to communicate password scheme also available.
>
>
> -- 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] OS API server password generation

[Mark Washenberger]

Each time I call random.seed() on my box, it grabs another 256 bits from 
/dev/urandom (verified by strace).

I feel like we can just rely on the old standby [random.choice(pwchars) for i 
in xrange(pwlength)], peppering a few random.seed() calls in periodically to 
skip onto a new pseudorandom loop if necessary. 

"Justin Santa Barbara"  said:

> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> We should be "secure out of the box", and not require the user to change
> their password or manually lock down SSH to disable password auth.
> 
> A secure password would still be just as readable: I was thinking we'd use
> the secure bytes to generate a readable password (either using them as a
> seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can
> skip some of the trickier letter pairs e.g. 1/I or 0/O.
> 
> 
> 
> On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe  wrote:
> 
>> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
>>
>> > Also, I know security through obscurity isn't really security, but if
>> we're open source, I think we must have "strong" password generation,
>> whatever may or may not have been the case in the past.  I suggest beefing
>> up the generate_password function to make use of os.urandom (which I know
>> isn't perfect either, but is probably secure enough for anyone willing to
>> rely on a password)
>>
>> The general process (at least in Rackspace Cloud Servers) is to
>> create an initial root password which we then display for the instance
>> owner; he/she can then shell in and change it to whatever they like. So I
>> think that at best the os.urandom generator should be an option, with the
>> less secure but easier to communicate password scheme also available.
>>
>>
>> -- 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] OS API server password generation

[Justin Santa Barbara]

Why go to all this effort to promote bad code, when writing good code is
just as easy?  This is a fairly trivial fix we're talking about, probably
comparable to the effort of running strace.

Anyway, my focus is on users that don't want you setting passwords into
their boxes (especially after reading this thread).  Is bypassing password
generation in scope, or should I open a new bug?



On Wed, Mar 2, 2011 at 5:57 PM, Mark Washenberger <
mark.washenber...@rackspace.com> wrote:

> Each time I call random.seed() on my box, it grabs another 256 bits from
> /dev/urandom (verified by strace).
>
> I feel like we can just rely on the old standby [random.choice(pwchars) for
> i in xrange(pwlength)], peppering a few random.seed() calls in periodically
> to skip onto a new pseudorandom loop if necessary.
>
> "Justin Santa Barbara"  said:
>
> > ___
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> > We should be "secure out of the box", and not require the user to change
> > their password or manually lock down SSH to disable password auth.
> >
> > A secure password would still be just as readable: I was thinking we'd
> use
> > the secure bytes to generate a readable password (either using them as a
> > seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can
> > skip some of the trickier letter pairs e.g. 1/I or 0/O.
> >
> >
> >
> > On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe  wrote:
> >
> >> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
> >>
> >> > Also, I know security through obscurity isn't really security, but if
> >> we're open source, I think we must have "strong" password generation,
> >> whatever may or may not have been the case in the past.  I suggest
> beefing
> >> up the generate_password function to make use of os.urandom (which I
> know
> >> isn't perfect either, but is probably secure enough for anyone willing
> to
> >> rely on a password)
> >>
> >> The general process (at least in Rackspace Cloud Servers) is to
> >> create an initial root password which we then display for the instance
> >> owner; he/she can then shell in and change it to whatever they like. So
> I
> >> think that at best the os.urandom generator should be an option, with
> the
> >> less secure but easier to communicate password scheme also available.
> >>
> >>
> >> -- 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] OS API server password generation

[Mark Washenberger]

Yikes, I'm sorry. I didn't mean to give the impression of promoting bad code. I 
was coming at it from a simplicity perspective because I mistakenly thought my 
approach was cryptographically equivalent, assuming a case where the user does 
not want to skip password injection.

To your main point, I share your desire to be able to turn off password 
injection during instance creation. (For clarity, I'm assuming that your 
preference is to create the vm with no root password and only ssh keys as a 
means of access.) I guess the main problem with this is that it isn't in the 
1.[01] spec so we'd need to agree on a sensible way of adding it to the api.

Does anyone know if it would create any compatibility problems to support an 
optional "disable_admin_pass": "True" attribute to the /servers POST request? 
Are there any reasons other than compatibility to require an adminPass to 
always be set?

"Justin Santa Barbara"  said:

> Why go to all this effort to promote bad code, when writing good code is
> just as easy?  This is a fairly trivial fix we're talking about, probably
> comparable to the effort of running strace.
> 
> Anyway, my focus is on users that don't want you setting passwords into
> their boxes (especially after reading this thread).  Is bypassing password
> generation in scope, or should I open a new bug?
> 
> 
> 
> On Wed, Mar 2, 2011 at 5:57 PM, Mark Washenberger <
> mark.washenber...@rackspace.com> wrote:
> 
>> Each time I call random.seed() on my box, it grabs another 256 bits from
>> /dev/urandom (verified by strace).
>>
>> I feel like we can just rely on the old standby [random.choice(pwchars) for
>> i in xrange(pwlength)], peppering a few random.seed() calls in periodically
>> to skip onto a new pseudorandom loop if necessary.
>>
>> "Justin Santa Barbara"  said:
>>
>> > ___
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>> > We should be "secure out of the box", and not require the user to change
>> > their password or manually lock down SSH to disable password auth.
>> >
>> > A secure password would still be just as readable: I was thinking we'd
>> use
>> > the secure bytes to generate a readable password (either using them as a
>> > seed or e.g. by mapping 5 bits at a time).  By using only 5 bits, we can
>> > skip some of the trickier letter pairs e.g. 1/I or 0/O.
>> >
>> >
>> >
>> > On Wed, Mar 2, 2011 at 5:17 PM, Ed Leafe  wrote:
>> >
>> >> On Mar 2, 2011, at 8:01 PM, Justin Santa Barbara wrote:
>> >>
>> >> > Also, I know security through obscurity isn't really security, but if
>> >> we're open source, I think we must have "strong" password generation,
>> >> whatever may or may not have been the case in the past.  I suggest
>> beefing
>> >> up the generate_password function to make use of os.urandom (which I
>> know
>> >> isn't perfect either, but is probably secure enough for anyone willing
>> to
>> >> rely on a password)
>> >>
>> >> The general process (at least in Rackspace Cloud Servers) is to
>> >> create an initial root password which we then display for the instance
>> >> owner; he/she can then shell in and change it to whatever they like. So
>> I
>> >> think that at best the os.urandom generator should be an option, with
>> the
>> >> less secure but easier to communicate password scheme also available.
>> >>
>> >>
>> >> -- 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] State of OpenStack Auth

[Jesse Andrews]

I agree that things should be pluggable, but OpenStack needs to have a default. 
 

Users need to know that they can point OpenStack client applications at 
OpenStack providers and it should work.

I would prefer a signature based approach as the default (as signatures limits 
replay attacks; tokens allow an eavesdropper to make arbitrary requests if they 
obtain a token).

Jesse

On Mar 2, 2011, at 7:34 AM, Jorge Williams wrote:

> Soren,
> 
> Really good question about why we didn't use cookies. There are two problems 
> that I see with cookies.
> 
> 1)  Weak support in HTTP client libraries.  HTTP libs tend to not handle them 
> at all or to not handle them correctly. In the Java world,  for example, 
> java.net.* doesn't handle cookies very well. There are certainly other libs 
> that handle them, but a whole bunch of software is built on top of java.net.* 
> including some popular REST libraries.
> 2)  Say you make a request and don't include your cookie in it. A typical 
> webapp will simply redirect you to a login form.  But what should happen in a 
> REST API?  Should you get a 401?  I think it's a little fuzzy how we would 
> handle this correctly.
> 
> If you want browser support -- and personally I think all of our APIs should 
> be browser friendly -- I think the best approach is to support an establish 
> scheme like HTTP Basic or Digest.  These schemes have great client lib 
> support.  They are supported in a friendly way by browsers.  And they don't 
> break HTTP semantics, so you don't get a redirect when you should be getting 
> a request for credentials.
> 
> That said, I really feel we should take a pluggable approach to 
> authentication so that we can let operators and clients decide what they need.
> 
> -jOrGe W.
> 
> 
> On Mar 1, 2011, at 3:08 PM, Eric Day wrote:
> 
>> On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote:
>>> 2011/3/1 Eric Day :
 Well, hopefully with a shared, modular service, we can add a token
 module that uses cookies instead. :)
>>> 
>>> Sure :) I was just hoping to extract whatever wisdom might have been
>>> behind the decision to seemingly reinvent the concept of cookies.
>>> Perhaps there's some reason to avoid cookies I'm missing... Sorry,
>>> didn't mean to hijack your thread :)
>> 
>> That's what this thread is for, figure out what we have and what do
>> we want? :)
>> 
>> Perhaps Jorge or someone else on the Rackspace auth side can share
>> some reasons for the decisions?
>> 
>> -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
> 
> 
> 
> 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] OS API server password generation

[Justin Santa Barbara]

On Wed, Mar 2, 2011 at 8:41 PM, Mark Washenberger <
mark.washenber...@rackspace.com> wrote:

> Yikes, I'm sorry. I didn't mean to give the impression of promoting bad
> code. I was coming at it from a simplicity perspective because I mistakenly
> thought my approach was cryptographically equivalent, assuming a case where
> the user does not want to skip password injection.
>

No worries - sorry if I was harsh.  I don't really know crypto, but I know
enough to try to 'just do the standard thing'.

... it isn't in the 1.[01] spec so we'd need to agree on a sensible way of
> adding it to the api.  Does anyone know if it would create any compatibility
> problems to support an optional "disable_admin_pass": "True" attribute to
> the /servers POST request?
>

+1 for an option that defaults to false
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp