From:
openstack-bounces+jason.rouault=hp@lists.launchpad.net<mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net>
[mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf
Of Ziad Sawalha
Sent: Thursday, July 21, 2011 12:52 PM
To: openstack@lists.launch
: 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
There isn't a plan, but an acknowledgement that we'll have to go there. Right
now we're trying to avoid authorization as much as possible because of the
complexity involved and the distraction it would be from the initial goal;
providing one, common authentication service for OpenStack core serv
.
(https://github.com/rackspace/keystone/issues/58)
Regards,
Ziad
From: Bryan Taylor mailto:btay...@rackspace.com>>
Date: Mon, 20 Jun 2011 23:17:02 -0500
To: Ziad Sawalha
mailto:ziad.sawa...@rackspace.com>>,
"openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.n
I'm reading through the dev guide for the first time. I hope my comments are
timely.
I'm glad to see section 2 begin by defining concepts. I'd suggest adding all
these concepts to the openstack glossary at http://wiki.openstack.org/Glossary.
The github site for keystone defines these concepts i
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
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 carry very different semantics.
So, to my understanding, key stone provides authentication and user
information -
Is there a plan to also have Keystone be the centralizing framework around
authorization? Right now it looks like policy enforcement is left to the
API layer.
Thanks,
Jason
From: openstack-bounces+jason.rouault=hp@lists.launchpad.net
[mailto:openstack-bounces+jason.rouault=hp@lis
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
35 matches
Mail list logo
