On 07/18/2013 12:33 AM, Alessio Ababilov wrote:
Hi, Chmouel!
I have seen your commit https://review.openstack.org/#/c/36427/2
introducing auth plugins to keystone client.
I have developed a common API client library that already has auth
plugin mechanism found in novaclient. The library can
Hi, Chmouel!
I have seen your commit
https://review.openstack.org/#/c/36427/2introducing auth plugins to
keystone client.
I have developed a common API client library that already has auth plugin
mechanism found in novaclient. The library can be used in keystone, nova,
and glance clients, and now
Try running the same command with the --debug option, and share the output
here.
Thanks,
-Dolph
On Sunday, July 22, 2012, MURAOKA Yusuke wrote:
> Hi,
>
> There is devstack all-in-one openstack builder. http://devstack.org/
> Officially, its not supporting RHEL 6.1 on the site. But its only
> sh
Hi,
There is devstack all-in-one openstack builder. http://devstack.org/
Officially, its not supporting RHEL 6.1 on the site. But its only shell-script.
So, you can get working stack to compare what's different from the stack you
built.
--
MURAOKA Yusuke
Mail: yus...@jbking.org
日付：2012年7月2
Hi,
Did you change Keystone ports ?
adminurl should be : http://127.0.0.1:35357/v2.0
publicurl & internalurl should be : http://127.0.0.1:5000/v2.0
2012/7/22 延生 付
> Dear all,**
> ** **
> The background is I have already installed all the openstack components on
> RHEL 6.1.
> Nova an
Dear all,
The background is I have already installed all the openstack components on RHEL
6.1.
Nova and Glance configured well, and can boot up normally.
Keystone server also configured and boot up normally, while when I type the cmd
as below, weird things happened.
[root@kapi-r11 keystone]#
t; 2) If Bud Selid tries to access MLB with the token scoped to either
>>>> Giants, Dodgers, or Brewers, his a NOBODY. J
>>>>
>>>> The upcoming Domains blueprint (to be implemented for Folsom), which
>>>> offers true multitenancy, should
t; ALSO the Minority Owner for Dodgers, Giants, and Brewers. J
>> 2) If Bud Selid tries to access MLB with the token scoped to either
>> Giants, Dodgers, or Brewers, his a NOBODY. J
>>
>> The upcoming Domains blueprint (to be implemented for Folsom), which
>> offers true mult
y Owner in the MLB domain. Assign the
> Commissioner role to Bud Selid, and the Minority Owner role scoped to
> Brewers. Suppose you have another domain NFL, Bud Selid will not be able to
> access any tenants in the NFL domain, unless the NFL domain administrator
> explicitly assign NF
ith Domains, you can create a MLB domain with tenants Dodgers, Giants, and
>>> Brewers. And have Bud Selid under the MLB domain. Notice that users will no
>>> longer be assigned to tenants. They will be under a domain. Create roles
>>> Commissioner and Minority Owner in the MLB d
in, unless the NFL domain administrator explicitly
>> assign NFL roles to Bud Selid.
>>
>>
>> Guang
>>
>>
>>
>>
>> From: openstack-bounces+guang.yee=hp@lists.launchpad.net
>> [mailto:openstack-bounces+guang.yee=hp@lists.l
explicitly assign NFL
> roles to Bud Selid.
>
>
> Guang
>
>
>
>
> From: openstack-bounces+guang.yee=hp@lists.launchpad.net
> [mailto:openstack-bounces+guang.yee=hp@lists.launchpad.net] On Behalf Of
> Dolph Mathews
> Sent: Wednesday, May 0
Subject: Re: [Openstack] Keystone client, user belongs to many tenants?
The user create command is actually creating discrete users, each with a
"default tenant" reference.
While that's fine for a lot of simple use cases, it doesn't directly support a
user accessing mul
On May 9, 2012, at 4:46 PM, Joshua Harlow wrote:
> A question,
>
> I am using anvil to setup the keystone roles/users/tenants.
>
> It seems like the python keystone client has the following command:
>
> client.users.create
>
> Which seems to take in the following:
>
> create(self, name, pas
nchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Joshua Harlow
Sent: Wednesday, May 09, 2012 1:46 PM
To: openstack
Subject: [Openstack] Keystone client, user belongs to many tenants?
A question,
I am using anvil to setup the keystone roles/users/tenants.
It
The user create command is actually creating discrete users, each with a
"default tenant" reference.
While that's fine for a lot of simple use cases, it doesn't directly support a
user accessing multiple tenants at all.
Instead, create a role, and grant that role to a user-tenant pair, creating
users are defined as globally unique in keystone
what's anvil?
-joe
On May 9, 2012, at 1:46 PM, Joshua Harlow wrote:
> A question,
>
> I am using anvil to setup the keystone roles/users/tenants.
>
> It seems like the python keystone client has the following command:
>
> client.users.create
>
A question,
I am using anvil to setup the keystone roles/users/tenants.
It seems like the python keystone client has the following command:
client.users.create
Which seems to take in the following:
create(self, name, password, email, tenant_id=None, enabled=True):
I would assume a user name
For anyone following along, this is now being tracked in
https://bugs.launchpad.net/keystone/+bug/962600
On Thu, Mar 22, 2012 at 5:21 PM, Joshua Harlow wrote:
> I’m still confused.
>
> Is there a bug in the keystone client that is causing these attributes to
> not exist?
>
> I am assuming yes, s
I'm still confused.
Is there a bug in the keystone client that is causing these attributes to not
exist?
I am assuming yes, since devstack.org is doing the same calls.
https://github.com/openstack-dev/devstack/blob/master/eucarc#L22
Which should blow up in the same place.
Thx for the explanat
With *all* services, if you know the endpoint you can query them
directly with the auth mechanism (either token or ec2 access/secret).
OpenStack has an identity service (keystone) that returns a catalog of
services (for discovery)
You don't need to look at the catalog if you know the endpoints.
I'm confused.
So this means ec2 won't work because it can't have a service catalog?
All of those variables should of been set:
export OS_AUTH_URL=http://172.21.102.236:5000/v2.0
export OS_PASSWORD=ac31bec851146d3c7f00
export OS_TENANT_NAME=demo
export OS_USERNAME=demo
On 3/22/12 1:39 PM, "Dolph
Accidentally hit send...
Anyway... which does not necessarily correspond to a normal user with a service
catalog.
The error message should explain this and direct you to use an OS_USERNAME,
OS_PASSWORD, OS_TENANT_* and OS_AUTH_URL instead (which can have a service
catalog).
-Dolph Mathews
On
I'm not sure if there's an open bug on this or not (definitely should be), but
you're attempting to perform operations using a SERVICE_TOKEN and
SERVICE_ENDPOINT (
that require
-Dolph Mathews
On Mar 22, 2012, at 1:42 PM, Joshua Harlow wrote:
> Hi all,
>
> When trying to use eucarc
> (https:
Hi all,
When trying to use eucarc
(https://github.com/openstack-dev/devstack/blob/master/eucarc) or the
devstackPY copy called euca.sh (
https://github.com/yahoo/Openstack-DevstackPy/blob/master/euca.sh )
I am getting the following:
++ keystone catalog --service ec2
++ awk '/ publicURL / { pr
That's totally fine. The choice to go with python-keystoneclient was based
on a small sample of votes present at the time. I only asked in case
someone has an alternate, better suggestion - I would want to hear the
argument.
Z
On 12/16/11 7:35 PM, "Dolph Mathews" wrote:
>Me, not being aware tha
Me, not being aware that we were already moving towards supporting
python-keystoneclient, implied that someone was /against/ python-keystoneclient.
I have no objections :)
-Dolph Mathews
On Dec 16, 2011, at 4:56 PM, Ziad Sawalha wrote:
> Who suggested not using python-keystoneclient?
>
>
>
Who suggested not using python-keystoneclient?
On 12/16/11 4:12 PM, "Jesse Andrews" wrote:
>python-keystoneclient is based on python-novaclient, and is already in
>use by horizon as mentioned.
>
>What are the reasons for not using python-keystoneclient?
>
>Jesse
>
>On Fri, Dec 16, 2011 at 1:47
python-keystoneclient is based on python-novaclient, and is already in
use by horizon as mentioned.
What are the reasons for not using python-keystoneclient?
Jesse
On Fri, Dec 16, 2011 at 1:47 PM, Monty Taylor wrote:
> Hrm. For some reason I thought we'd already decided to use the
> 4P/python-k
Hrm. For some reason I thought we'd already decided to use the
4P/python-keystoneclient (it's been a todo list item for me to move it
in to the openstack repos) I take it that we have _not_ decided that we
should use that library as the keystone client library?
On 12/16/2011 10:16 AM, Dolph Math
Well, I'm certainly not planning on writing a client from scratch, so I'd
be happy to hear some discussion on which client we should deem official
and replace the others with.
My only concern is that we provide an intuitive python API supporting the
various auth flows.
-Dolph
On Fri, Dec 16, 201
Dolph Mathews wrote:
> Yes (and there's actually more than 2 floating around, in various
> states); we're moving towards providing a single client, independent of
> keystone, which can be consumed by other projects (including keystone
> itself).
>
> There's no milestone target for this effort yet,
On Fri, Dec 16 2011, Dolph Mathews wrote:
> Yes (and there's actually more than 2 floating around, in various states);
> we're moving towards providing a single client, independent of keystone,
> which can be consumed by other projects (including keystone itself).
>
> There's no milestone target f
Yes (and there's actually more than 2 floating around, in various states);
we're moving towards providing a single client, independent of keystone,
which can be consumed by other projects (including keystone itself).
There's no milestone target for this effort yet, but:
https://blueprints.launchpa
Hi,
I've just a small question about Keystone client code.
Correct me if I'm wrong, but it seems that currently there's Keystone
client code inside python-novaclient as novaclient.keystone. OTOH,
horizon seems to use python-keystoneclient which is not part of
OpenStack.
I don't see the point to
35 matches
Mail list logo
