[openstack-dev] [keystone][adjutant] Sync with adjutant team

Adrian Turjak adriant at catalyst.net.nz
Mon Sep 10 11:44:40 UTC 2018


As I'm not attending the PTG, I thought I might help put some words
against these questions for when you're having the meeting. Plus even if
I did want to be online, it would be something like 4am my time.

Stein will likely see a lot of Adjutant refactor work as I get myself
back onto the project full swing, and onboard a new dev who will be
helping me. As that work happens I'll be in a better place to reevaluate
exactly where Adjutant sits around Keystone, so I'll be updating you all
as much as I can, but for now have some answers that may help.



## They are building on top of keystone, is there anything we can do to
make those interactions easier?

Most of the admin level APIs we interact with do the work well enough
and the 'primitives' in Keystone work as a base layer for us to build
account management logic on top of. I think there was something with
querying roles up and down a tree that was awkward, but I think I found
ways of doing that which didn't amount to silly numbers of API calls.

I think the only real thing I can think of which was awkward is that
Keystone doesn't have a concept for quota in regards to how many
projects a subtree can have (and how deep that tree can be). In my WIP
HMT management code I'm faking it by sticking a key=value in the root
project extras blob and doing the checking in my code, and I guess I can
potentially switch to using the limits API once that's considered
stable, although I don't know how far Keystone itself wants to go down
the route of actually implementing quota checking on its own resources.
My WIP code has quota checking implemented in Adjutant and because of
how it works it likely will stay there as right now that code does quota
as: "allowed to create x number of projects across the whole tree within
a period of y days, to a depth of z" where x, y, and z have default
values in Adjutant or key=values present in the root project extras blob
if a project tree needs custom quotas. As for checking quotas, that's
done against total project creations across a whole tree based on the
number of previous subproject creation tasks in Adjutant in the same tree.


## Is there anything we should incorporate into keystone? maybe after
all the scope work lands in Stein?

There are indeed places where with some work the Keystone APIs (with
proper policy and roles) could provide a replacement for some of the
work in Adjutant, and some cases where it just doesn't make sense
because the parts of that workflow aren't things Keystone is meant to do
(anything with emails or that may need to talk to external systems). The
annoying part here though is that while there are definitely things
Adjutant can do, or will do that make sense to have in Keystone, other
parts of that which a deployer may want to link with external systems or
add more workflow logic on top of don't make sense in Keystone. I'm torn
because there are a lot of small features I could propose we add to
Keystone, but then I doubt I'd be able to use them because I'd need to
still keep elements of them pluggable in Adjutant itself, or would still
write logic around, at which stage working with the primitives is
somewhat easier.

What I might do is make a list and see what 'could' work in Keystone,
and if I could find a way to still use it in Adjutant. If I can still
use it, great, if not, we can evaluated it anyway and consider it as a
minor quality of life improvement to Keystone without an Adjutant. That
way Keystone potentially gains features that makes sense for it, but if
Adjutant is around they can be disabled (or blocked with policy) and
Adjutant's more flexible/complex variants can be configured by the
deployer. The worry though is that you end up with two cloud variants
with slightly similar features, but that's always going to be the case
(Keystone + Adjutant vs just Keystone), the question is if adding
similar overlapping features may prove too confusing.


## Is there anything we need to be aware of with the scope work in Stein
that needs to be communicated to them?

Not that I'm entirely aware of? Maybe some of the internals of Adjutant
will need to change as to how Adjutant's admin user interacts with
Keystone (as it likely will use system scope to have access to
everything), but all the assignments that Adjutant manages for users are
in project scope. Need to really play with and figure this out, not sure
how much is really changing that will cause us pain.



More information about the OpenStack-dev mailing list