Open Stack

Hi Florian,

great to hear that your problem is solved.

As I pointed out, in Liberty you actually do not need the
"heat_stack_owner" role at all. Just make sure that in your heat.conf the
following option is set to empty value (which AFAIK is default in Liberty):

# Subset of trustor roles to be delegated to heat. If left unset, all roles
of
# a user will be delegated to heat when creating a stack. (list value)
      trusts_delegated_roles =

(that's new line right after after "=", for oslo_cfg to parse empty
ListOpt).

At some point, heat_stack_owner role was used by default as a single role
to be passed via trust, but now we can pass all roles at once without a
need of a special role.

So to avoid future confusion, you can consider deleting the
heat_stack_owner role and strictly advise people to not use heat_stack_user
role for actual (human) OpenStack users (this one is internal for Heat).
You could also rename that role to anything less confusing (like
"heat_internal_do_not_use" :) ) and reconfigure heat.conf and heat's
policy.json to use that name as a role for Heat-internal users.

Cheers,

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Tue, May 17, 2016 at 5:29 PM, Florian Rommel <
florian.rommel at datalounges.com> wrote:

> Hi, thank you for pointing it out, apparently you need to have one of the
> roles applied in Liberty (which is what we used), but my demo user had both
> applied. If then chooses the lower level access, hence no access. Once I
> gave the user only heat_stack_owner i could deploy stacks within the normal
> projects as normal users.
>
> Thank you again.
>
> //Florian
>
> On 17 May 2016, at 16:37, Pavlo Shchelokovskyy <
> pshchelokovskyy at mirantis.com> wrote:
>
> Hi,
>
> are you sure that's "heat_stack_owner" and _not_ "heat_stack_user" role
> that is assigned to your normal, non-admin user? These are frequently
> confused, but there's a great deal of difference between them, the latter
> role indeed has almost no access to Heat API.
>
> Also, what OpenStack version are you using? AFAIR starting from Kilo (or
> may be even later maintenance releases of Juno) one does not actually need
> the heat_stack_owner role altogether, all user roles should be passed via
> trust by default (you have to make sure Heat is configured to use Keystone
> V3 for that).
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Tue, May 17, 2016 at 4:19 PM, Florian Rommel <
> florian.rommel at datalounges.com> wrote:
>
>> Hi, all, most of our major hurdles are now gone with Openstack and it
>> looks almost all great now..
>>
>> Now the tricky part. I have gotten into HEAT and have written many
>> templates and actually very complex ones too and I would love for normal
>> users and other tenants to be able to use them but I keep getting an error
>> retrieving stack list.
>> The user has heat stack owner assigned to him and i can see orchestration
>> in the dashboard but no stacks can be retrieved nor looked at the resource
>> types. What exactly kind of permissions/groups does the user need to be in?
>> Thanks again for any help already.
>> when i source the demo rc file i get:
>>
>> root at control:~ # source .opendemo
>> root at control:~ # heat stack-list
>> ERROR: You are not authorized to use index.
>> root at control:~ #
>>
>> while the admin rc gives:
>>
>> root at control:~ # heat stack-list
>>
>> +--------------------------------------+------------+-----------------+----------------------------+--------------+
>> | id                                   | stack_name | stack_status    |
>> creation_time              | updated_time |
>>
>> +--------------------------------------+------------+-----------------+----------------------------+--------------+
>> | e7ca31f9-cd14-4f98-9f71-566ef69809c0 | Test4      | CREATE_COMPLETE |
>> 2016-05-17T12:37:33.684783 | None         |
>>
>> +--------------------------------------+------------+-----------------+----------------------------+--------------+
>> root at control:~ #
>>
>> only difference is the project name and username/password.
>>
>> Best regards,
>> //FR
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160517/fdb78df9/attachment.html>