18:00:33 #startmeeting keystone 18:00:33 Meeting started Tue Oct 13 18:00:33 2015 UTC and is due to finish in 60 minutes. The chair is stevemar_. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:36 o/ 18:00:38 The meeting name has been set to 'keystone' 18:00:40 o/ 18:00:42 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:00:43 \o/ 18:00:52 #topic design summit 18:00:53 * morgan runs away and hides 18:01:02 the schedule is out 18:01:09 well, the keystone one anyway 18:01:11 #link https://mitakadesignsummit.sched.org/overview/type/Keystone#.VhQoFBNVhBc 18:01:30 stevemar_: nice work 18:01:37 i've created etherpads for all the sessions, and pre-populated them with content from our brain dump 18:01:46 oi :) 18:01:56 we can take tuesday off 18:02:08 cross-project day 18:02:12 bknudson: I heard we also get to take monday off 18:02:12 bknudson: there are a few cross project sessions you should consider going to 18:02:30 bknudson-bot does not take days off 18:02:31 like what, service catalog? :) 18:02:34 gyee: yes 18:02:39 stevemar_: is the scedule for x-project ? 18:02:46 but other general x-project 18:02:50 0/ 18:02:53 is there a schedule out for x-project? 18:02:53 marekd: there was a ML topic just sent out for feedback on it 18:03:02 maybe an hour ago? 18:03:08 #link https://etherpad.openstack.org/p/mitaka-cross-project-session-planning 18:03:19 that's the current plan for x-project session 18:03:23 there are A LOT 18:03:28 theres even one for federation 18:03:33 o/ 18:03:36 stevemar_: can't be! 18:03:37 at line 605ish, 18:03:39 what day is cross project/ 18:03:43 tuesday 18:03:46 there was some discussion from sdague and dhelman about the policu X=project 18:03:48 cool 18:03:49 topol: it spans many days i think 18:03:58 ayoung: there is one for policy too! 18:04:03 I think the focus will be on Bug 968696 issue 18:04:03 bug 968696 in Keystone ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung) 18:04:09 all the summit topics should be cross-project 18:04:17 we have a meetup for intra-project 18:04:22 ayoung, yay, congress 18:04:27 I mean policy 18:05:39 so if folks want to add more context to the federation and policy x-project session that would be cool :) 18:06:04 marekd: i think they want actionable items, even if it's just a call to action for more projects to be aware of it 18:06:09 stevemar_: the HMT one is very raw too 18:06:12 stevemar_: so this voting on the etherpad was for everybody or some super heroes? 18:06:26 marekd: lol i think it's just for TC 18:06:34 for what I've been seeing in liberty, we may have some other things to discuss there 18:06:37 they are kinda like a justice league... 18:07:15 stevemar_: that's what i meant 18:07:22 any other questions about the design sessions :) 18:07:38 requests / comments / don't throw tomatoes at me 18:07:55 just kudos 18:08:03 if the area is something you're interested in, please try to populate the etherpad, it's in the sched link 18:08:05 stevemar_, so Friday meetups are going to be like last time at Vancouver? 18:08:16 do whatever 18:08:18 gyee: yep 18:08:19 stevemar_: I think the sched looks good, nicely done :) 18:08:30 i think bknudson wants us to all do code-reviews that day :) 18:08:38 sure, that'll work 18:08:39 stevemar_: can we create a hangout air in the design session for who are not attending the summit? :) 18:09:01 just curious, but are we going to plan on leveraging monday for anything? 18:09:10 lbragstad: there is no summit on monday 18:09:11 raildo: hmm, i will try. at the minimum we'll be updating the etherpad as we go 18:09:11 I assume you're all doing code reviews all the time. 18:09:14 right 18:09:24 stevemar_: ok :) 18:09:32 bknudson: we are :D 18:09:32 lbragstad: monday is for touring tokyo 18:09:50 i imagine that would be the "get into town and get acclimated" day 18:09:51 Mobile* code reviews 18:09:57 yep 18:10:00 ok, works for me 18:10:04 alrighty, neeeeext 18:10:13 I plan on hanging out with the ninjas 18:10:22 jamielennox: you around? 18:10:25 yea 18:10:30 if you can find the ninjas they're not very good ones. 18:10:36 #topic auth plugins 18:11:01 this was something that bknudson brought up in this review: https://review.openstack.org/#/c/177227/ 18:11:32 basically, should we be leveraging "extras" instead of creating new repos 18:11:38 we've got too many repos 18:11:42 oh the package dependency thingy 18:12:01 the justification for keystoneauth-saml2 was because we didn't want to force folks to carry lxml 18:12:10 yes 18:12:17 but with setuptools 'extras' we can specify it in setup.cfg 18:12:18 similarly kerberos 18:12:24 and it's not there by default 18:12:26 jamielennox: yep 18:12:48 I think reviews will go faster if we have fewer repos 18:12:51 so, is this something we want to set a precedent for? 18:12:54 bknudson: agreed 18:13:11 if we can squeeze them back into the repo then that would be easier 18:13:14 only trick might be that we have to do optional imports or something. 18:13:21 bknudson: yep 18:13:21 thats only 1 issue, packaging and consumability are others 18:13:27 bknudson: how does that work? 18:13:44 try: import lxml except ImportError: lxml = None 18:13:50 bknudson: oh lol 18:13:51 this way 18:13:53 I think we have that in a few places already 18:13:57 bknudson: yes 18:14:03 i thought there was smarter way 18:14:18 i'm still not sure how packaging is going to handle this - but i guess that's not a problem for here 18:14:23 there's probably something fancy with optional imports. 18:14:31 silent failure is not good for supportability 18:14:35 bknudson: a decorator or generator 18:14:46 stevemar_: yes, not sure how distro packaging would work unless they just included the kitchen sink 18:15:02 dstanek: well that's an issue for keystone right now isn't it? 18:15:07 similar to http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/__init__.py 18:15:09 gyee: it's not silent - they just don't raise the error until you actually try to use them 18:15:10 bknudson: jamielennox bknudson: so how is it going to work...i pip install keystoneauth and need to install lxml by hand? 18:15:14 we do this technique with ldap now 18:15:24 pip install keystonauth[saml] 18:15:26 marekd: pip install keystoneauth[saml2] 18:15:26 i think there's a specific keystone-ldap package 18:15:36 jamielennox: bknudson not using pip though 18:15:40 stevemar_: yep, i hear the complaints. that's why i say that :-) 18:15:53 packagers can handle it however they want to. 18:16:07 if I was a packager I'd just put it all in keystoneauth 18:16:11 jamielennox: bknudson: ok, any code that already does that so i can start working on squeezing saml2 coe into ksa ? 18:16:16 jamielennox, ok, that's fine then 18:16:26 I hate SAML 18:16:29 ayoung: me too 18:16:44 lxml is an easy dep to carry really, kerberos not so much 18:16:47 zigo: you around? 18:17:05 if i was packaging this i'd just rely on lxml 18:17:12 Kerberos really should be an optional dependency on the session, not on the auth plugin anyway 18:17:37 ayoung, so is x.509 18:17:47 marekd: if you can take a look at it and propose the change and it looks good I think we should go with it. 18:17:53 gyee, X509 is part of the HTTP code base, though 18:17:58 ayoung: x509 is both, kerberos not so much 18:18:00 #action get input from packagers for handling optional libs 18:18:02 we never released keystoneauth-saml2? 18:18:07 bknudson: correct 18:18:40 I would certainly hope distros DON'T include everything as prereqs just because one extra does... leave it up to the operator/ansible/etc. to determine what they need and don't need for optional dependencies 18:18:43 we'll lose the git history unless we do something drastic 18:18:48 they can do that easily enough by looking at the setup.cfg 18:19:40 edmondsw: do you see the setup.cfg when you install the package? 18:19:48 no, but you see it in git :) 18:19:54 edmondsw: who would be looking at setup.cfg though? 18:19:56 meh, i'll poke around and ask zigo, i'll report my findings to the ML 18:20:06 guys writing ansible/etc. 18:20:12 bknudson: i can propose something, but i am not sure how i should structure the code so there is any distinction between pip install keystoneauth and pip install[saml2] 18:20:22 and let's face it... operators who aren't using something like that already have to go to git 18:20:28 pip install keystoneauth[saml2] 18:20:33 stevemar_: i think it's one you should take to the list, lifeless will have an opinion and i'm sure the packagers will as well 18:20:37 marekd: just gotta create entry points 18:20:43 stevemar_: aha 18:20:45 ok 18:20:46 jamielennox: cool 18:20:48 marekd: http://git.openstack.org/cgit/openstack/keystone/tree/setup.cfg#n25 18:20:48 edmondsw: that's part of the complaining i hear 18:20:48 marekd: have a look, keystone itself does it 18:20:56 dstanek, what is? 18:20:58 we already do this in keystone proper with our ldap support 18:21:00 jamielennox: ok 18:21:01 jamielennox: stevemar_: context? 18:21:18 lifeless: what's going to happen with packaging if we put lots of pip optional dependencies 18:21:24 stevemar_: ok, so i am good 18:21:25 edmondsw: having to go to git to figure it out 18:21:27 lifeless: impact to packagers when setuptools has 'extra' dependcies 18:21:27 lifeless: keystoneauth[saml2] 18:21:37 dstanek, that's unsolvable 18:21:38 edmondsw: and setup.cfg doesn't actually tell you what you need for a feature. 18:21:48 dstanek, oh, but it does... 18:21:56 ah right - so they translate to recommended dependencies in the distro world typically 18:21:58 that's exactly what the extras do 18:22:13 they can in principle be translated to helper packages that only express tings in the dependency graph 18:22:33 lifeless: sounds like everything is packaged in 18:22:34 edmondsw: nope, between ubuntu and fedora they have different package names 18:22:44 lifeless: have you heard any complaints from distros about use of extras? 18:22:46 e.g. in Debian it might be python-keystoneauth-saml2 which is empty but has dependencies on the saml2 deps 18:22:50 bknudson: I have not 18:22:58 bknudson: but that is likely low use measurement bias 18:23:09 edmondsw: and then there have been times in the past where a python lib packaged for a dist also have a dep that you have to install 18:23:17 edmondsw: sometimes it's pretty hard 18:23:27 lifeless: so i only know rpm and the recommended doesn't exist there, but do we need to structure this to ensure they are seperatable? 18:23:30 lifeless: so in keystone you can do pip install keystone[ldap], does that mean there's a keystone-ldap package? 18:23:54 lifeless: like obviously having things that might be split be in an __all__ is going to cause problems there 18:23:55 stevemar_: there's a couple different ways it could be translated; thats one of them yes 18:24:05 dstanek, setup.cfg will tell you what you need in python terms... yes, the distro might name their rpm/deb a little differently, but it shouldn't be hard to find 18:24:12 jamielennox: so stuff in __all__ has to be defined always (but could be None) 18:24:27 and we can certainly make recommendations in pbr's docs for redistributors 18:24:34 so I think yeah, a list thread is a good idea 18:24:39 stevemar_: i think keystone itself is less of a concern because it really doesn't matter if you have some extra packages there, keystoneauth on the other hand will be installed everywhere 18:24:50 jamielennox: marekd: it can't be imported by default, so check out the lazy importer we use in ksc -- http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/__init__.py#n52 18:25:00 I don't see any reason why it should make packagers grumpy (other than it being churn vs the status quo) 18:25:29 It should be trivially handlable in deb/rpm/arch etc 18:25:35 bknudson: that got us around a very specific problem, i don't think we should intend to use that always 18:25:41 (since the minimum mechanical transform is an empty dep-only package) 18:25:49 and every system can do tht 18:26:22 lifeless: oh, not actually split the code out into new packages, just the deps 18:26:59 lifeless: makes more sense, not sure what i was thinking 18:27:00 jamielennox: yeah, extras do not imply code split out at all 18:27:20 i guess because we have/can do a clean split between deps 18:27:22 (gonna switch topics in 3 minutes to make sure we have enough time) 18:27:36 stevemar_: do it, resolve to get packager input on list 18:27:37 would it be better to split out the code? if so let's keep separate repos. it's not that big of a deal 18:27:43 jamielennox: rgr 18:27:53 bknudson: that can have high friction costs 18:27:54 to the mailing list! 18:28:07 #topic functional tests in keystone 18:28:12 bknudson: I really think its worth keeping dev easy and low-friction if the externalities are tolerable 18:28:13 bknudson: lets see what packagers say, if it's a problem we keep the repos beause we have them anyway 18:28:24 marekd dstanek the floor is yours 18:28:37 So...looking in to getting IPA up and working for Functional testing...does it have to be Ubuntu 14.04? 18:28:44 keystone is carrying several optional dependencies in requirements.txt that should really be extras in setup.cfg... passlib, oauthlib, pysaml2 18:28:53 mtreinish: fyi ^ 18:29:10 edmondsw: file a bug :P 18:29:15 yeah :) 18:29:16 ayoung: we have centos slaves 18:29:26 dstanek: here? 18:29:29 ayoung: I'm not sure if there are fedora slaves offhand 18:29:31 centos for python 2.6? 18:29:44 stevemar_: i think marekd was just worried about the path we are taking 18:29:44 lifeless, centos? Ubuntu Later than 14.04? 18:29:53 Centos 7? 18:29:53 and if it jives with everyone else 18:30:05 so we basically had a discussion about functional tests and whether things like that: https://review.openstack.org/#/c/203258/ is fine 18:30:35 before we go adding a bunch of functional tests there should be a gate job that at least verifies it works. 18:30:37 marekd: dstanek i think it's good to make sure everyone else knows whats up 18:30:40 or we need to come up with some way to verify 18:30:51 i remember last week there was a concern that functional tests should validate backend (mysql, postgres) not just API responses 18:30:57 the new question is where do the tests go? in keystone or in tempest 18:31:14 dstanek: i'd definitely say keystone 18:31:23 ^^ yes, then the convo earlier on evolved into something like that :-) 18:31:33 i'm guessing it depends what you want the tests for 18:31:37 we can review the tests ourselves 18:31:51 jamielennox: i personally want to be automatize real workflows 18:31:55 if you want them as part of the gate then keystone, if you want them as part of like a validation suite then tempest 18:31:57 we can review changes to tempest, too 18:31:59 real interaction between keystone and idp 18:32:09 and maybe they're faster at doing reviews than we are 18:32:10 real interaction between ksa/ksc and some server (when testing clients) 18:32:12 without any mocks 18:32:27 marekd: that sounds like testing, so i'd say keystone/ksa 18:32:30 ayoung: we have centos7, fedora22 and ubuntu-trusty available 18:32:45 jamielennox: yes 18:32:50 mordred, OK, Centos7 is trivial, as is F22 18:33:16 jamielennox: you know, every change we do with federation i have to build my own env, setup, and run some code to make sure it works... 18:33:20 bknudson: are they faster? 18:33:21 marekd: fwiw, we have functional tests in the shade repo that consume ksa and ksc to do things 18:33:46 mordred: great, we now need to have something for both federations for instance :-) 18:33:47 marekd: I know that does not solve your immediate concern - but just to let you know there are some consume non-mocked tests running currently 18:34:24 marekd: I have nothing configured to test any auth plugins other than v2password and v3password :) 18:34:40 marekd: completely agree 18:34:40 bknudson: my concern is i don't have any clarity for what they will accept and what they won't 18:34:41 mordred: clients was just a part of the 'problem' i think and my understanding federation (as it needs 3rd party peer) is in the greaest need 18:34:42 there's some review stats on http://russellbryant.net/openstack-stats/keystone-openreviews.html vs http://russellbryant.net/openstack-stats/tempest-openreviews.html 18:34:46 mordred: why is nodepool openstck config in system-config? or perhaps I just don't understand the split 18:34:51 marekd: ah! gotcha 18:35:16 mordred: we first need to be able to automatically build federation setup and be able to test server, than we can proceed to clients. 18:35:17 dstanek: I don't know if they have specs or blueprints? probably. 18:35:28 lifeless: because it's templated via puppet because there are things we need to put into via config - project-config is all static files 18:35:55 marekd: this makes sense to me. I will be looking forward to copying and abusing your work once it's done... 18:36:03 marekd: do we care about multi-machine setups here? 18:36:03 dstanek: we do have a qa liaison... 18:36:06 mordred: ah, I thought project-config was 'things for openstack' vs system-config of 'things for folk to reuse' 18:36:11 bknudson: dstanek let's keep the functional tests in house for now 18:36:15 as I want to test that federation works from my side too, but I have no idea how to set it up 18:36:29 mordred, I can help 18:36:32 jamielennox: we will need two keystones for k2k, but i think we agreed that we will try with single machine at the moment. 18:36:33 can we get a gate job that runs the functional tests? 18:36:34 marekd: is it enough to run the IDP on the keystone box and assume we didn't fake anything or do you want to do proper multiple machines 18:36:45 jamielennox: idp like pysaml2 - agreed 18:36:46 (the functional tests that we have now) 18:36:53 bknudson: that would be awesome 18:36:53 bknudson: yes, i'll work on getting one up 18:37:13 dstanek: bknudson: that would be great 18:37:27 stevemar_: only great? 18:37:28 bknudson: i'll add you to the review so i can get your +1 :-) 18:37:37 bknudson: fantabulous? 18:37:41 that's better 18:37:54 dstanek: make it non-voting initially 18:38:00 or do an experimental job 18:38:01 i agree with Tony the Tiger - it's greeeeeaaaat 18:38:05 anyway, guys, please have a look at https://review.openstack.org/#/c/203258/ and up 18:38:31 #action review marek's functional test patches and staneks new gate job 18:38:42 #action review all the things 18:38:50 #undo 18:38:52 Removing item from minutes: 18:38:57 i will be adding more and proceed to something more fancy - authentication. 18:39:04 JFDI 18:39:04 alright 18:39:04 stevemar_: he he 18:39:06 jamielennox: fwiw, we do have mulit-node testing available should you decide you need it 18:39:19 mordred: oh, great 18:39:22 we might need one 18:39:26 at some point for k2k 18:39:28 bknudson: you have the right attitide there 18:39:29 mordred: decided. we need ot 18:39:33 errr. it 18:39:38 cool. we use it to test live migrations currently 18:39:40 uness we can run two keystones on one VM 18:39:48 mordred: sweet, they managed to get that going 18:39:52 oh yah 18:40:04 just use docker. 18:40:05 clarkb is your man who actually fully understands it 18:40:19 noted 18:40:24 bknudson: let's not just use docker - we have absolutely no pre-caching infrastructure for docker in the gate 18:40:40 you could just run two keystones 18:40:48 without extra containers or dockers 18:40:49 which isn't to say we shouldn't grow some - but I believe you'll find getting that solid to be more work than not using it in this particular case 18:41:42 right, we should always be able to run this on different ports or set it up to work 18:41:51 we'll need multiple dbs 18:42:01 yes, backends are the issue 18:42:05 right - devstack is not going to handle this 18:42:07 bknudson: yeah, that's the concern 18:42:22 all it takes is to pass a different db name. 18:42:27 we still need a bunch of devstack plugins, like the ones dstanek was making 18:42:27 stanek was proposing devstack booting a VM with a keystone configured there :D 18:42:32 what about a different table? 18:42:34 it's just multiple config files 18:42:41 lbragstad, nope 18:42:44 nvm 18:42:57 can we also have multiple instances of shibd on a same node? 18:42:59 * lbragstad tries to get the words to come back 18:43:06 gyee: which part? 18:43:08 lbragstad: one day 18:43:09 Can a Keystone K2K with itself? 18:43:18 marekd, for k2k we need shibd 18:43:27 ayoung: it should 18:43:27 ayoung: lol, umm.... i don't know 18:43:36 ayoung, it can 18:43:41 Make that work 18:43:52 ayoung: such config is so ridiculous i've never tried that but.... 18:43:54 i'm not sure we should consider that a successful functional test 18:44:01 jamielennox: exactly 18:44:05 meh, this is all getting a bit off topic, there are other functional configurations, not just k2k 18:44:12 marekd, we tried it and it works fine 18:44:27 * marekd k2k is still far away in the functioal tests island 18:44:33 ++ 18:44:45 lets give ayoung some time to chat about admin-ness 18:44:47 gyee: aha, good to know stuff i helped to make works :-) 18:44:53 Yay 18:45:09 #topic Supressing admin role for non-admin projects 18:45:14 ayoung: ^ 18:45:35 so, the fix is to only allow the admin role on the admin proejct 18:45:37 why? 18:46:03 ayoung: please tell us 18:46:04 becasue so mnuch is hard coded to only check the admin role. THis, essentially, communicates which project is "admin" 18:46:31 Ok,. lets start with Henrynashs suggestion 18:46:34 you don't want admin project to be able to boot instances and stuff, right? 18:46:39 admin should be by choice no accident :) 18:46:51 bknudson, don't care if the ydo, not what it is there for though 18:47:02 "make people update policy" 18:47:14 we can't./..most people don't touch policy 18:47:34 and, even if we were, we would have no way to clear;y communicate "this is the admin project" 18:47:56 we'd have to templatize all of the policy files in glance neutron nova etc 18:48:01 and fill in the project id 18:48:11 we don't because "this is the admin project" is never something we've tried to communicate 18:48:11 and, we don't control the distribution mechanism 18:48:12 ayoung: also, can we have a chained-k2K ? that means a keystone as SP, that needs another keystone SP to provide auth :p nvm 18:48:24 stevemar: what is non-admin project? project name is just a name. How do you define it? 18:48:39 haneef__, there are certain operations not scoped to a proejct 18:49:31 if we don't restrict where the "admin" role comes from, it means that anyone that can assign a role can assign the admin role, and thus compromise security 18:49:50 so, effectively, we have said "only sysadmins can assign roles" 18:49:53 ayoung, we needs to make people update policy or provide a way to make policy changes less painful. 18:49:53 put that in the commit message 18:49:59 which , of course, does not scale too well 18:50:06 david8hu, I tried that route 18:50:10 what's the point of assigning a role if you can only get it under some conditions? 18:50:19 gyee, all the other roles... 18:50:22 aren't policies updated every upgrade? 18:50:31 most important, you can add someone to your own project, or remove them 18:50:44 stevemar_, that is outside the scope of what openstack upstream can control 18:50:53 is it puppte, ansible, chef, or bash? 18:51:29 Dynamic policy was, effectivly, an internalized config management tool to solve this. But, its not going to hap[p[en quickly 18:51:50 so, lets lay off on dynamic policy and just fix the problem first 18:51:50 ayoung, if keystone can store policies for entire openstack, it can modify it too, no? All we have to do is to convince others to use stored policies instead of local files 18:52:01 amakarov, tried. failed 18:52:06 amakarov: same argument 18:52:11 and, we still have the tokenizeation problem 18:52:24 Keystone not only needs to store, it would need to modify 18:52:24 ayoung, what kan be done if we negotiate Horizon team to make a convenient tool to edit them :) 18:52:33 so...lets change what we can control: what goes in the token 18:52:34 ayoung: so i think it's worth asking, how much of a hole are we going to dig ourselves into? 18:52:37 ayoung, Operator still need a way to modify and validate policy even with the dynamic policy route. 18:52:44 stevemar_, none 18:52:46 if we assume admin roles and admin projects are always there 18:52:52 we are already in the hole 18:53:01 were just fuinally deciding to make iourselves dcomfortable 18:53:06 i guess if they don't want this, they just don't set the config option? 18:53:10 right 18:53:17 config option is off by defualt, too 18:53:20 to avoid breaking people 18:53:21 bknudson: dolphm mordred thoughts? 18:53:24 we'll activate it in devstack 18:53:28 err morgan: not mordred 18:53:53 stevemar_, the bottom of a bowl usually contains the sweetest pieces! 18:53:53 put more info in the commit message so it can be documented properly 18:53:54 so my problem is that if you know enough to set the config option, then you presumably know enough to not spray admin around 18:54:05 and as I mentioned before there are service users that need admin 18:54:09 I have thought about a tool to support customizing policies + something to validate the policy changes, something like: my admin does this and that, and then the tool would run against a live cloud and test it 18:54:11 gyee: cc ^ 18:54:17 and they're scoped to service not admin 18:54:25 gyee: I think I have told you about that idea 18:54:26 bknudson: service users need admin because of bad policies in other services 18:54:29 if you trust someone to assign roles, you should trust them to assign roles... someone can setup a role specifically for the purpose of being able to assign roles, if they want to really lock that down 18:54:39 (and should) 18:54:57 smueldmq, tool or API? 18:54:59 so service users indicate we probalby needto make it a list and not a single project 18:55:08 I'm working on updating the patch for that 18:55:27 i know it doesn't exist, but i'd love to see a list of places where services treat "admin" as not scoped to the project in the token - cause they're just bugs 18:55:28 amakarov: I think Timur(tsufiev) have started looking at the policy editor in horizon, but holding that off for now. 18:55:29 samueldmq, I have Horizon guys who wolunteered to code the editor if we provide the data format 18:55:31 edmondsw, admin role is just different from other roles 18:55:45 ayoung, in which sense do you mean? 18:55:55 edmondsw, it is hard coded everywhere, and with no scope check 18:56:01 Let's get x509 going for service users, so we don't need to worry about it no more ;) 18:56:04 yeah... it's a mess we need to fix 18:56:06 this is just acceptance of the state of things 18:56:16 david8hu, orthogonal 18:56:19 I should be able to say joe is an admin on project A, bob is an admin on project B, etc. 18:56:25 david8hu, don't confuse authentication with authorization 18:56:37 edmondsw, we'll call it soemthig other than admin 18:56:39 call it manager 18:56:40 and I'm an admin on project C, which is a parent to both of those, so I'm effectively an admin on A and B as well 18:56:53 make it heirarchical 18:56:56 edmondsw, nothing checks "admin on project" 18:57:02 IT SHOULD, though 18:57:05 we need to fix that 18:57:06 edmondsw, things check "on proejct" or "admin" 18:57:11 edmondsw, forget should... 18:57:13 that's the problem 18:57:20 so much of this should have been done diffeerntly 18:57:26 we are in a world of legacy 18:57:34 so we punt? 18:57:44 gyee: well, some CLI that uses the oepnstack APIs to validate what users can do what 18:57:47 on admin, sure...but 18:57:49 edmondsw, I think "admin" term should dissolve when we enable better role assignment management 18:57:51 ayoung, let's help move it out of legacy 18:57:52 here is the best part: 18:58:00 it lets us focus on splitting policuy into two parts 18:58:14 let the proejct keep what they have: effectivly checking the scope of hte porject 18:58:19 match the tokn e 18:58:28 we can then do dynamic policy in middleware 18:58:29 so we have a distinction betwee project admin and admin project admin? 18:58:34 ayoung: i think you've got something here 18:58:50 it just needs to be baked a bit longer, add some docs and such like bknudson asked 18:58:58 see, checking to see what the scope of the resource \requires a database lookup for most things 18:59:03 we don;t want that in dyanmic poluicy 18:59:05 it can't break anything if it's optional 18:59:06 changing it breaks things 18:59:11 we only want to do the role check 18:59:15 bknudson: yep 18:59:26 alright, lets' not creep onto infra time 18:59:28 so...this lets us plan on doing that in the future 18:59:35 #endmeeting