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