pad.net<mailto:openstack@lists.launchpad.net>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Hot, Texas summer regards to all!
Since my last note we have had much progress on Keystone. Particularly:
* We now have Nova, Dashboard, Glance, and Keystone integration
(htt
: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Hot, Texas summer regards to all!
Since my last note we have had much progress on Keystone. Particularly:
* We now have Nova, Dashboard, Glance, and Keystone integration
(https://github.com/cloudbuilders/deploy.sh
Hot, Texas summer regards to all!
Since my last note we have had much progress on Keystone. Particularly:
* We now have Nova, Dashboard, Glance, and Keystone integration
(https://github.com/cloudbuilders/deploy.sh
* We've done some work on Swift integration
(https://github.com/rackspace
gt; Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
>
> Below:
>
> On Jul 18, 2011, at 3:28 AM, Salvatore Orlando wrote:
>
>
> Hi,
>
> I’m jumping in this thread to understand whether there’s a chance KeyStone
> can implement some use cases arou
Hi Vish,
Please see my comments inline.
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: 18 July 2011 17:36
To: Salvatore Orlando
Cc: Ziad Sawalha; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Below:
On Jul 18, 2011, at 3:28 AM
Below:
On Jul 18, 2011, at 3:28 AM, Salvatore Orlando wrote:
> Hi,
>
> I’m jumping in this thread to understand whether there’s a chance KeyStone
> can implement some use cases around the concept of object ownership.
> I apologise if this email turns out to be a bunch of nonsense; unfortunatel
citrix@lists.launchpad.net
[mailto:openstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net]
On Behalf Of Ziad Sawalha
Sent: 13 July 2011 05:45
To: Rouault, Jason (Cloud Services); andi abes
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Her
awalha mailto:ziad.sawa...@rackspace.com>>
Cc: Jay Pipes mailto:jaypi...@gmail.com>>, Bryan Taylor
mailto:btay...@rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openst
> From: Thor Wolpert
> Date: Wed, 13 Jul 2011 17:17:03 -0700
> To: Ziad Sawalha
> Cc: Jay Pipes , Bryan Taylor ,
> "openstack@lists.launchpad.net"
> Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
>
> If they had called it "global" or some other
d, 13 Jul 2011 17:17:03 -0700
To: Ziad Sawalha mailto:ziad.sawa...@rackspace.com>>
Cc: Jay Pipes mailto:jaypi...@gmail.com>>, Bryan Taylor
mailto:btay...@rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.n
I'm a bit confused as to how Keystone will handle authorization. It sounds now
like it is only handling authentication. Can you clarify?
Devin
On Jul 13, 2011, at 9:41 PM, Ziad Sawalha wrote:
> We've taken much of that out of the current API; so the API does not allow
> creating these entiti
We've taken much of that out of the current API; so the API does not allow
creating these entities through the service API.
And we don't have delegation over tenant administration either, although
the API we have in place can fully support atier that implements itŠ.
Z
On 7/13/11 11:30 AM, "Bryan
k@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Dropped off the thread for a while... sorry.
Ziad, I think this sounds very reasonable. I think the only hiccup might be
w
mplete IDM solution…
>
>I *think*.
>
> ** **
>
> ** **
>
> ** **
>
>
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Jun 15, 2011 at 11:52 AM, Rouault, Jason (Cloud Services) <
> jason.roua...@hp.com> wrote:
>
>
If they had called it "global" or some other container name, would you be
happier with that? If you're trying to leverage some LDAP style framework,
then you'd always want users in some container instead of at the raw root.
Maybe some guidance or default schema would help those groups out?
On W
And some current Nova users have created 'dummy' tenants to house global
users. That's ugly and hard to maintain, so we wanted to avoid 'dummy'
tenant solutions if possible. Given we're creating the spec right here and
now, we can do that :-)
On 7/13/11 12:14 PM, "Jay Pipes" wrote:
>On Wed, Ju
On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor wrote:
> How is this different in effect than letting swift or nova be tenants? Each
> tenant gets to define users, roles, and groups, right?
A service can have multiple tenants. For instance, an installation of
Nova might have a RAX tenant and a RAX
How is this different in effect than letting swift or nova be tenants?
Each tenant gets to define users, roles, and groups, right?
On 07/13/2011 10:39 AM, Jay Pipes wrote:
On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha
wrote:
Here's a possible use case we can implement to address this:
A se
On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha
wrote:
> Here's a possible use case we can implement to address this:
>
> A service 'registers' itself with Keystone and reserves a name (Ex. Swift,
> or nova). Keystone will guarantee uniqueness.
> Registered services can then create roles for the se
rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: RE: [Openstack] OpenStack Identity: Keystone API Proposal
See inline…
Jason
From: andi abes [mailto:andi.a...@gmail.com]
Sent: W
;openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
On PUT operations:
The identifier for users right now (username) is supplied in the payload, so it
is a PUT. Same with
3:17:02 -0500
To: Ziad Sawalha
mailto:ziad.sawa...@rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
I'm reading through the de
enstack@lists.launchpad.net>
Subject: [Openstack] OpenStack Identity: Keystone API Proposal
Time flies! It's June 10th already. In my last email to this community I had
proposed today as the day to lock down the Keystone API so we can finalize
implementation by Diablo-D2 (June 30th).
We
ion that can be kept current
within a desired latency by efficient polling of the atom feeds.
From: Ziad Sawalha
mailto:ziad.sawa...@rackspace.com>>
Date: Fri, 10 Jun 2011 23:24:24 +
To: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lis
o:ziad.sawa...@rackspace.com>>
Date: Fri, 10 Jun 2011 23:24:24 +0000
To: "openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] OpenStack Identity: Keystone API Proposal
Time flies! It's June 10
See inline.
Jason
From: andi abes [mailto:andi.a...@gmail.com]
Sent: Wednesday, June 15, 2011 5:04 PM
To: Rouault, Jason (Cloud Services)
Cc: Ziad Sawalha; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Jason,
Sounds like the
>
>
>
>
>
> *From:* andi abes [mailto:andi.a...@gmail.com]
> *Sent:* Wednesday, June 15, 2011 9:18 AM
> *To:* Rouault, Jason (Cloud Services)
> *Cc:* Ziad Sawalha; openstack@lists.launchpad.net
> *Subject:* Re: [Openstack] OpenStack Identity: Keystone API Proposal
>
: Ziad Sawalha; openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
I would expect that the API of each service would have to interpret the role
assigned to a user in the context of that service - roles for swift nova
glance quantum etc would probably
sts.launchpad.net[mailto:
> openstack-bounces+jason.rouault=hp@lists.launchpad.net] *On Behalf Of
> *Ziad Sawalha
> *Sent:* Friday, June 10, 2011 5:24 PM
> *To:* openstack@lists.launchpad.net
> *Subject:* [Openstack] OpenStack Identity: Keystone API Proposal
>
>
>
> Time f
@lists.launchpad.net] On
Behalf Of Ziad Sawalha
Sent: Friday, June 10, 2011 5:24 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] OpenStack Identity: Keystone API Proposal
Time flies! It's June 10th already. In my last email to this community I had
proposed today as the day to lock
d.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Ziad, thanks the quick edits.
One more quick question, mostly because I haven't followed the full keystone
discussions. How does this API relate (if at all) to
lso refer to the readme which today has instructions for setting up
> your Keystone instance.
>
> Let me know if that gets you going, Andi.
>
> Regards,
> Ziad
>
>
> From: Ziad Sawalha
> Date: Sat, 11 Jun 2011 14:44:12 +
> To: Andiabes
>
> Cc: "openstac
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
Your guess is correct. The only calls you should be able to make without having
a token are the calls to discover the service (getting version info, WADL
contract, dev guide, help, etc
d.net<mailto:openstack@lists.launchpad.net>"
mailto:openstack@lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal
It might be useful to include in the API guide some information about
authentication to keystone itself. I.e when requesting a list of users,te
It might be useful to include in the API guide some information about
authentication to keystone itself. I.e when requesting a list of users,tenants
etc the requestor should somehow authenticate itself
I'm guessing that the flow involve acquiring a token that authenticates the
user to keystone a
Time flies! It's June 10th already. In my last email to this community I had
proposed today as the day to lock down the Keystone API so we can finalize
implementation by Diablo-D2 (June 30th).
We've been working on this feverishly over the past couple of weeks and have
just pushed out a propose
36 matches
Mail list logo
