> 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
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 a
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
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
> [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
wit
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 peopl
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
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 Launchpa
> 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 appeal
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 ou
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-co
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 o
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",
>
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
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 i
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:
GE
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
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 go
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
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 d
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 I
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 "1
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 u
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 docu
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 rea
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 pr
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
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/ope
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
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
noti
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 unf
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
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
>
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 wi
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 wr
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 h
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 w
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 in
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/usabi
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 f
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 so
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 througho
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_
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.
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 loo
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 readi
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 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; token
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
52 matches
Mail list logo
