On 16/09/14 13:54, Devananda van der Veen wrote:
On Sep 15, 2014 8:20 AM, "James Slagle"<james.sla...@gmail.com>  wrote:
>On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy<sha...@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
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.


OpenStack-dev mailing list

Reply via email to