Open Stack

On 16/09/14 13:54, Devananda van der Veen wrote:
> On Sep 15, 2014 8:20 AM, "James Slagle"<james.slagle at gmail.com>  wrote:
>> >
>> >On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy<shardy at redhat.com>  wrote:
>>> > >
>>> > >The initial assumption is that there is some discovery step (either
>>> > >automatic or static generation of a manifest of nodes), that can be input
>>> > >to either Ironic or Heat.
>> >
>> >I think it makes a lot of sense to use Heat to do the bulk
>> >registration of nodes via Ironic. I understand the argument that the
>> >Ironic API should be "admin-only" a little bit for the non-TripleO
>> >case, but for TripleO, we only have admins interfacing with the
>> >Undercloud. The user of a TripleO undercloud is the deployer/operator
>> >and in some scenarios this may not be the undercloud admin. So,
>> >talking about TripleO, I don't really buy that the Ironic API is
>> >admin-only.
>> >
> When I say the ironic API is admin only, I'm speaking to the required
> permissions for accessing it. One must be authenticated with keystone
> with the "admin" privilege. Borrowing from the ops guide:

In most contexts "admin only" means that the default policy.json file 
requires the "admin" role in the current project in order to access a 
particular API endpoint. If you are relying on the is_admin flag in the 
user context and not policy.json then it's likely you are Doing Keystone 
Wrong(TM).

> " An administrative super user, which has full permissions across all
> projects and should be used with great care."
>
> I'm not sure how TripleO is dividing operator and admin in the
> undercloud - so I just want to be clear on what you mean when you say
> "may not be the undercloud admin". Simply put, to use Ironic in the
> undercloud, you must have "admin" privileges in the undercloud -- or
> you need to disable Ironic's auth entirely.

TripleO can presumably deploy any policy.json file they like in the 
undercloud. It's not entirely surprising that some operations that might 
are admin-only in an overcloud might need to be available in the 
undercloud to "ordinary" users - who, after all, have permissions to 
create entire overclouds - despite them not being admins of the 
undercloud itself.

cheers,
Zane.