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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev