Terry Howe wrote on 06/19/2015 10:22:51 AM:
> From: Terry Howe
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 06/19/2015 10:25 AM
> Subject: Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create
> --project $projid does not
On Fri, Jun 19, 2015 at 12:30 AM, Matthias Runge wrote:
> On 18/06/15 17:58, Dolph Mathews wrote:
>
>> This was entirely intentional, in order to replace the implicit role
>> assignment behavior in v2 with an explicit behavior in v3.
>>
>>
> I must admit, this is quite irritating, as the command
On 18/06/15 17:58, Dolph Mathews wrote:
This was entirely intentional, in order to replace the implicit role
assignment behavior in v2 with an explicit behavior in v3.
I must admit, this is quite irritating, as the command line client still
offers the --project ability; dropping this silently
This was entirely intentional, in order to replace the implicit role
assignment behavior in v2 with an explicit behavior in v3.
The default_project_id attribute (***emphasis*** mine):
> References the user's default project against which to authorize, if the
API user does not explicitly specify o
On 06/18/2015 06:43 AM, Raildo Mascena wrote:
Hi Rick,
In Keystone, Domains are the container of users, so a user belongs to
a domain and you can grant role assignments for projects.
With this call that you made, you will set the project default to this
user, after that you need to grant a r
Hi Rick,
In Keystone, Domains are the container of users, so a user belongs to a
domain and you can grant role assignments for projects.
With this call that you made, you will set the project default to this
user, after that you need to grant a role for this user in this project.
So, you can do:
Using admin token credentials with the Keystone v2.0 API and the
openstackclient, doing this:
# openstack project create bar --enable
# openstack user create foo --project bar --enable ...
The user will be added to the project.
Using admin token credentials with the Keystone v3 API and the
op
