Re: [Openstack] swauth_novaldap released
Hi Greg, Thank you for your response. On Fri, 3 Jun 2011 09:53:01 -0500 Greg Holt wrote: > Very, very cool! > > Just curious, what's the reason for the account, user -> user, account switch > in swift3.py? The format of Authorization header of S3 API is below: Authorization: LOW Accesskey:Secret And accesskey of Nova is below: AccessKey = User:Project So, Authorization header of Swift3 forms: Authorization: LOW User:Project:secret swauth_novaldap presumed that projects of Nova are accounts of Swift, so that header is User:Account:secret. So, we have to change that code from account,user,_junk to user,account,_junk. Best regards, Akira YOSHIYAMA > On Jun 3, 2011, at 9:25 AM, Akira YOSHIYAMA wrote: > > > Hi Stackers, > > > > I'm pleased to announce swauth_novaldap, an auth-n/z driver for Swift > > to use Nova user/profile data in LDAP. > > > > http://www.debian.or.jp/~yosshy/swauth_novaldap/ > > > > swauth_novaldap has 2 benefits: > > > > * Nova and Swift share their user and group information. > > * Swift can use LDAP as a store for user and group information. So, you > > can manage user and group of Swift with your LDAP administration > > tools. > > > > Note: > > swauth_novaldap doesn't use user's password but secret key of Nova > > user. > > > > Best regards, > > Akira YOSHIYAMA ___ 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] Feedback on HTTP APIs
I think Jorge's "bookmark" links refer to an Atom permalink. Jorge, is
that correct?
-jay
On Fri, Jun 3, 2011 at 11:34 AM, Thorsten von Eicken
wrote:
> Really? The way I understand it, when I retrieve resource X I will get a
> bookmark link for X. But when I retrieve resource Y that happens to have a
> reference to X this references will not include the bookmark link for X, it
> will just include X's URL. I'd then have to retrieve that URL, which would
> get me that resource's bookmark link and then realize that this is actually
> X which I already have. Or perhaps I'm not understanding the docs correctly?
> Thorsten
>
> On 6/3/2011 5:39 AM, Jorge Williams wrote:
>
> The whole idea behind the "bookmark" links is to give you the functionality
> that you want -- that is a URL without a version number in it. Looks like
> the implementation hasn't yet added support for that, but it will.
> -jOrGe W.
> On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote:
>
> We neither hate nor love UUIDs, but we like them when they provide value and
> we also accept alternatives. What we do hate is ambiguity and in certain
> cases UUIDs help.
>
> Look at the hrefs returned in this sample resource and picture what you'd
> store in your database as unique identifier to refer to each one:
> {"server"=>
> {"name"=>"kd_test_3",
> "flavorRef"=>"http://5.5.2.2:8774/v1.1/flavors/3";,
> "addresses"=>
> {"public"=>[], "private"=>[{"version"=>4, "addr"=>"5.5.2.5"}]},
> "metadata"=>{"v2"=>"d2", "4"=>"14", "5"=>"17"},
> "imageRef"=>"http://5.5.2.2:8774/v1.1/images/1";,
> "id"=>26,
> "hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5",
> "links"=>
> [{"href"=>"http://5.5.2.2:8774/v1.1/servers/26";, "rel"=>"self"},
> {"href"=>"http://5.5.2.2:8774/v1.1/servers/26";,
> "rel"=>"bookmark",
> "type"=>"application/json"
> },
> {"href"=>"http://5.5.2.2:8774/v1.1/servers/26";,
> "rel"=>"bookmark",
> "type"=>"application/xml"
> }
> ],
> "status"=>"ACTIVE"
> }
> }
> Are the hostnames significant? Are the port numbers significant? Are the
> version IDs significant? Is the next URI component significant? Is the
> integer ID significant? Mhhh, maybe it's obvious to the OpenStack
> implementers, but it leaves quite some room for error for all the users out
> there. We end up having to write a little algorithm that throws away the
> hostname and port, then throws away the version number if there is one -- it
> really should NOT be part of the URL! -- then looks at the next path
> component to decide whether its the resource type and whether the path
> component after that is the resource id, or whether there is further nesting
> of path components. Then we can assemble a unique ID and see whether we know
> about that resource or need to fetch it. It would be really nice to have a
> UUID attribute that eliminates this guesswork and we like UUIDs that start
> with a type-specific prefix, such as inst-12345 or img-12345.
>
> Our recommendation:
> - option 1: use canonical hrefs that can be used as unique IDs, which means
> without host/port and without version number
> - option 2: use a unique ID with a type prefix and include that as
> attribute in hrefs, we like small IDs, but we don't care that much
>
> WRT UUIDs, we try to use integer IDs when we can easily generate them
> centrally, but switch to UUIDs when we need to distribute the ID generation
> and we keep them as short as practical.
>
> Thanks much!
> Thorsten - CTO RightScale
>
>
> On 6/2/2011 12:40 PM, Jay Pipes wrote:
>
> On Thu, Jun 2, 2011 at 1:18 PM, George Reese
> wrote:
>
> I hate UUIDs with a passion.
>
> * They are text fields, which means slower database indexes
>
> Text fields are stored on disk/in memory as bytes the same as any
> integer. It's that the number of bytes needed to store it is greater,
> resulting in larger indexes and more bytes to store the keys. But, as
> Jorge mentioned, some databases have native support for large-integer
> types like UUIDs.
>
> * They are completely user-unfriendly. The whole "copy and paste" argument
> borders on silliness
>
> Yes, it's not easy to remember UUIDs. That's why virtually every
> resource has some other way of identifying themselves. Typically, this
> is a name attribute, though not all resources enforce uniqueness on
> the name attribute, thus the need for a unique identifier.
>
> I don't see people manually looking up resources based on UUIDs. I see
> *machines* manually looking up resources based on UUIDs, and humans
> looking up resources by, say, name, or (name, tenant_id) or (name,
> user_id), etc.
>
> * And uniqueness across regions for "share nothing" can be managed with a
> variety of alternative options without resorting to the ugliness that is
> UUIDs
>
> Like URIs? I don't know of any other options that would work. Please
> let us know what you think about in this respect.
>
> -jay
>
> __
Re: [Openstack] XML and JSON for API's
On Jun 3, 2011, at 1:13 PM, Bryan Taylor wrote: > We've standardized on XML for backend work. We aren't spending much time > debugging serialization issues and are pretty happy with our decision and > aren't likly to change any time soon vs. > So the obvious thing to do is support both JSON and XML, which isn't that > hard. I'm always confused when people claim that doing something is easy, but also that for them to do the same thing is too hard. > at the point they try to tell me how to implement my solutions, all it does > is annoy me, because format wars are annoying. I'm not sure if you intended it, but dismissing a discussion about taking on a significant chunk of work as nothing more than an annoying "format war" sounds rather condescending. We're not arguing the merits of of one over the other; we're deciding if we are going to commit to supporting XML right now, or perhaps add it later on. Everyone would love to support as many formats as possible. With limited resources, we need to narrow our focus. And since this is all open source, anyone who has a need and finds implementing the solution for that need isn't "that hard" is more than welcome to contribute. -- 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] XML and JSON for API's
On Jun 4, 2011, at 9:14 AM, "Ed Leafe" wrote: > On Jun 3, 2011, at 1:13 PM, Bryan Taylor wrote: > >> We've standardized on XML for backend work. We aren't spending much time >> debugging serialization issues and are pretty happy with our decision and >> aren't likly to change any time soon Our choice, for "backend" work, as one example of an openstack customer. >vs. > >> So the obvious thing to do is support both JSON and XML, which isn't that >> hard. A product feature choice as a platform provider who has to support a community. > >I'm always confused when people claim that doing something is easy, but > also that for them to do the same thing is too hard. Our internal policy is actually that XML is mandatory and other formats are allowed and driven by customer request. I never said it was too hard for us to support both, and when we look at the needs of the community of developers - we see a vastly different layout than openstack does, with a much smaller set of people. BTW, we ironically followed the Rackspace Cloud architecture team's recommendation as cloud is the only major external integrator with us. We just signed a major contract with a SaaS vendor whose product will become one of the pillars that runs Rackspace. They earned big points in the integration category vs their competition because they uniformly output XML, JSON, CSV, XLS via http and SOAP for each API. >> at the point they try to tell me how to implement my solutions, all it does >> is annoy me, because format wars are annoying. > >I'm not sure if you intended it, but dismissing a discussion about taking > on a significant chunk of work as nothing more than an annoying "format war" > sounds rather condescending. We're not arguing the merits of of one over the > other; we're deciding if we are going to commit to supporting XML right now, > or perhaps add it later on. Ask the customers. This is a product feature - the question is demand vs difficulty. Think of this decision the same way we decide what OS's to support. And several posts (none from you) have approached it by touting technical merits. There are certain religious area: OS, language, xml vs json where tech merit discussions are just going to result in endless soul sucking debate. >Everyone would love to support as many formats as possible. With limited > resources, we need to narrow our focus. And since this is all open source, > anyone who has a need and finds implementing the solution for that need isn't > "that hard" is more than welcome to contribute. I wonder what your stance would be on a contribution that was XML only. Mine would be the same - the feature isn't ready for inclusion in a release until it is finished by meeting the API standards of supporting both. I'm pushing for more involvement by our devs in openstack, btw. As we scratch our own itches as customers i have no problem expecting our contributions to meet openstack coding standards. But before this happens we go through the process of deciding to deploy openstack components, and components that speak XML are attractive to us. Other customers prefer JSON and I'd like a big tent where we all collaborate. > > -- 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] Feedback on HTTP APIs
Resources often have multiple representations, due to either media type
versioning or differing underlying formats. A common convention is to create
"variant" resources that support some specific representation(s) eg by putting
a version number or file extension or both in the resouce identifier.
I recommend using rel=bookmark for the permalink to the parent resource, not to
variants. This is the most stable URI for long term linking to the underlying
thing. It will survive changes in version and representation format.
For rel=self i dont care as much at excluding variants and it seems natural to
put a versioned URI there when i have the bookmark next to it.
On Jun 4, 2011, at 8:37 AM, "Jay Pipes" wrote:
> I think Jorge's "bookmark" links refer to an Atom permalink. Jorge, is
> that correct?
>
> -jay
>
> On Fri, Jun 3, 2011 at 11:34 AM, Thorsten von Eicken
> wrote:
>> Really? The way I understand it, when I retrieve resource X I will get a
>> bookmark link for X. But when I retrieve resource Y that happens to have a
>> reference to X this references will not include the bookmark link for X, it
>> will just include X's URL. I'd then have to retrieve that URL, which would
>> get me that resource's bookmark link and then realize that this is actually
>> X which I already have. Or perhaps I'm not understanding the docs correctly?
>> Thorsten
>>
>> On 6/3/2011 5:39 AM, Jorge Williams wrote:
>>
>> The whole idea behind the "bookmark" links is to give you the functionality
>> that you want -- that is a URL without a version number in it. Looks like
>> the implementation hasn't yet added support for that, but it will.
>> -jOrGe W.
>> On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote:
>>
>> We neither hate nor love UUIDs, but we like them when they provide value and
>> we also accept alternatives. What we do hate is ambiguity and in certain
>> cases UUIDs help.
>>
>> Look at the hrefs returned in this sample resource and picture what you'd
>> store in your database as unique identifier to refer to each one:
>> {"server"=>
>> {"name"=>"kd_test_3",
>>"flavorRef"=>"http://5.5.2.2:8774/v1.1/flavors/3";,
>>"addresses"=>
>> {"public"=>[], "private"=>[{"version"=>4, "addr"=>"5.5.2.5"}]},
>>"metadata"=>{"v2"=>"d2", "4"=>"14", "5"=>"17"},
>>"imageRef"=>"http://5.5.2.2:8774/v1.1/images/1";,
>>"id"=>26,
>>"hostId"=>"4e6200284bc7bd28e49016aa047fbdc6a3f5",
>>"links"=>
>> [{"href"=>"http://5.5.2.2:8774/v1.1/servers/26";, "rel"=>"self"},
>> {"href"=>"http://5.5.2.2:8774/v1.1/servers/26";,
>> "rel"=>"bookmark",
>> "type"=>"application/json"
>> },
>> {"href"=>"http://5.5.2.2:8774/v1.1/servers/26";,
>> "rel"=>"bookmark",
>> "type"=>"application/xml"
>> }
>> ],
>>"status"=>"ACTIVE"
>> }
>> }
>> Are the hostnames significant? Are the port numbers significant? Are the
>> version IDs significant? Is the next URI component significant? Is the
>> integer ID significant? Mhhh, maybe it's obvious to the OpenStack
>> implementers, but it leaves quite some room for error for all the users out
>> there. We end up having to write a little algorithm that throws away the
>> hostname and port, then throws away the version number if there is one -- it
>> really should NOT be part of the URL! -- then looks at the next path
>> component to decide whether its the resource type and whether the path
>> component after that is the resource id, or whether there is further nesting
>> of path components. Then we can assemble a unique ID and see whether we know
>> about that resource or need to fetch it. It would be really nice to have a
>> UUID attribute that eliminates this guesswork and we like UUIDs that start
>> with a type-specific prefix, such as inst-12345 or img-12345.
>>
>> Our recommendation:
>> - option 1: use canonical hrefs that can be used as unique IDs, which means
>> without host/port and without version number
>> - option 2: use a unique ID with a type prefix and include that as
>> attribute in hrefs, we like small IDs, but we don't care that much
>>
>> WRT UUIDs, we try to use integer IDs when we can easily generate them
>> centrally, but switch to UUIDs when we need to distribute the ID generation
>> and we keep them as short as practical.
>>
>> Thanks much!
>> Thorsten - CTO RightScale
>>
>>
>> On 6/2/2011 12:40 PM, Jay Pipes wrote:
>>
>> On Thu, Jun 2, 2011 at 1:18 PM, George Reese
>> wrote:
>>
>> I hate UUIDs with a passion.
>>
>> * They are text fields, which means slower database indexes
>>
>> Text fields are stored on disk/in memory as bytes the same as any
>> integer. It's that the number of bytes needed to store it is greater,
>> resulting in larger indexes and more bytes to store the keys. But, as
>> Jorge mentioned, some databases have native support for large-integer
>> types like UUIDs.
>>
>> * They are completely user-unfriendly. The whole "copy and paste" argument
>> borders on silliness
>>
Re: [Openstack] XML and JSON for API's
Damn, I knew I should have trademarked the "OpenStack, Cloud's Big Tent" slogan! Sent from my iPhone On 2011-06-04, at 10:37 AM, Bryan Taylor wrote: > On Jun 4, 2011, at 9:14 AM, "Ed Leafe" wrote: > >> On Jun 3, 2011, at 1:13 PM, Bryan Taylor wrote: >> >>> We've standardized on XML for backend work. We aren't spending much time >>> debugging serialization issues and are pretty happy with our decision and >>> aren't likly to change any time soon > > Our choice, for "backend" work, as one example of an openstack customer. > >> vs. >> >>> So the obvious thing to do is support both JSON and XML, which isn't that >>> hard. > > A product feature choice as a platform provider who has to support a > community. > >> >> I'm always confused when people claim that doing something is easy, but >> also that for them to do the same thing is too hard. > > Our internal policy is actually that XML is mandatory and other formats are > allowed and driven by customer request. I never said it was too hard for us > to support both, and when we look at the needs of the community of developers > - we see a vastly different layout than openstack does, with a much smaller > set of people. BTW, we ironically followed the Rackspace Cloud architecture > team's recommendation as cloud is the only major external integrator with us. > > We just signed a major contract with a SaaS vendor whose product will become > one of the pillars that runs Rackspace. They earned big points in the > integration category vs their competition because they uniformly output XML, > JSON, CSV, XLS via http and SOAP for each API. > >>> at the point they try to tell me how to implement my solutions, all it does >>> is annoy me, because format wars are annoying. >> >> I'm not sure if you intended it, but dismissing a discussion about taking >> on a significant chunk of work as nothing more than an annoying "format war" >> sounds rather condescending. We're not arguing the merits of of one over the >> other; we're deciding if we are going to commit to supporting XML right now, >> or perhaps add it later on. > > Ask the customers. This is a product feature - the question is demand vs > difficulty. Think of this decision the same way we decide what OS's to > support. > > And several posts (none from you) have approached it by touting technical > merits. There are certain religious area: OS, language, xml vs json where > tech merit discussions are just going to result in endless soul sucking > debate. > >> Everyone would love to support as many formats as possible. With limited >> resources, we need to narrow our focus. And since this is all open source, >> anyone who has a need and finds implementing the solution for that need >> isn't "that hard" is more than welcome to contribute. > > I wonder what your stance would be on a contribution that was XML only. Mine > would be the same - the feature isn't ready for inclusion in a release until > it is finished by meeting the API standards of supporting both. > > I'm pushing for more involvement by our devs in openstack, btw. As we scratch > our own itches as customers i have no problem expecting our contributions to > meet openstack coding standards. But before this happens we go through the > process of deciding to deploy openstack components, and components that speak > XML are attractive to us. Other customers prefer JSON and I'd like a big tent > where we all collaborate. > >> >> -- 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] XML and JSON for API's
Motto! On 6/4/11 9:39 PM, "Joshua McKenty" wrote: >Damn, I knew I should have trademarked the "OpenStack, Cloud's Big Tent" >slogan! ___ 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] XML and JSON for API's
No, it was the title of my talk at CCA11. The motto is, and will remain, "Free as in speech, love, and beer." Sent from my iPhone On 2011-06-04, at 7:43 PM, Bryan Taylor wrote: > Motto! > > On 6/4/11 9:39 PM, "Joshua McKenty" wrote: > >> Damn, I knew I should have trademarked the "OpenStack, Cloud's Big Tent" >> slogan! > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
