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
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
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
[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
2011/3/2 Jorge Williams 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
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
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
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
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
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:
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
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
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
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.
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
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
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
2011/3/2 Michael Barton mike-launch...@weirdlooking.com:
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
On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen so...@ubuntu.com 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
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:
2011/3/2 Michael Barton mike-launch...@weirdlooking.com:
On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen so...@ubuntu.com 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
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
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
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,
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
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
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 jorge.willi...@rackspace.com
wrote:
https://launchpad.net/openstack-manuals
On Mar 2, 2011, at 10:42
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
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
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,
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,
31 matches
Mail list logo
