<div dir="ltr"><div class="gmail_extra">Looking at implementations in Keystone and Nova, I found the only use for is_admin but it is essential.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Whenever in code you need to run a piece of code with admin privileges, you can create a new context with  is_admin=True keeping all other parameters as is, run code requiring admin access and then revert context back.</div>

<div class="gmail_extra">My first though was: "Hey, why don't they just add 'admin' role then?". But what if in current deployment admin role is named like 'TheVerySpecialAdmin'? What if user has tweaked policy.json to better suite one's needs?</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So my current understanding is (and I suggest to follow this logic):</div><div class="gmail_extra">- 'admin' role in context.roles can vary, it's up to cloud admin to set necessary value in policy.json;</div>

<div class="gmail_extra">- 'is_admin' flag is used to elevate privileges from code and it's name is fixed;</div><div class="gmail_extra">- policy check should assume that user is admin if either special role is present or is_admin flag is set.<br clear="all">

<div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>