Tuesday, 2015-06-02

jamielennoxbigjools: we tend to be strict00:05
bigjoolsI can do strict00:06
samueldmqjamielennox, hi00:11
samueldmqjamielennox, you already have ds patches for v3 ? :-)00:11
jamielennoxsamueldmq: if only it was just devstack :(00:11
jamielennoxneed https://review.openstack.org/187094 for ksc00:12
samueldmqjamielennox, :/ is that ec2 stuff related ? or you need to get that merged to then have time for ds ?00:12
jamielennoxhttps://review.openstack.org/187127 for osc00:12
jamielennoxthen devstack patches start https://review.openstack.org/18667800:13
*** gokrokve has quit IRC00:13
*** zzzeek has quit IRC00:14
*** gokrokve has joined #openstack-keystone00:14
samueldmqjamielennox, why do the other gates fail ?00:16
jamielennoxsamueldmq: there is an auth issue with osc00:16
jamielennoxso need that one as well00:17
samueldmqjamielennox, and don't forget to run 'check experimental' to see how things are progressing :-)00:17
jamielennoxsamueldmq: i haven't gotten it to run to the end on my own machine yet :)00:17
*** gokrokve has quit IRC00:18
samueldmqjamielennox, k :)00:20
*** someara2 has quit IRC00:25
*** someara2 has joined #openstack-keystone00:25
samueldmqjamielennox, looking at #187094, I found some issues in the copyrights00:29
jamielennoxsamueldmq: oh, yea ok - that's because i c&p the file from v200:29
*** someara2 has quit IRC00:30
openstackgerritJamie Lennox proposed openstack/python-keystoneclient: Add EC2 CRUD credential support to v3 API  https://review.openstack.org/18709400:30
lifelessjamielennox: did you just say 'thats ok'....'c&p' ?00:32
jamielennoxlifeless: i then went and fixed it - but i'm always weird about changing copyright headers on files00:33
jamielennoxlifeless: the fact that file exists at all is a concern for everyone00:33
*** gyee has quit IRC00:34
samueldmqjamielennox, why is that defining a __repr__ ? I don't see that on other resources00:36
samueldmqjamielennox, is tht what is returned when we print it ?00:36
jamielennoxsamueldmq: it came from the v2 file00:36
samueldmqjamielennox, cool00:36
jamielennoxi didn't see any reason to remove it00:36
samueldmqjamielennox, ++00:37
samueldmqjamielennox, is there any diff between /v3/ec2.py and /v2.0/ec2.py00:38
jamielennoxsamueldmq: just the imports i think00:38
jamielennoxoh - i removed the EC2().delete function - cause as far as i can tell it must be broken in v2 :p00:38
samueldmqjamielennox, yeah, that's the only thing that changes00:39
samueldmqjamielennox, isn't there any way to easily re-use that code?00:40
samueldmqjamielennox, (I am not against your approach, I am just looking at the possibilities :))00:40
jamielennoxsamueldmq: we haven't for anything else - but for everything else there is generally at least some difference between v2 and v300:41
jamielennoxit's possible, i don't know if it's worth it00:42
samueldmqjamielennox, ksclient code is cool :)00:42
jamielennoxsamueldmq: it's really not00:42
samueldmqjamielennox, at least not for now, maybe in a future patch00:42
samueldmqjamielennox, what doesn't make you happy in ther ,00:42
jamielennoxsamueldmq: amongst other things the base CRUD create etc methods get in the way - you can see a lot of managers ignoring them and going straight to the _get/_post functions to get around them00:44
jamielennoxonce you start talking about how it auths there is a long list of problems there00:44
jamielennoxbut essentially we can't break any existing behaviour so we've had to build hack on top of hack00:44
samueldmqjamielennox, :/00:44
jamielennoxwhen it was initially built it was a backend for the CLI, so there are a lot of assumptions that don't work for a normal library00:45
jamielennoxanyway there are plans afoot to fix it00:45
samueldmqjamielennox, ++00:47
samueldmqjamielennox, btw, what exactly are ec2 credentials ?00:48
jamielennoxec2 is aws's compute service, the way aws does auth is with a access_id and secret key which you sign messages with00:48
jamielennoxi don't know why but at some point there was the intention that nova was going to be EC2 compatible00:49
jamielennoxand so keystone had to know how to auth with these credentials00:49
jamielennoxi think now they are mostly unused except for heat who uses them as a hack around the limitations in trusts00:49
*** nkinder__ has joined #openstack-keystone00:50
jamielennoxi've never used them myself00:50
samueldmqjamielennox, me neither (obviously seen from my question) :p00:50
samueldmqjamielennox, we shouldn't redefine the tests in v3/test_ec2.py00:51
samueldmqjamielennox, just create the file, and the class EC2Tests should inherit from the class EC2Tests from v2.à00:51
samueldmqjamielennox, makes sense?00:51
*** sigmavirus24_awa is now known as sigmavirus2400:52
*** _cjones_ has quit IRC00:52
samueldmqjamielennox, the same for ec2.EC2Manager00:55
samueldmqjamielennox, left one last review, let me know if you disagree with what I suggested00:56
jamielennoxsamueldmq: i'm torn, they should be different things but it's just the server side implementation is stupid00:59
*** lhcheng has quit IRC01:01
samueldmqjamielennox, hmm ... and actually if you hadn't removed the  'def delete(self):' in EC2, we didnt need to redefine that at all01:02
samueldmqjamielennox, actually that should happend to any entity that hasn't changed from v2 to v301:02
samueldmqjamielennox, and maybe placed in a separate directory other than v2.0 and v301:02
*** lhcheng has joined #openstack-keystone01:03
*** ChanServ sets mode: +v lhcheng01:03
samueldmqjamielennox, but well ... one thing at a time :)01:03
*** lhcheng has quit IRC01:07
samueldmqjamielennox, currently looking at the osc change01:08
jamielennoxthere's a bug in the OSC change01:09
jamielennoxit says identity.tenants and it's supposed to be identity.project01:10
samueldmqjamielennox, is there any difference between /identity/v3/ec2creds.py and /identity/v2.0/ec2creds.py ?01:12
jamielennoxi think just that bug i mentione01:12
samueldmqjamielennox, is the bug in v2.0? (in the v2.0 endpoint it says project, when it should be tenant)01:12
jamielennoxno, it's a c&p mistake, it's supposed to be tenants in v2 but projects in v301:12
jamielennoxbut i know it's OSC policy that they will replicate the code between versions01:13
jamielennoxbecause that way you can fix inconsistencies in individual APIs01:13
samueldmqjamielennox, yeah makes sense, as it is the cli ..01:14
* morganfainberg lurks in the corner of the airport01:15
samueldmqmorganfainberg, o/01:15
morganfainbergjamielennox: i pay so little attention to anything beyond the apache license01:15
samueldmqjamielennox, in the osc change ... only the copyright to be chagned01:16
samueldmqjamielennox, and a small nit in a comment01:16
jamielennoxmorganfainberg: yea, i have no idea what the policy is on assigning copyright any more01:17
morganfainbergjamielennox: my rule is "i don't"01:17
jamielennoxi know if i more or less c&p a file i'm not supposed to change it01:17
jamielennoxmorganfainberg: same01:17
morganfainbergand if someone complains... then i'll fix it01:17
samueldmqjamielennox, morganfainberg even the year ?01:17
morganfainbergand appologize then01:17
jamielennoxsamueldmq: i really don't know01:17
morganfainbergsamueldmq: i'd remove the copyright over changing the year01:17
morganfainbergif i change anything it'll be removing those things01:18
morganfainbergmy personal rule01:18
morganfainbergand so far, no one has complained01:18
* morganfainberg doesn't go out of the way to remove them01:18
samueldmqmorganfainberg, remove the whole copyright ?01:18
morganfainbergif i am changing copyright headers01:19
morganfainbergthat is my rule. i'd remove them vs. "correct" them01:19
samueldmqmorganfainberg, ah yes , and just keep the license thing01:19
jamielennoxi don't think copyright headers make sense on a file that has had half a dozen companies change them01:19
morganfainbergi don't like them in *every* file. we have a git log if someone wants to know who did what for what company01:19
morganfainbergjamielennox: ++01:19
dstanekmorganfainberg: +++01:19
stevemarjamielennox, btw, what did you want to do about https://review.openstack.org/#/c/187103/ ?01:20
morganfainbergstevemar: oh hai01:20
samueldmqyeah, we should remove them all :)01:20
stevemarmorganfainberg, heyooo01:20
morganfainbergsamueldmq: that is treacherous waters.01:20
samueldmqI will propose a bp, 'no more copyrights'01:20
samueldmqand see things exploding01:20
jamielennoxstevemar: what ever you like, i just noticed the mistake and fixed it01:20
morganfainbergsamueldmq: don't go out of your way to remove them. this has gone rounds w/ the TC and such01:20
morganfainbergit's not a winning battle01:20
morganfainbergbetter to ignore them.01:21
samueldmqmorganfainberg, (in fact I was only kidding) :)01:21
samueldmqI don't want to struggle in that front01:21
jamielennoxmorganfainberg: weigh in on https://review.openstack.org/#/c/187094/ i'm inclined to replicate the code because it should be different for v2 and v3 - and this is what OSC does01:22
dstanekmorganfainberg: what is the legality of a copyright given our cla?01:22
stevemarjamielennox, cool enough of a reason for me01:22
jamielennoxi could figure out some way of inheritting v3 from the v2 managers and tests but i don't know it buys us anything01:22
morganfainbergdstanek: basically CLA wins01:23
dstaneki think it's pretty explicit in that you give away most traditional copyright rights01:23
morganfainbergdstanek: afaik01:23
morganfainbergjamielennox: hmm.01:23
morganfainbergjamielennox: you could common class important things01:23
morganfainbergbut meh01:23
morganfainbergreplicating code is ok01:23
morganfainbergesp. if things start varying more01:24
jamielennoxright, i could figure out some multiple inheritence way to share stuff01:24
morganfainbergjamielennox: MixIns! (no don't)01:24
jamielennoxright - i don't think it helps readability at all01:24
jamielennoxthere are lots of places between v2 and v3 where we essentially duplicate code,01:25
jamielennoxespecially in tests01:25
samueldmqI think we could put the common code in a separate directory (other than v2.0 and v3)01:25
samueldmqbut not sure how worth it could be01:26
morganfainbergsamueldmq: eh.01:26
* morganfainberg shrugs01:26
* morganfainberg is pretty non-committal about that particular thing01:26
jamielennoxsamueldmq: there isn't a lot of interest in fixing CRUD for ksc01:26
morganfainbergjamielennox: yep01:27
jamielennoxwe're taking the bits we want over to keystoneauth and hopefully the SDK will come along and take the rest of it off our hands completely01:27
morganfainbergbasically limp it along for SDK and KSA to take over01:27
samueldmqjamielennox, hmm, so if we have been doing that (copying code) in other places, and we have those plans01:28
samueldmqjamielennox, maybe there isn't a good reasong to try and re-use the code01:28
samueldmqjamielennox, (not completely sure about the tests though, as they are 100% the same)01:29
* morganfainberg deprecates keystoneclient (j/k!!!)01:29
jamielennoxsamueldmq: if i didn't need it for OSC i wouldn't have implemented it at all01:29
jamielennoxmorganfainberg: one of those joking/not joking situations01:30
morganfainbergsorry not sorry? ;)01:30
samueldmqjamielennox, I don't have a hard concern on that ... if others (morganfainberg stevemar ?) agree with that duplication01:31
morganfainbergsamueldmq: it's really a question of effort.01:31
samueldmqjamielennox, I am not against it.. let's make that move01:31
samueldmqmorganfainberg, yeah I see ... how worth it that could be01:31
morganfainbergi'm totally willing to support people making that code better01:31
morganfainbergbut if really if you have better things to work on, please do.01:32
morganfainbergespecially KeystoneAuth or similar types of initatives that directly improve our user's experience01:32
* samueldmq needs to take a look at keystoneauth01:32
morganfainbergimproving this part of keystoneclient is not *really* a huge win01:32
morganfainbergsamueldmq: please do. it's starting to shape up01:33
samueldmqis keystoneauth the new repo ?01:33
*** radez is now known as radez_g0n301:33
morganfainbergnext release should move it to keystoneauth1 and a virtual keystoneauth package01:33
morganfainbergsamueldmq: yeah it's openstack/keystoneauth01:33
samueldmqmorganfainberg, cool, I will take a look01:33
samueldmqmorganfainberg, is there doc about it as well  ?01:33
* morganfainberg needs to bug dhellmann about getting a keystoneauthv1 branch01:33
morganfainbergsamueldmq: the readme. but it's really about taking the session code out of keystoneclient and fix it.01:34
* samueldmq could simply checks if there are docs instead of asking everything01:34
morganfainbergand jamielennox 's blog posts01:34
* samueldmq apologizes01:34
morganfainbergbut we need more docs01:34
*** alanf-mc has quit IRC01:34
morganfainbergjamielennox: ping01:35
jamielennoxsamueldmq: don't apologise - there is really no where else you could learn about this stuff at the moment than iRC01:35
jamielennoxmorganfainberg: i've been chatting for about 40 min...01:35
ayoungNAKED PING!01:35
*** boris-42 has quit IRC01:35
*** ctracey has quit IRC01:35
samueldmqjamielennox, +1'ed the ksclient change01:36
*** briancurtin has quit IRC01:36
*** serverascode has quit IRC01:36
samueldmqjamielennox, thx :)01:36
samueldmqayoung, your naked ping made people disconnect01:36
samueldmqayoung, please don't do that agian :)01:36
morganfainbergayoung: ping01:36
morganfainbergayoung: ping01:36
ayoungmorganfainberg, do you really want to start this?01:36
samueldmqmorganfainberg, please :(01:36
morganfainbergayoung: only doing it in response of your announcement to the channel ;)01:37
morganfainbergdstanek: you around?01:37
morganfainbergdstanek: have a question for you if you are.01:37
dstanekmorganfainberg: yes01:37
samueldmqmorganfainberg, nice thanks, I will take a look at ka, as I find some free time in the policy stuff + reviews01:37
ayoungdstanek, is no longer01:37
morganfainberghm. is Lin around?01:38
ayoungsamueldmq, I think I need to revamp the policy overview01:38
openstackgerritQiming Teng proposed openstack/keystone: Allow a user to get his own user information  https://review.openstack.org/18129801:39
ayoungadd in the new specs about "subsets" and the endpoint binding...01:39
dstanekayoung: :-P01:39
samueldmqayoung, I am ok if you need .. I should already updated that spec, but time has been thigh, sorry01:40
samueldmqayoung, I am ok if you need to add more things in there01:40
samueldmqayoung, btw, what is that tokens subset thing01:41
openstackgerritayoung proposed openstack/keystone-specs: unified policy file  https://review.openstack.org/13465601:41
samueldmqayoung, this will fail pep8  ^01:41
ayoungdstanek, samueldmq the overview spec is the one I am least concerned with getting approved01:41
ayoungIt is really there just othave an official document for the overall strategy01:42
morganfainbergeverything fails pep8 :P01:42
samueldmqayoung, your commit message has 2³² chars :p01:42
ayoungso long as the smaller specs keep making progress,we are headed in the right direction01:42
openstackgerritayoung proposed openstack/keystone-specs: unified policy file  https://review.openstack.org/13465601:42
samueldmqayoung, ++ makes sense01:43
*** briancurtin has joined #openstack-keystone01:43
samueldmqayoung, but I think we should agree in all the points of the general approach01:43
ayoungsamueldmq, its what I get for editing in the Browser window.01:43
*** ctracey has joined #openstack-keystone01:43
samueldmqayoung, and then get that merged to get people looking at the other specs01:43
samueldmqayoung, hehe01:43
*** serverascode has joined #openstack-keystone01:44
ayoung"Let me explain:"  http://24.media.tumblr.com/tumblr_lnlxjw3rAo1ql9pqpo1_500.gif01:45
samueldmqayoung, haha01:46
samueldmqayoung, btw, I am looking at the Subset Tokens spec01:47
samueldmqayoung, the user requesting the token has to say it wants a subset of roles/endpoints ?01:47
openstackgerritMerged openstack/keystone: Improve error message when tenant ID does not exist  https://review.openstack.org/13125501:47
jamielennoxahh - at this point i feel like glance is my v3 nemesis01:48
jamielennoxi guess along with swift and ironic and a couple of others01:48
jamielennoxso yea, maybe nemesis is strong - but rah!01:49
ayoungsamueldmq, yep.  We treat the existing behavior as the default unless specified01:50
*** blewis has joined #openstack-keystone01:50
ayoungsamueldmq, it will allow a user to remove roles from a token so the token only has the minimal required to perform the work requested01:50
samueldmqayoung, subsets of roles should be something delegated right ? This way looks to be something requested01:50
samueldmqayoung, not sure I am understanding it correctly, still looking at the spec01:51
ayoungsamueldmq, trusts actually do that already01:51
ayoungyou can create a trust with a subset of your roles01:51
samueldmqayoung, why do we need to request a token with only a subset of roles ?01:51
samueldmqayoung, how does the user know what roles he need ?01:51
ayoungthis is to limit the exposure on a given token.  If you know you only need the "read_glance" role when sending a token to Nova, you don't send a token with "write_image_to_glance" on it01:51
samueldmqayoung, he has no access to the policy01:51
ayoungsamueldmq, right now, there is no clear way to know.  We need other BPs implemented before we can make use of this01:52
ayoungbaby steps01:52
ayoungto start with, and admin  could say, or publish the policy.  We'll get better tooling over time01:52
samueldmqayoung, yeah, and you're in the almost last steps .. I can't see the path ;)01:52
ayoungits all necessary, but this change has to be ther in order for the rest of it to be usefukl01:53
samueldmqayoung, anyway, I need to take a better look at that spec before having a concrete opinion over that01:53
*** sigmavirus24 is now known as sigmavirus24_awa01:53
ayoungalso, with implied (inherited) roles, a user could then ask for an implied role instead of the explicitly assigned...but I am holding off on that part until we get there01:53
samueldmqayoung, btw, talking about what goes in the token01:54
samueldmqayoung, I think we should add parent_id in the token, so that would simplify life for other projects that need, let's say, enforce hierarchical quota01:54
samueldmqmorganfainberg, dstanek cc ^01:55
*** boris-42 has joined #openstack-keystone01:55
*** blewis has quit IRC01:55
ayoungparent_id for project?01:55
samueldmqayoung, in the token, we specify the project_id .. I am saying we should specify its parent as well01:56
ayoungsamueldmq, nope01:56
samueldmqayoung, so when nova wants to enforce quota01:56
ayoungcuz we care about the whole chain01:56
samueldmqit doesn't need to get a project from keystone all the time01:56
ayoungit might not be parent,  but great-great-grandparent01:56
ayoungfor quota01:57
samueldmqyou only cares about your parent01:57
ayoungit is nested arbitratily deep01:57
ayoungbut my quota might be set 3-6levels higher01:57
samueldmqyou are ok with your parent, and so on01:57
samueldmqayoung, yes, and that must be set level by level01:57
ayoungif we know the project ID, we can deduce partnet, and so on up the chain.  If that is not the case, something bigger than this is wrong01:57
samueldmqayoung, so the children quota is always <= parent's quota01:58
ayoungdamn caps lock01:58
samueldmqayoung, I still think it's enough :p01:59
samueldmqayoung, if you need to, lets say, increase your quota, that should be ok if your parent still have slots01:59
ayoungsamueldmq, and if they don't...you get a token for the parent...and so on up the chain....hmmm02:00
dstaneksamueldmq: so quota is always defined on the direct parent?02:00
samueldmqdstanek, children quotas are based on the parent's quota02:00
ayoungsamueldmq, then "set quote for child" should be done using a parent project scoped token, not the child02:01
samueldmqdstanek, and who cares about the parent quota ? the grandparent ..02:01
*** davechen__ has quit IRC02:01
morganfainbergjamielennox: i'm going to propose a new config for keystonemiddleware02:01
*** davechen1 has joined #openstack-keystone02:01
jamielennoxmorganfainberg: mmmm02:02
*** liusheng has quit IRC02:02
morganfainbergjamielennox: where we take [keystone_auth_token]\memcached_servers over [default]02:02
samueldmqayoung, hmm... what I said is useful in the case you have the token in the project you're CRUDing quotas ...02:02
morganfainbergif they exist02:02
dstaneksamueldmq: i don't know what their quota datastructures look like, but they could just store the calculated quota for each project02:02
samueldmqayoung, is that what you're saying all the time ?02:02
jamielennoxmorganfainberg: why would we move memcached_servers rather than jump straight to dogpile02:02
samueldmqdstanek, yeah; but enforcement on children depend on parents ;.. yyou shouldn't be able to increase you quota if it passes your parent's limit02:03
morganfainbergjamielennox: well we probably want to still support a transitional "you don't need dogpile configs"02:03
*** tobe has joined #openstack-keystone02:03
morganfainbergbut you can configure different memcache servers for ATM over sya... nova02:03
morganfainbergsince nova also uses oslo.memorycache02:03
morganfainbergoslo incubator*02:03
dstaneksamueldmq: sure, but it could still be enforce on the project level and only edited on the parent level02:03
samueldmqdstanek, but I think I got what ayoung was trying to say: 'you don't use a project scoped token to update that project's quota, for example'02:03
jamielennoxmorganfainberg: sure, but you're suggesting to add them as additional vlaues that will hopefully be deprecated soon02:03
ayoungsamueldmq, If I want to query quota, a token for that projedct should be sufficient.  But If I am setting it based on the parent project's quote, I am effectively performin an operaion on the parent, no the child.02:03
*** davechen has quit IRC02:03
samueldmqdstanek, yeah, editing will come from parents ..02:04
jamielennoxmorganfainberg: are those options locations dictated by oslo.memorycache?02:04
morganfainbergjamielennox: yes02:04
morganfainbergjamielennox: that is why02:04
jamielennoxmorganfainberg: wrong02:04
ayoungsamueldmq, we good on that?02:04
morganfainbergjamielennox: i want to do a [KATM] takes priority02:04
morganfainbergso we aren't in a weird loop getting rid of memorycache since nova also uses it.02:05
jamielennoxmorganfainberg: is oslo.memorycache the thing that gives us that in memory fallback caching mode02:05
samueldmqayoung, kind of .. I need to take a better look on the hierarchical quotas stuff, but I agree with you02:05
morganfainbergi was looking at replacing all of it02:05
samueldmqayoung, editing comes from parents ..02:05
morganfainbergand ditching the last incubator code in middleware02:05
jamielennoxmorganfainberg: so i'm fine with the idea - but honestly i'd be inclined to just deprecate it out02:05
* morganfainberg was also looking at moving to pymemcache02:05
ayoungsamueldmq, yeah, and then the child projects are just like any other resource managed by the parent;02:05
morganfainbergbecause we have issues with the pool stuff02:05
morganfainbergandpymemcahce has a built in pool and doesn't suck w/ thread.local02:06
samueldmqayoung, with tokens scoped to parents, right ?02:06
jamielennoxmorganfainberg: i have no particular love of dogpile, the one time i tried to use it i found it a bit confusing - but i really like that if we use dogpile people can do whatever they like on the backend and it's not our problem02:06
samueldmqayoung, i.e, quotas in child are managed in a higher level02:06
ayoungsamueldmq, correct.02:06
morganfainbergjamielennox: someone is working on making "oslo.cache" a thing02:06
morganfainbergbut i am not sure of the current status02:06
jamielennoxmorganfainberg: do i want oslo messing with this?02:07
ayoungNow, reading quota is a little strange, as it can either be done for "this project that I am inside of right now" or "This child project"02:07
samueldmqayoung, k, so parent_id in the token isn't required for now02:07
morganfainbergjamielennox: with what?02:07
jamielennoxmorganfainberg: what is oslo.cache going to give me that i can't just use dogpile02:07
jamielennoxis it just CONF handling?02:08
morganfainbergjamielennox: oslo.config option handling and a thin wrapper to help smooth the rough edges while we work on cleaning up the upstream02:08
jamielennox(which will hopefully be done better than oslo.memorycache)02:08
* morganfainberg has like 5 or 6 patches to push up to dogpile)02:08
morganfainbergand one just needs tests02:09
morganfainbergmy goal has been to rip out a bunch of the custom code we have in keystone02:09
morganfainbergwrapping dogpile02:09
jamielennoxmorganfainberg: ok, fair enough02:09
jamielennoxso you want to do the memorycache fix as well02:09
*** davechen2 has joined #openstack-keystone02:11
*** browne has quit IRC02:11
davechen2jamielennox: Jamie, are you still working on this patch: replace-extensions?  I saw docs still failed on that patch.02:12
jamielennoxdavechen2: oh, yea i can fix that, i forgot about that one02:13
*** davechen1 has quit IRC02:13
davechen2jamielennox: I am trying to move endpoint filter into core in another patch, and try to raise the exception if upgrade is invoked.02:14
davechen2jamielennox: Although it works for jekins, but i am not quite sure about that, so you may help to judge. :)02:14
samueldmqmorganfainberg, thanks (Adds inherited column to RoleAssignment PK)02:15
samueldmqmorganfainberg, should I propose a backport ?02:15
jamielennoxdavechen2: that's great, let me see why this is failing - ideally i just want the doc builder to ignore that file02:16
morganfainbergwe could try and do a backport02:16
morganfainbergsamueldmq: i'm not opposed to it02:16
jamielennoxit used to do that, but there was some changes as to how docs were built02:16
morganfainbergsamueldmq: but it's not a fun backport remember you need to make sure changes are idempoent and then can be reapplied, etc02:16
samueldmqmorganfainberg, should I add a point in tomorrow's meeting ? just to have an agreement ?02:16
morganfainbergsure, ask brant and dolphm as the first line of defence on stable branches02:17
openstackgerritliusheng proposed openstack/keystone: Remove the deprecated ec2 token middleware  https://review.openstack.org/18550902:17
* morganfainberg has to hop on a plane02:17
samueldmqmorganfainberg, this is very important when we have hierarchical projects02:17
davechen2jamielennox: that patch is here, I add you as the reviewer, you may help to review when you get a chance. https://review.openstack.org/#/c/186988/02:17
morganfainbergsee ya later02:17
stevemarmorganfainberg, have fun02:17
samueldmqmorganfainberg, we should consider at least backporting to K02:17
samueldmqmorganfainberg, see you02:17
stevemarmorganfainberg, did you ever send off the ppt to business folk for flair? i might send it to our folks otherwise02:17
morganfainbergstevemar: I'm going to work on it this week but hp folk are busy this week.02:18
morganfainbergFeel free to send it off. Just make sure hey know it's not just for you to present.02:18
morganfainbergI am also going to convert it to html02:19
morganfainbergSo we can publish it.02:19
* morganfainberg is working on htmlizing but hasn't gotten far.02:19
jamielennoxdavechen2: hmm, i think it will be easiest if we just raise the error if the upgrade/downgrade functions are called02:19
jamielennoxit appears we would have to name each file individually in an exclude list to get the docs to ignore them and that's a pointless list to maintain02:20
davechen2jamielennox: I did that way in that patch, but i am not quite sure, fix the jenkins so other would start to review at that patch. :)02:20
jamielennoxdavechen2: are they dependent on that patch?02:21
davechen2jamielennox: not yet, it's depends on the a different patch, just cannot figure out a way to depend on two patches.02:21
jamielennoxdavechen2: you can't :(02:21
davechen2jamielennox: cann't what? :)02:22
jamielennoxdepend on two patches02:22
*** liusheng has joined #openstack-keystone02:22
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191602:22
davechen2jamielennox: so, let's it be, and when your patch got merged, I can rebase on yours.02:23
*** davechen1 has joined #openstack-keystone02:25
*** davechen2 has quit IRC02:27
*** someara2 has joined #openstack-keystone02:29
openstackgerritJamie Lennox proposed openstack/keystone: Move endpoint_policy migrations into keystone core  https://review.openstack.org/17191602:30
*** davechen2 has joined #openstack-keystone02:31
*** davechen1 has quit IRC02:32
stevemarmorganfainberg, cool cool, i already sent them a draft, andy gave awesome feedback02:35
stevemari'll be making a second copy to tweak things a bit02:35
*** chlong has quit IRC02:39
*** davechen2 is now known as up02:41
*** browne has joined #openstack-keystone02:42
*** up has left #openstack-keystone02:43
*** davechen has joined #openstack-keystone02:44
*** richm has quit IRC02:47
*** dims___ has quit IRC02:48
*** arunkant has quit IRC02:51
*** Kennan has joined #openstack-keystone02:52
*** arunkant has joined #openstack-keystone02:55
*** someara2 has quit IRC03:09
*** someara2 has joined #openstack-keystone03:09
openstackgerritMerged openstack/keystone: Adds inherited column to RoleAssignment PK  https://review.openstack.org/14247203:12
*** someara2 has quit IRC03:13
*** samueldmq has quit IRC03:15
*** samueldmq has joined #openstack-keystone03:15
*** chlong has joined #openstack-keystone03:22
*** someara2 has joined #openstack-keystone03:27
jamielennoxholy crap, devstack v3 only completed03:44
*** dims_ has joined #openstack-keystone03:48
*** samueldmq has quit IRC03:50
*** dims_ has quit IRC03:53
*** kwills has quit IRC03:55
*** ayoung has quit IRC04:12
*** lhcheng has joined #openstack-keystone04:16
*** ChanServ sets mode: +v lhcheng04:16
*** someara2 has quit IRC04:21
*** david-lyle has quit IRC04:24
*** david-lyle has joined #openstack-keystone04:25
stevemarjamielennox, \o/04:42
jamielennoxstevemar: :)04:43
jamielennoxit doesn't mean it's all that close - just that that should be all i need from ksc and osc04:43
stevemari remember trying to make devstack v3 compliant (naively) back when i first started in grizzly04:43
jamielennoxstevemar: yea, this isn't my first attempt either04:45
*** spandhe has quit IRC04:55
*** spandhe has joined #openstack-keystone04:58
*** lhcheng_ has joined #openstack-keystone05:06
*** tobe has quit IRC05:08
*** lhcheng has quit IRC05:09
*** kiran-r has joined #openstack-keystone05:13
openstackgerritTobias Urdin proposed openstack/keystone: Fix domain id not being dict for token data  https://review.openstack.org/18745605:21
*** someara2 has joined #openstack-keystone05:22
*** triggerz has joined #openstack-keystone05:25
*** triggerz is now known as tobasco05:25
*** someara2 has quit IRC05:27
*** _cjones_ has joined #openstack-keystone05:28
*** stevemar has quit IRC05:31
*** tobe has joined #openstack-keystone05:37
*** spandhe has quit IRC06:04
*** mabrams has joined #openstack-keystone06:05
*** Kennan2 has joined #openstack-keystone06:06
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Imported Translations from Transifex  https://review.openstack.org/18627906:06
*** Kennan has quit IRC06:06
*** tobe has quit IRC06:13
*** ajayaa has joined #openstack-keystone06:23
*** henrynash has joined #openstack-keystone06:23
*** ChanServ sets mode: +v henrynash06:23
ajayaaHi. Can anyone point me to documentation where there is an example of how to create an ec2 credential for a user using v3 api.06:24
*** _cjones_ has quit IRC06:30
openstackgerritguang-yee proposed openstack/keystonemiddleware: Enforce endpoint constraint  https://review.openstack.org/17766106:37
*** dims_ has joined #openstack-keystone06:37
*** tobe has joined #openstack-keystone06:38
*** belmoreira has joined #openstack-keystone06:38
davechenajayaa: hi, I didn't notice there is any doc about that, maybe we have but I didn't read it.06:41
*** dims_ has quit IRC06:42
ajayaadavechen, Hi. The way it's done in v3 is confusing. I am not sure what to put in blob field while creating ec2 credential for a user.06:42
davechenajayaa: I think what you are looking for is some manual for ec2 credential for credential CRUD?06:42
ajayaadavechen, yes.06:42
ajayaaIf I get something done then maybe I will put a patch.06:43
ajayaaOr if you are interested, you can take it up.06:43
davechenyes, that great. Does some help manual from the openstack command help?06:43
davechenajayaa, some easy way I use when I cannot find some manual is trying to read some test code.06:44
ajayaadavechen, nope. The cli is also not helpful in this case.06:45
davechenajayaa, from those testcase, you will know what's the input and what's the expected result, this is really a workaround :)06:45
ajayaaReading a test is a good idea.06:45
ajayaaI will do that. Thanks for the idea davechen.06:45
davechenajayaa, example: blob = {"access" ..., "secret" ... }06:47
ajayaadavechen, this is what I am trying out.06:48
ajayaaBut validation fails. Now it has come down to permutations and combinations of escape characters.06:48
*** krykowski has joined #openstack-keystone06:53
davechenajayaa: me too, I am trying to have a look at this.06:54
ajayaadavechen, please let me know if you have any success.06:55
*** krykowski has quit IRC07:05
*** woodster_ has quit IRC07:10
*** jsheeren has joined #openstack-keystone07:13
*** browne has quit IRC07:22
*** lufix has joined #openstack-keystone07:22
*** lhcheng_ has quit IRC07:23
*** Kennan has joined #openstack-keystone07:39
*** Kennan2 has quit IRC07:39
*** pnavarro has joined #openstack-keystone07:46
*** dguerri`away is now known as dguerri07:48
*** jistr has joined #openstack-keystone07:48
*** chlong has quit IRC07:56
*** henrynash has quit IRC08:01
*** fhubik has joined #openstack-keystone08:14
*** fhubik is now known as fhubik_afk08:15
*** fhubik_afk is now known as fhubik08:20
*** bjornar has joined #openstack-keystone08:24
openstackgerritMarek Denis proposed openstack/python-keystoneclient-saml2: Refactor SAML2 auth plugins  https://review.openstack.org/17674608:24
davechenajayaa: still around?08:44
openstackgerritMarek Denis proposed openstack/python-keystoneclient-saml2: Refactor SAML2 auth plugins  https://review.openstack.org/17674608:44
openstackgerritMarek Denis proposed openstack/python-keystoneclient-saml2: Depend on python-keystoneauth  https://review.openstack.org/18685408:44
openstackgerritMarek Denis proposed openstack/python-keystoneclient-saml2: Standardize federated auth token scoping  https://review.openstack.org/17722708:49
ajayaadavechen, yes.08:56
*** aix has joined #openstack-keystone09:01
*** someara2 has joined #openstack-keystone09:02
davechenajayaa: I think it's field validation cause that issue.09:03
davechenajayaa: It requires bold field is a string, but we pass a dict.09:03
davechenajayaa: In the testcase, the dict is parsed to string by json.dumps()09:04
ajayaadavechen, Yes, a string needs to be passed. But I am having a hard time constructing a string of dictionary.09:04
davechenajayaa: so the testcase can pass but I didn't figure out a way how to pass a string in the curl's body.09:04
davechenajayaa: me either.09:05
ajayaadavechen, same case here. I tried to do it through postman rest client, but the error still persists.09:05
ajayaaI am having  a hard time understanding why these things were made more complicated.09:06
*** someara2 has quit IRC09:07
ajayaadavechen, it worked.09:11
ajayaaAll the double quotes inside the dict need to be escaped.09:11
davechenajayaa: cool09:11
ajayaadavechen, Does the user need to generate access and secret on his own?09:12
davechenI am still wondering whether it's wise to put a hard requirement on the blob field.09:13
ajayaadavechen, +1.09:14
davechenajayaa: maybe we can fix it. :)09:14
ajayaaIf the user asks to create ec2 credentials for him then access and secret should be generated automatically in Keystone.09:15
ajayaaNeed someone from Keystone cores to comment on this before we can fix the problem.09:15
ajayaaWe need to be sure that it indeed is a problem.09:15
ajayaamost the the Keystone cores will be here around 4 hours from now.09:16
davechenI tried the similar approach, and struggle for a long time, use double quote or single quote to escape.09:16
davechenI think I leave an extra comma there, sigh09:17
ajayaaIt's hard man! we should be glad that we figured it out eventually. :)09:18
ekarlsois keystoneauth ready to go ?09:18
*** rlt_ has joined #openstack-keystone09:18
davechenajayaa: imo, it's not flexible at least, and I really cannot understand why we need it's a string instead of handle with it in the code.09:18
davechenajayaa: yep, cheers09:19
ajayaadavechen, It's because of the database scheme. See the credential table in keystone schema.09:20
*** e0ne has joined #openstack-keystone09:20
davechenajayaa: I am off-duty now, nice to co-work with you to find a solution to make it work, and maybe we need some docs about the CLI command as well.09:21
ajayaadavechen, It was nice working with you.09:22
*** davechen is now known as davechen_afk09:24
*** dims_ has joined #openstack-keystone09:26
*** dims_ has quit IRC09:31
*** afazekas has joined #openstack-keystone09:40
*** aix has quit IRC09:45
*** aix has joined #openstack-keystone09:45
*** josecastroleon has joined #openstack-keystone09:49
*** kwills has joined #openstack-keystone09:51
*** kwills has quit IRC09:56
openstackgerritChenhong Liu proposed openstack/keystone: Replace status code 403 with ForbiddenAction.code  https://review.openstack.org/18751110:04
*** e0ne is now known as e0ne_10:13
evrardjphi everyone10:16
evrardjpfor those who aren't used to the timings of the meeting, wouldn't it be better if there is the TIME of the meeting in the topic title? With a timezone for example :p10:18
*** lufix has quit IRC10:19
openstackgerritMarek Denis proposed openstack/keystoneauth: Honour ``service_providers`` in AccessInfo  https://review.openstack.org/18751410:20
*** e0ne_ has quit IRC10:24
*** e0ne has joined #openstack-keystone10:29
*** samueldmq has joined #openstack-keystone10:31
samueldmqgood morning10:31
samueldmqoperator99, hi, I'd like to talk about 'Enforce endpoint constraint'10:31
samueldmqoperator99, let me know when you are available10:32
openstackgerritMarek Denis proposed openstack/keystoneauth: Add default domain to fixture.v3.V3FederationToken  https://review.openstack.org/18751610:35
*** dguerri is now known as dguerri`away10:37
*** fhubik is now known as fhubik_afk10:47
openstackgerritMarek Denis proposed openstack/keystone-specs: Federated domain identified by ``id`` not ``name``  https://review.openstack.org/18752010:47
openstackgerritMarek Denis proposed openstack/keystoneauth: Honour ``service_providers`` in AccessInfo  https://review.openstack.org/18751410:51
*** henrynash has joined #openstack-keystone10:53
*** ChanServ sets mode: +v henrynash10:53
*** dims_ has joined #openstack-keystone10:55
*** woodster_ has joined #openstack-keystone11:03
*** tobasco has quit IRC11:17
samueldmqhenrynash, hi11:17
*** e0ne has quit IRC11:19
ccardI'm confused about openstack regions. Horizon can be configured for multiple regions by setting AVAILABLE_REGIONS in local_settings to a list of region name -> keystone url mappings. How do these regions relate to the keystone.region table, the keystone.endpoint.region column and the region configured in e.g. neutron.conf and nova.conf?11:19
*** amakarov_away is now known as amakarov11:20
*** rushiagr_away is now known as rushiagr11:22
*** fhubik_afk is now known as fhubik11:22
bretonsamueldmq: great explanation on the ml11:23
*** e0ne has joined #openstack-keystone11:24
*** e0ne is now known as e0ne_11:25
*** triggerz has joined #openstack-keystone11:27
samueldmqbreton, thanks ... although I think our local webmail is messing up with formatting ;)11:27
*** mabrams1 has joined #openstack-keystone11:29
*** mabrams has quit IRC11:29
*** e0ne_ is now known as e0ne11:30
samueldmqhenrynash, fyi, 'Adds inherited column to RoleAssignment PK' merged :)11:41
henrynashsamuekdmq: sounds good…sorry burried under deadlines right now...11:42
samueldmqhenrynash, completely understandable, have a good day :)11:43
*** kwills has joined #openstack-keystone11:52
*** henrynash has quit IRC11:54
rushiagrmorganfainberg: hi11:55
rushiagrmorganfainberg: I was going through the stable driver interfaces blueprint (https://review.openstack.org/#/c/177428/7/specs/backlog/stable-driver-interfaces.rst), and have some questions11:55
rushiagrmorganfainberg: which is a good place to discuss them? here on IRC, or on that gerrit patch? The patch is merged, so wasn't so sure about the latter option11:56
*** e0ne is now known as e0ne_12:04
*** tobe has quit IRC12:07
samueldmqrushiagr, hi12:09
samueldmqrushiagr, I think in this channel is fine, although morganfainberg probably is not available right now ;)12:09
*** e0ne_ has quit IRC12:14
*** mabrams1 has quit IRC12:14
*** jsheeren has quit IRC12:15
*** mabrams has joined #openstack-keystone12:15
*** jistr is now known as jistr|class12:17
*** jistr|class is now known as jistr12:22
*** jsavak has joined #openstack-keystone12:24
*** breton is now known as chaosgoblin``12:25
rushiagrsamueldmq: ok, thanks12:28
samueldmqrushiagr, np :)12:28
rushiagrmorganfainberg: this is what I was writing as a comment on the spec gerrit submision:12:28
rushiagrDoes this mean there will be a version bump for every change a developer proposes and manages to get it merged? Or there will be a version per release (e.g. 11 for kilo, 12 for liberty, and so on)? In the earlier case, how are we going to keep track of the changes which belong to a particular release (e.g. how to say that versions 7,8,9 landed in Kilo, and 10,11 landed in Liberty, etc)? Point versions, like 10.1, 10.2,12:28
rushiagr etc?12:28
rushiagr(regarding the versioning aspect)12:29
*** ajayaa has quit IRC12:29
*** fhubik is now known as fhubik_afk12:34
*** e0ne has joined #openstack-keystone12:36
*** fhubik_afk is now known as fhubik12:36
*** chaosgoblin`` is now known as breton12:39
*** someara2 has joined #openstack-keystone12:41
*** someara2 has quit IRC12:45
*** iurygregory has quit IRC12:59
*** dsirrine has joined #openstack-keystone13:00
*** kiran-r has quit IRC13:09
*** emagana has joined #openstack-keystone13:09
*** emagana has quit IRC13:12
*** emagana has joined #openstack-keystone13:12
*** Ephur has joined #openstack-keystone13:13
*** emagana has quit IRC13:16
*** Ephur has quit IRC13:19
*** bknudson has joined #openstack-keystone13:20
*** ChanServ sets mode: +v bknudson13:20
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements  https://review.openstack.org/18693213:22
*** Ephur has joined #openstack-keystone13:23
*** richm has joined #openstack-keystone13:23
*** bdossant has joined #openstack-keystone13:27
*** fhubik is now known as fhubik_afk13:27
*** radez_g0n3 is now known as radez13:28
*** nkinder__ has quit IRC13:30
*** dguerri`away is now known as dguerri13:31
*** ajayaa has joined #openstack-keystone13:39
*** ErickHeinrich has joined #openstack-keystone13:41
*** ErickHeinrich has quit IRC13:41
*** rushiagr is now known as rushiagr_away13:41
*** ayoung has joined #openstack-keystone13:45
*** ChanServ sets mode: +v ayoung13:45
*** HT_sergio has joined #openstack-keystone13:46
samueldmqayoung, hi13:47
dstanekrushiagr_away: morganfainberg is PST and is probably sleeping13:47
samueldmqayoung, look at https://bugs.launchpad.net/designate/+bug/145894513:47
openstackLaunchpad bug 1458945 in murano "Use graduated oslo.policy instead of oslo-incubator code" [High,Confirmed] - Assigned to Ekaterina Chernova (efedorova)13:47
samueldmqayoung, I got people from other projects to confirm/work/invalidate that bug13:48
dstanekrushiagr_away: we can't logically do new versions for each change. that would mean we have to maintain maybe dozens of each backends at a time.13:48
samueldmqayoung, I re-added some project which were previously marked as 'no longer affects' to then mark them as invalid13:48
samueldmqayoung, so we could keep track of all them in that table13:49
samueldmqayoung, but once re-added, I am not able to invalidate them .. it says permission denied13:49
samueldmqayoung, the projects are swift ironic heat sahara manila designate13:49
*** dims_ has quit IRC13:51
*** dims_ has joined #openstack-keystone13:51
*** bdossant_ has joined #openstack-keystone13:59
*** bdossant_ has quit IRC13:59
*** csoukup has joined #openstack-keystone14:00
*** fhubik_afk is now known as fhubik14:01
*** bdossant has quit IRC14:01
openstackgerritDivya K Konoor proposed openstack/pycadf: Add api_audit_map.conf for Ceilometer project  https://review.openstack.org/18759314:02
*** bdossant has joined #openstack-keystone14:04
*** gokrokve has joined #openstack-keystone14:09
*** sigmavirus24_awa is now known as sigmavirus2414:10
ayoungsamueldmq, hey14:11
ayoungsamueldmq, I saw a bunch of that activity.  Nice14:11
ayoungsamueldmq, I think I want to work on the "fetch policy by URL" piece myself14:12
ayoungI need somethig early on the stack code wisse to work on, or I'm a go nutz14:12
*** jistr is now known as jistr|mtg14:16
*** boris-42 has quit IRC14:18
*** ajayaa has quit IRC14:21
*** stevemar has joined #openstack-keystone14:23
*** ChanServ sets mode: +v stevemar14:23
*** timcline has joined #openstack-keystone14:23
*** radez is now known as radez_g0n314:23
rodrigodsmarekd, there?14:23
*** nkinder__ has joined #openstack-keystone14:26
*** radez_g0n3 is now known as radez14:26
marekdrodrigods: ^^14:29
rodrigodsmarekd, so you are against the k2k auth plugin? how we could implement it in keystoneauth and Horizon use it?14:29
marekdrodrigods: my understanding is all auth plugins will be by default in keystoneauth14:29
marekdmorganfainberg: am i right? ^^14:30
*** emagana has joined #openstack-keystone14:30
*** jistr|mtg is now known as jistr14:30
rodrigodsmarekd, hmm didn't know about that...14:30
morganfainbergmarekd: split out like we have now for saml2 etc.14:31
marekdmorganfainberg: hm? you want to split k2k and ksa?14:31
morganfainbergIf they have dependencies that are more than basic Python.14:31
marekdmorganfainberg: they don't14:31
morganfainbergThen it'd be in ksa unless jamielennox really feels strongly it shouldn't be.14:32
marekdmorganfainberg: i wanted to confirm, that any auth plugins (Esp new) should be developed now under ksa umbrella, not ksc.14:32
marekdmorganfainberg: ok, thanks.14:32
openstackgerritMarek Denis proposed openstack/keystoneauth: Add protocol docstring in FederationBaseAuthPlugin  https://review.openstack.org/18761014:33
rodrigodsmarekd, morganfainberg thanks, will submit to ksa14:35
dstanekis mercador fulfilling the usecase that the BU guys were describing at the summit?14:41
marekddstanek: is there any detailed description of mercador capabilities and functions?14:41
dstanekmarekd: just the -dev list post that just came through14:42
marekddstanek: the one long time ago before summit ?14:42
marekddstanek: oh, my email just got synced and I can see it now14:43
henrique_ayoung, morganfainberg (and anyone interested in reseller), I've just sent an email to openstack-dev regarding the project scoped token by name stuff we discussed in vancouver14:47
henrique_you may want to take a look at it, and we can discuss it in today's meeting if we have room for it14:47
*** henrique_ has quit IRC14:48
*** htruta has joined #openstack-keystone14:48
htrutabtw, henrique_ was me14:49
dstanekhttps://review.openstack.org/#/c/183698/ - strange new HTTP 5XX rules14:49
*** radez is now known as radez_g0n314:54
*** hemnafk is now known as hemna15:02
*** mabrams has quit IRC15:03
openstackgerritBrant Knudson proposed openstack/keystone: Remove deprecated external authentication plugins  https://review.openstack.org/12570115:05
rodrigodsmarekd, stevemar, "Shall we pull Federation Mapping Engine out of Keystone and make it separate library?" yeeeeees15:07
marekdrodrigods: :)15:08
stevemarrodrigods, marek and i want it out. i don't think anyone else does :(15:08
marekdrodrigods: we will get there...one day.15:08
*** e0ne is now known as e0ne_15:09
rodrigodsmarekd, stevemar I want it.15:09
*** e0ne_ is now known as e0ne15:09
stevemarthat makes 3 of us then15:10
marekdvs rest of the world15:10
*** zzzeek has joined #openstack-keystone15:10
*** samueldmq_ has joined #openstack-keystone15:10
marekdrodrigods: well, ok if it doesn't happen I am not going to despair.15:11
dstanekrodrigods: will only keystone use it?15:11
*** samueldmq_ is now known as samuel-dmq15:11
samuel-dmqjamielennox, hi, I just saw a message here saying15:11
samuel-dmq<jamielennox> holy crap, devstack v3 only completed15:11
samuel-dmqjamielennox, did I misread something?15:11
rodrigodsdstanek, good point :)15:12
stevemardstanek, yes, but it's handy for admins creating a mapping to validate15:13
rodrigodsstevemar, ++15:13
marekd...and not having to install whole keystone locally to try that out15:13
dstanekwhy don't we provide an api then: openstackclient validate-federation-mapping something.json15:14
marekddstanek: we cannot validate mapping rules as of today.15:15
dstanekthen how does a separate package help you?15:15
marekddstanek: well, let's start the cli tool would be a local mapping rules tester  - here is my ruleset, here is my parsed assertion (key values for instance) and as an output you see users' credentials based on the rules - user_id, groups (ids).15:17
marekddstanek: if we make this tool part of keystone, you will need to install heavy keystone (with all the deps) just to test that out on you local laptop.15:17
rodrigodswe can even add tools to help building rules15:18
marekddstanek: with a pulled out library and wraper that'd be much lighter.15:18
marekddstanek: that's my only argument, and hence i am saying im in favor of this, however i see your point and i will not push for separating the code extremly hard.15:19
dstanekrodrigods: start building the tools and then if it looks independently useful you have a better case15:19
dstanekmarekd: so the real difference would be in the amount of deps your new package has right?15:20
marekddstanek: yes.15:21
marekddstanek: i think we will get there (separate lib) either way, maybe we just need to wait a little bit. I understand it.15:23
bknudsonkeystone unit tests are failing due to stuff in oslo being deprecated... I'll post a patch to disable the check for now15:33
morganfainbergbknudson: oooh doh!15:35
*** samuel-dmq has quit IRC15:36
openstackgerritBrant Knudson proposed openstack/keystone: Remove deprecation check in tests  https://review.openstack.org/18763915:36
openstackgerritBrant Knudson proposed openstack/keystone: Revert "Remove deprecation check in tests"  https://review.openstack.org/18764015:36
*** boris-42 has joined #openstack-keystone15:37
*** bdossant has quit IRC15:39
*** openstackgerrit has quit IRC15:42
*** fhubik is now known as fhubik_afk15:43
*** openstackgerrit has joined #openstack-keystone15:43
*** topol has joined #openstack-keystone15:44
*** ChanServ sets mode: +v topol15:44
*** SaintAardvark has joined #openstack-keystone15:46
*** bdossant has joined #openstack-keystone15:51
*** _cjones_ has joined #openstack-keystone15:51
*** someara2 has joined #openstack-keystone15:52
*** fhubik_afk is now known as fhubik15:59
*** jistr has quit IRC16:05
*** browne has joined #openstack-keystone16:10
*** gyee has joined #openstack-keystone16:10
*** ChanServ sets mode: +v gyee16:10
*** belmoreira has quit IRC16:12
*** gokrokve_ has joined #openstack-keystone16:14
*** bdossant has quit IRC16:15
*** gokrokve has quit IRC16:17
openstackgerritChenhong Liu proposed openstack/keystone: Replace status code 403 with ForbiddenAction.code  https://review.openstack.org/18751116:22
*** mattfarina has joined #openstack-keystone16:22
samueldmqayoung, hi, - you around ? saw your message but was afk16:25
*** e0ne has quit IRC16:29
*** liusheng has quit IRC16:33
*** liusheng has joined #openstack-keystone16:33
*** fhubik has quit IRC16:34
*** lhcheng has joined #openstack-keystone16:39
*** ChanServ sets mode: +v lhcheng16:39
*** gokrokve_ has quit IRC16:43
*** gokrokve has joined #openstack-keystone16:43
*** gokrokve has quit IRC16:45
*** gokrokve_ has joined #openstack-keystone16:45
*** lufix has joined #openstack-keystone16:46
*** iurygregory has joined #openstack-keystone16:50
ayoungsamueldmq, yep16:53
ayoungsamueldmq, you have not started actively coding the "fetch policy by url" feature, right?16:54
samueldmqayoung, actually I am available from today to start the fetch policy in ksmiddleware16:54
samueldmqayoung, I just made the changes in keystone server so far .. (updating them this afternoon)16:54
ayoungsamueldmq, so started the work already?  Cool16:55
ayoungsamueldmq, fetch by URL?16:55
*** lufix has quit IRC16:55
samueldmqayoung, I started just the keystone filter ... by endpoint_url16:55
samueldmqayoung, you already know that16:55
samueldmqayoung, the fetch part I am starting later today (if you don't grab it)16:56
ayoungsamueldmq, wasn't sure if you had started coding.  good to know16:56
samueldmqayoung, nice16:56
ayoungbetter for you to implement...I'm just needing a coding task to keep from going crazy with all these specs16:56
samueldmqayoung, GET /policies?endpoin_url=<url>16:56
*** emagana has quit IRC16:57
*** emagana has joined #openstack-keystone16:59
*** dguerri is now known as dguerri`away17:04
*** alanf-mc has joined #openstack-keystone17:10
*** spandhe has joined #openstack-keystone17:11
*** samleon has joined #openstack-keystone17:14
samueldmqayoung, http://lists.openstack.org/pipermail/openstack-dev/2015-June/065496.html17:17
*** rushiagr_away is now known as rushiagr17:17
ayoungsamueldmq, yes, I talked with them about it at the summit.  I don't like that.17:18
ayoungsamueldmq, I was, however, thinking something like this:17:19
samueldmqayoung, we need to converge to a solution17:19
samueldmqayoung, they said me that had talked to jamielennox (possibly morganfainberg as well)17:19
rushiagrdstanek: (regarding a new version for each change) that makes sense: too much of an overhead17:19
gyeeayoung, samueldmq, that proposal won't work17:19
samueldmqayoung, we need to agree with people from other projects, then we have no problems with adoption17:19
samueldmqgyee, so then let's convince them17:19
dstanekrushiagr: i don't know if morganfainberg was explicit in there, but i always thought of a version as corresponding to a release17:20
ayoungsamueldmq, lets try to loop them in to the dynamic policy discussions.  I realize I want to do something....similar to what they suggest, but different17:20
samueldmqgyee, let's have a clean table from the start, and we will be good when adopting17:20
gyeetell horizon to parse Nova source code in order to setup a intuitive UI is going to be *fun* :)17:20
ayoungok...lets stake a  standard, tricky rule...17:20
ayounglet me see...17:20
samueldmqayoung, what if we have a separate meeting for dynamic policy stuff17:20
morganfainbergdstanek: hmm?17:20
* morganfainberg reads backscroll.17:20
ayoungsamueldmq, Maybe.  discussing that is in the agenda for today's keystone meeting17:21
samueldmqgyee, ++ good point17:21
david8huI read about that proposal, too.  I don't like how policy is hardcoded, but I do like a way for audit trail.17:21
ayoungsamueldmq, I think I want to split up policy like this:17:21
gyeetell our security auditors to read the code to find out who can do what is even more fun17:21
ayounglet me link to the cloud sample...17:21
dstanekmorganfainberg: https://review.openstack.org/#/c/177428/7/specs/backlog/stable-driver-interfaces.rst17:21
samueldmqgyee, please reply that email, let's converge in the idea17:21
samueldmqgyee, I like your arguments :)17:21
*** henrynash has joined #openstack-keystone17:22
*** ChanServ sets mode: +v henrynash17:22
ayoungOK,  so my guidance was to split the "find the project_id" from the "assign this role"17:22
ayoungso, that line is kindof in that form:17:22
morganfainbergdstanek: the idea is there should *not* be many reasons to break the driver contract.17:22
ayoungsio I don't want tules like this rule:admin_and_matching_target_project_domain_id  would be17:22
morganfainbergIf you are breaking that contract it is a change. Release or not.17:22
ayoungbetter as17:22
gyeesamueldmq, on yeah, let me read the Nova code to find out how to create a trust :)17:22
morganfainbergSome deployers chase master. You would need a new driver interface contract and still need to support the old contract if you are making a change17:23
morganfainbergrushiagr: ^cc17:23
dstanekmorganfainberg: and breaking means remove, rename or update datatype right?17:23
ayoung "identity:get_project":   "domain_id:%(project.domain_id)s  and rule_get_project_role",17:23
ayoungsamueldmq, and then  rule_get_project_role  would specify what role you need for that API17:23
morganfainbergdstanek: change to method signature, new data type, adding/removing methods etx17:23
ayoungits really verbose, but we could split it into two files17:23
*** rlt_ has quit IRC17:23
david8huayoung, gyee, samueldmq, The proposal will make it harder for me to come up with a programatic way to dump all capabilities assocaited with a token or user.17:23
*** henrynash has quit IRC17:23
morganfainbergdstanek: assume the driver is loaded from out of tree17:24
ayoungone which is never touched, and just matches the domain_id, the other which assigns roles17:24
gyeedavid8hu, can't you write a script to scan the source code? :)17:24
ayoungdavid8hu, the "in the code" proposal?"  yeah17:24
morganfainbergIf we adhere to our contract the driver should keep working. Even if we layer more business logic on top of it.17:24
ayoungdavid8hu, we'll work with sdague to make sure the approach is sane for all the requirements17:25
gyeedavid8hu, with AI on top17:25
ayoungdavid8hu, are you still looking at "clean up the token pipeline?"17:25
david8hugyee, ayoung, Maybe elastic search will help .  LOL17:25
*** nkinder_ has joined #openstack-keystone17:25
samueldmqayoung, david8hu ++17:26
david8huayoung, yes, I am.  Is accessinfo still alive?17:26
samueldmqayoung, I am not sure about different files .. we should go away from files, not create more of them :p17:26
ayoungdavid8hu, alive and kicking...question is whether I need to add ServiceProviders before you can use it?17:26
samueldmqayoung, but I agree with the idea17:26
ayoungdavid8hu, the name of the review has changed...I'll link17:27
david8huayoung, ServiceProviders?17:27
rushiagrmorganfainberg: getting that.. But I'm still not clear what's decided on how to manage changes.. I think the layer on top of the driver will still need to know what version the db driver is exposing currently, so that that layer can decide which path to take depending upon that version number17:28
rushiagrmorganfainberg: am I missing that discussion, or we are yet to reach a consensus on that discussion?17:28
david8huayoung, It is on my todo list.  I will take a look, and provide feedback.17:28
morganfainbergrushiagr: correct. Think of this like how neutron and ironic handle the vendor drivers.17:29
*** nkinder__ has quit IRC17:29
ayoungdavid8hu, I'm going to add service providers.  I'll need some new sample data for that, and it will motivate me to integrate the test fixtures with the rest of the server code17:29
morganfainbergThey do not break the contract. And yes it limits what can be done. This spec just says that *if* we need to break the contract - we need to have logic to know how to work with the old interface as well17:30
morganfainbergI don't know if ironic or neutron specifically outline how to change the driver interface contracts. This is the definition we are putting forward for future cases.17:30
morganfainbergrushiagr: so yes, we need to know the version of the driver interface being used.17:30
david8huayoung, the patch has over 1000 LOC already :)  Are you trying break a record or something.17:31
*** ksavich has joined #openstack-keystone17:31
ayoungdavid8hu, mostly testing17:31
morganfainbergAnd yes we will need to at least translate those results. (Should be a known)17:31
*** nkinder_ has quit IRC17:31
ayoungdavid8hu, there are some sampledata tokens in there copied over from KC.17:31
*** e0ne has joined #openstack-keystone17:32
ayoungdavid8hu, I will probably be dropping the LOC count when I do ServiceProviders by using existing fictures.  rodrigods do we have sample JSON fixtures I can use for ServiceProvider testing in https://review.openstack.org/#/c/184651/  ?17:32
david8huayoung, I found those fixtures very useful for token formatter as well.  I basically use them for free.  Go ahead an incorporate them.17:32
*** emagana has quit IRC17:32
ayoungdavid8hu, We have had several iterations of the token fixtures over time.  I'd probably be negligent if I just blindly copied them without good reason.  I had good reason before, but less so now17:33
lbragstadwe have quite a few new bugs this week17:36
*** josecastroleon has quit IRC17:39
ayoung$ openstack server list17:42
ayoungERROR: openstackclient.shell Exception raised: (python-neutronclient 2.3.9 (/usr/lib/python2.7/site-packages), Requirement.parse('python-neutronclient<3,>=2.3.11'))17:42
*** nkinder_ has joined #openstack-keystone17:43
stevemarayoung, $ pip install --update python-neutronclient17:44
ayoungstevemar, biter your tongue17:44
ayoungstevemar, I'm trying to make this work using RPMS17:44
stevemarpfft, on your own on that front17:44
david8huayoung,  There is a RPM for that.17:44
ayoungif I keep doing pip...I never find out how our packages are all kinds of outofsync17:45
ayoungdavid8hu, where?17:45
david8huayoung, dont know ;)17:45
ayoungdavid8hu, I tried using the RDO repo...but maybe I have a copr enabled that got me too late an openstacklclient17:45
ayoung python-openstackclient      noarch   1.0.3-2.fc23      openstack-kilo   but  python-neutronclient        noarch   2.3.9-1.fc22      fedora17:46
ayoungdavid8hu, that looks wrong17:46
david8huayoung, perhaps time to migrate to pip install like stevemar suggested or try rpmfind.net17:49
ayoungdavid8hu, going to try the rdo-testing repo...but shipping a working version of the CLI should be baseline. I'm still kindof mad it wasn't wokring in Fedora22 right from install17:49
ayoungdavid8hu, nah, it is in here https://repos.fedorapeople.org/repos/openstack/openstack-kilo/testing/f22/  just not in "released"17:50
david8huayoung, Do you run devstack at all?17:50
ayoungdavid8hu, only in a VM17:50
david8huayoung, i see.17:50
ayoungdavid8hu, It made a mess of my workstation,  replacing core site-packages with the upstream versions...which then broken when the time came to update the install17:51
ayoungI pip install rpdb and tox, and things like that, but that is about it17:51
david8huayoung, a lot of fun17:51
ayoungand we still ship a version of python-neutronclient that does not match what openstackclient needs17:51
ayoungpython-neutronclient.noarch 2.3.11-1.fc23   should be good.  WTF?17:52
morganfainbergalmost that time....17:52
*** e0ne is now known as e0ne_17:52
*** someara2 has quit IRC17:54
*** someara2 has joined #openstack-keystone17:54
*** someara2 has quit IRC17:57
*** someara2 has joined #openstack-keystone17:57
*** e0ne_ is now known as e0ne17:57
*** aix has quit IRC17:57
rushiagrmorganfainberg: okay. That makes things clearer.. I still get a feeling that not all details have been either 1. documented or 2. not completely decided/thought throuogh/agreed upon17:57
morganfainbergrushiagr: the spec covers a lot of things but specs are not set in stone and can always be improved17:58
morganfainbergthe other side is they are really about a direction.17:58
*** henrynash has joined #openstack-keystone17:58
*** ChanServ sets mode: +v henrynash17:58
rushiagrmorganfainberg: hmm..17:58
rushiagrmorganfainberg: I'll spend some more time on this, maybe tomorrow. Sleeping time here..17:58
morganfainbergthings invariably change a little as implementation occurs17:58
morganfainbergrushiagr: sleep well!17:58
rushiagrmorganfainberg: true. Thanks :)17:59
marekdgyee: https://review.openstack.org/#/c/187514/ please revisit, left a comment for ya18:00
gyeemarekd, k, lemme 2x check on that decorator18:01
openstackgerritFernando Diaz proposed openstack/python-keystoneclient: Add openid connect client support  https://review.openstack.org/13470018:01
*** radez_g0n3 is now known as radez18:02
*** edmondsw has joined #openstack-keystone18:02
*** ayoung is now known as ayoung_Eeyeore18:02
*** ayoung_Eeyeore is now known as ayoung18:02
morganfainbergjamielennox: ping meeting18:03
*** someara2 has quit IRC18:06
*** samleon has quit IRC18:06
ayoungdstanek, >>> print keystoneclient.__file__18:08
ayoungdstanek, how do I undo that?18:08
ayoungie...use the fiels in /usr/lib/python27/site-packages?18:09
*** openstackgerrit has quit IRC18:09
*** openstackgerrit has joined #openstack-keystone18:10
*** dguerri`away is now known as dguerri18:11
*** someara2 has joined #openstack-keystone18:19
dstanekayoung: set the correct path in your PYTHONPATH or in python set sys.path18:19
ayoungdstanek, it was easyintall...I got it18:22
ayoung.pth file somewhere18:22
*** gokrokve_ has quit IRC18:23
*** HT_sergio has quit IRC18:30
*** someara2 has left #openstack-keystone18:37
*** blewis has joined #openstack-keystone18:41
*** erhudy has quit IRC18:42
*** gokrokve has joined #openstack-keystone18:42
openstackgerritMarek Denis proposed openstack/keystoneauth: Add default domain to fixture.v3.V3FederationToken  https://review.openstack.org/18751618:42
marekdgyee: ^^18:43
gyeemarekd, looks good! waiting for Jenkins, don't want topol to call me Mr. Speedy18:44
*** gokrokve has quit IRC18:44
* topol its a term of endearment18:44
*** gokrokve has joined #openstack-keystone18:44
marekdgyee: sure18:44
*** kiran-r has joined #openstack-keystone18:50
*** openstackgerrit has quit IRC18:56
*** openstackgerrit has joined #openstack-keystone18:56
*** Chenhong has joined #openstack-keystone18:59
*** henrynash has quit IRC19:00
*** Chenhong has quit IRC19:00
*** rushiagr is now known as rushiagr_away19:01
marekddstanek: keysone-mapper would simply depend on jsonschema and maybe something small vs whole keystone.19:01
morganfainbergmy evaluation on splitting mapping out is strictly "who would use this besides us"19:01
morganfainbergthats really all i'm looking at for managing the overhead of splitting it out19:01
marekdmorganfainberg: i see19:01
marekdmorganfainberg: ok, so not let's split it for now.19:01
morganfainberg(considering we're going to be looking at merging some plugin things back in now that pbr is smarter [yay!])19:02
bknudsonanother reason to split it out is you can have a different core group19:02
morganfainbergbknudson: do we have enough people legitimately interested in just that small bit of code to justify a core group19:02
morganfainbergif so, willing to support a split (and fair point)19:02
marekdmorganfainberg: ok, let's not split it for now.19:02
bknudsonI don't know what the plans are for the project19:02
*** geoffarnold_ has joined #openstack-keystone19:03
dstanekbknudson: project/module :-)19:03
morganfainbergbknudson: my general feeling is not split - and if we get a solid case to split we can.19:03
marekdbknudson: this cycle i think we will leave it as is.19:03
morganfainbergand iirc we can do sub-tree cores in gerrit.19:03
marekdbknudson: later i have some ideas.19:03
morganfainbergbut i'd have to ask some -infra folks how / if that'd work19:03
marekdmorganfainberg: there is no need for it IMHO19:03
morganfainbergannnnd henrynash is gone19:03
*** HT_sergio has joined #openstack-keystone19:03
bknudsonthe unit tests would be a lot faster if it was just mapping and not all keystone19:03
marekdmorganfainberg: ok, tomorrow i will propose cli under keystone umbrella19:04
gyeemarekd, have you think about how to manage mapping from UI?19:05
gyeelike how to render a map in UI?19:05
stevemargyee, as a json blob :P19:06
*** Rockyg has joined #openstack-keystone19:06
gyeestevemar, that's not UI19:06
stevemarwe have have APIs to support adding a single rule or AND'ing a rule19:07
gyeestevemar, yeah, to be properly authorize on the mapping, I think we'll need to decompose it the same way we decompose policies19:08
*** HT_sergio has quit IRC19:08
gyeeif you think about it, a map is a lot like an API, data coming in and data coming out19:09
gyeehow do we authorize what data it can produce?19:10
marekdgyee: i imagine this as # keystone-mapper --mapping-rules <json with mapping> --input <kwy value stores, something like parsed credentials injected in the RuleProcessor>19:10
marekdgyee: no API, it's just string processing19:10
marekdgyee: KISS rule19:11
* marekd needs to step out for a while19:13
*** davechen has joined #openstack-keystone19:14
ayoungmorganfainberg, mapping should be callable inside the endpoints.  You could avoid having to go back to Keystone except to fetch role assignments19:15
ayoungtokenless everywhere19:15
morganfainbergayoung: would break a lot of places. nova -> galnce19:15
openstackgerritMerged openstack/keystoneauth: Honour ``service_providers`` in AccessInfo  https://review.openstack.org/18751419:16
*** tellesnobrega_ has joined #openstack-keystone19:16
gyeeayoung, that's why I suggest melting mapping with oslo.policy19:16
*** iamjarvo has joined #openstack-keystone19:19
*** belmoreira has joined #openstack-keystone19:20
*** gyee has quit IRC19:21
samueldmqayoung, couldn't the policy endpoint binding be enforced somehow using the endpoint_url we will be defining for the policy fetch thing ?19:24
samueldmqayoung, I mean the token endpoint binding19:25
ayoungmorganfainberg, not if glance implements as well, and Nova was implicitly trusted19:26
*** fangzhou has joined #openstack-keystone19:26
ayoungsamueldmq, yes it can19:26
morganfainbergayoung: "implicit" trust is not something we do well in OpenStack at the moment. there is a lot of change needed for that to be a reality19:26
ayoungmorganfainberg, or done with a delegation_id, but this is all in the realm of the possible.  But it means we need to check mapping outside of Keystone itself19:27
samueldmqayoung, great, so we should re-use that endpoint_url (will be in the keystoneauth_token session of services' configs19:27
samueldmqayoung, instead of defining a hardcoded endpointid in the policy19:28
samueldmqayoung, agreed ?19:28
morganfainbergayoung: i think we need to have the policy work before we discuss merging mapping in.19:28
*** HT_sergio has joined #openstack-keystone19:28
ayoungsamueldmq, sort of...hold that thought19:28
*** fangzhou has quit IRC19:28
samueldmqayoung, k19:28
*** fangzhou has joined #openstack-keystone19:29
ayoungmorganfainberg, not before discussing, just before implementing. We'd need everything from Keystone to be executable in an external way, and then Keystone  becomes a respoitory consuimed by mapping and policy19:29
ayoungpolicy is the logical first step, but I think we have the broad strokes of that fleshed out19:30
morganfainbergayoung: lets not dive too deep into this right now, lets get the stuff we need this cycle outlined and build this convo on that (the specs)19:30
*** davechen has left #openstack-keystone19:31
*** miguelgrinberg has quit IRC19:31
ayoungmorganfainberg,  We need to stop focusing on "what we can get done this release" as we an't get jack done inside a single release.  These things take time, and we need to accept that. Often we find that a small change now will have to be undone later because we haven;t actually thought things through.  IN the case of this mapping thing, I actually discussed it back in The Fall.19:32
morganfainbergayoung: having a clear foundation (policy) to work from, even if it's the spec and not the implementation, will make the subsequent conversations easier19:32
ayoungmorganfainberg, having a clear vision of where we are headed will help everyone get aligned19:33
ayoungAnyway..you asked "who would ever want it" or something...that is the answer19:33
morganfainbergayoung: honestly, i think we *need* the focus on the foundation [again not the implementation] so we can build on it19:33
ayoungand then gyee disappeared19:34
*** miguelgr- has joined #openstack-keystone19:34
ayoungmorganfainberg, you know that I am working on that, too19:34
morganfainbergayoung: yep19:35
ayoungmorganfainberg, what do uyou think about Papai?  External service, or part of Keystone?19:35
ayoungpretty sure I know what you will say...19:35
* samueldmq is waiting morganfainberg view on that19:36
morganfainbergayoung: honestly, i don't know19:36
ayoungmorganfainberg, ok...let me see if I can lay out the pros and cons19:36
ayoungfirst, the cons...cuz I think they are shorter19:36
morganfainbergayoung: i can see either side. i dont have a strong feeling it needs to be one way or another19:37
ayoung1.  adds more to keystone, and we are already talking about splitting it19:37
morganfainbergand by exernal you mean "in keystone's API" or "separate process"?19:37
ayoung2.  need to port the DNF library to python2719:37
ayoung3.  It merges in code that could potentially have a life of its own.19:37
ayoungthat is the cons of it being in the same repo19:37
ayoungmorganfainberg, yeah19:37
ayoungmorganfainberg, I am not saying this clearly ...19:38
samueldmqthe API is in Keystone, the drivers (db) should be as well ... as we have been doing all the time :/19:38
ayoungsamueldmq,  so...I can see that arguement, but  there are a couple counter arguments19:39
ayoungI think the most powerful on keeping them separate  argument is actually "managing the access control to the policy API should be separate from everything else"19:39
ayoungyou don't want to screw up the policy that manages the policy server...by making changes inside the policy server19:40
samueldmqayoung, you should manage the access control via keystone, no ? update policy et c...19:40
ayoungthe biggest down side to keeping it in a separate repo is the data synchronization issue...and I think that is a solvable problem19:41
ayoungthe biggest benefit is that we can split developme of Papaisfrom the rest of Keystone, and make it move faster19:41
samueldmqayoung, should papai then own the APIs for managing the policy ?19:41
ayoungits in prototype stages now, which is good.  It means we can make major changes without too much overhead19:41
samueldmqayoung, and we deprecate keystone ones ?19:41
ayoungsamueldmq, one possibility is that Keystone owns them and proxies papai19:42
ayounganother is that, yes, papai owns them19:42
ayoungthere really are very few APIS, and those...are now Service Catalog specific19:42
ayoungget_policy_for_endpoint is the big one...that needs Keystone specific data19:42
samueldmqayoung, if it is a separate service for managing the policies, I think that is good, but only separating the database is bad imo19:43
ayoungbut, if the policy it fetches comes from Papai, and is cached in Keystone.19:43
samueldmqayoung, however we have the policy associations by endpoint, etc19:43
ayoungsamueldmq, I think we keep it as a separate service19:43
ayoungPapai might not need to know about the service catalog19:43
samueldmqayoung, so you go for keystone and ask for the association19:44
ayoungOTOH, we might want to expose *some* of the policy management APIs direct from Papai19:44
samueldmqayoung, get the policy id and fetch from papai19:44
ayoungsamueldmq, and then Papai needs to support the Keystone servers attempt to request a policy by ID...somehow19:44
ayoungwould love it if these IDs were hashses, and we could do this all Git-style19:44
samueldmqayoung, and papai have granular api's to manage the policy and we deprecate keystone ones19:45
ekarlsowhat's papai ?19:45
ayoungsamueldmq, and Papai needs to continue to support older policies, even after they are updated19:45
*** miguelgr- has quit IRC19:45
samueldmqayoung, and papai ...19:45
ayoungwe might have two endpoints,one that uses policyid 1234 ane one that uses id=abcd19:45
samueldmqayoung, :)19:45
samueldmqekarlso, policy store and management serivce, right ayoung ?19:46
*** miguelgr- has joined #openstack-keystone19:46
ayoungekarlso, PAP is short of Policy Administration Point...standard term for this kind of service.  We code named ours PAPAI due to the Brazilian influence19:46
ayoungekarlso, the same Professor that originally presented on Federation (David Chadwick) now has a graduate student writing a service for policy management.  He;'s writing it sort of OpenStack agnosically, so we need to bridge the gap between his design and what we expose19:48
*** kiran-r has quit IRC19:48
samueldmqayoung, ekarlso where Papai = Dad :)19:48
ayoungthey are supposed to get us code pretty soon19:48
*** belmoreira has quit IRC19:49
samueldmqayoung, whether go to a generic representation (what they're proposing) and write a mapper or go to a less generic approach (we define tables, etc only to fit our needs) is somthing that is still being discussed right?19:50
*** amakarov is now known as amakarov_away19:51
ayoungsamueldmq, yeah.  I'm kindof postponing that discussion til I have code I can play with19:51
samueldmqayoung, or did you buy the generic idea (the OpenStack agnosically implementation) and want that19:51
ayoungI want to see how good-bad-ugly it is19:51
samueldmqayoung, I should be able to create a poc in the simpler idea19:51
samueldmqayoung, could you point me to code where the checks (form oslo.policy) get instantiated from the policy rule string?19:51
ayoungsamueldmq, lets let them run, and focus on the other pieces need to start19:51
ayoungsamueldmq, yeah...one sec19:52
*** ksavich has quit IRC19:52
*** alanf-mc has quit IRC19:54
morganfainbergayoung: separate is fine by me. Really I don't feel strongly it has to be one way or another.19:55
*** blewis has quit IRC19:55
morganfainbergayoung: I'm more concerned with usability.19:56
ayoungmorganfainberg, would we be willing to take it under our corner of the big tent?19:56
ayoungmorganfainberg, they wrote it as a Django App. I'm assuming we would prefer Flask, right?19:56
morganfainbergSo let's see what bknudson comes up with for the "keystone" corner of the tent.19:56
samueldmqayoung, please make sure as well ioram knows we are still evaluating their proposal, which can be refused when you (the community) analyzes the code19:56
ayoungsamueldmq, its bigger than just me.  I'll be involved, but I want the whole team to take ownership of the decision.19:57
morganfainbergBut I am not opposed to it. And django / flask I prefer flask but we have prior art for using django in OpenStack.19:57
*** SaintAardvark has quit IRC19:57
samueldmqayoung, yes, that's why I said (the community) :)19:57
ayoungThis is kindof the next big think in Keystone, beyond Fedearation, and we all need to be making informed choices19:58
morganfainbergayoung: if that makes sense?19:58
samueldmqmorganfainberg, great, you agree with having both the storage + management at other service (granular update of policy rules, etc)19:58
samueldmqmorganfainberg, and then we deprecate keystone policy api's19:58
samueldmqmorganfainberg, is that what's in your mind ?19:58
ayoungmorganfainberg, yeah...it does.  Its why I specifically asked "prefer"19:58
*** spandhe has quit IRC19:59
morganfainbergayoung: no preference until we determine what the keystone corner of the tent comprises. I see benefit to both sides. I am willing to go with the one that is more usable. I am leaning towards external for more usable.19:59
ayoungsamueldmq, so the osl.policy code has its own parser:  http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/_parser.py20:00
morganfainbergLunch time. /me jumps out for a few.20:00
ayoungmorganfainberg, and if we manage it, we *prefer* flask but are willing to *accept* DJango20:00
samueldmqmorganfainberg, ++20:00
samueldmqmorganfainberg, bon apetit20:00
ayoungsamueldmq, does ^^ answer your question about oslo.policy?20:01
* ayoung has a meeting20:01
samueldmqayoung, yes, thanks20:01
samueldmqayoung, going home now, talk to you later20:01
*** ayoung is now known as ayoung-meeting20:01
*** miguelgr- is now known as miguelgrinberg20:05
*** samueldmq has quit IRC20:05
*** ayoung-meeting has quit IRC20:06
*** Raildo has joined #openstack-keystone20:08
*** openstackgerrit has quit IRC20:10
*** openstackgerrit has joined #openstack-keystone20:10
openstackgerritBrant Knudson proposed openstack/keystone: Switch from deprecated isotime  https://review.openstack.org/18775120:11
bknudson^ should fix the use of deprecated function20:12
*** iamjarvo has quit IRC20:14
*** tellesnobrega_ has quit IRC20:16
*** timcline has quit IRC20:16
*** ayoung-meeting has joined #openstack-keystone20:23
*** HT_sergio has quit IRC20:27
*** alanf-mc has joined #openstack-keystone20:29
*** timcline has joined #openstack-keystone20:30
*** topol has quit IRC20:32
*** henrynash has joined #openstack-keystone20:32
*** ChanServ sets mode: +v henrynash20:32
*** henrynash has quit IRC20:33
*** jsavak has quit IRC20:33
*** jsavak has joined #openstack-keystone20:34
Raildostevemar, ping, hey can you take a moment later to see this patch? https://review.openstack.org/#/c/123539/ :)20:35
*** Raildo_ has joined #openstack-keystone20:35
stevemarRaildo, NO!20:36
stevemaryeah sure, just give me a few minutes, helping someone else out20:36
stevemartrying to explain that v2 and v3 endpoints always exist in keystone :\20:37
*** henrynash has joined #openstack-keystone20:37
*** henrynash has quit IRC20:37
*** operator99 is now known as gyee20:39
*** Raildo has quit IRC20:39
*** spandhe has joined #openstack-keystone20:40
*** emagana has joined #openstack-keystone20:41
*** iamjarvo has joined #openstack-keystone20:42
bknudsonstevemar: you can configure the paste pipeline to remove either or both20:43
*** emagana has quit IRC20:43
bknudsonalthough keystone without either v2 or v3 is not very useful20:44
*** emagana has joined #openstack-keystone20:44
stevemarbknudson, i don't think our product teams would support that recommendation20:45
bknudsonwe have to support everything possible!20:45
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Common base class for unit tests  https://review.openstack.org/18777020:49
*** jsavak has quit IRC20:51
*** jsavak has joined #openstack-keystone20:52
*** gyee has quit IRC20:53
*** gyee has joined #openstack-keystone20:53
*** ChanServ sets mode: +v gyee20:53
*** emagana has quit IRC20:58
Raildo_stevemar, haha, thanks :D21:00
stevemarbknudson, i told them we might remove keystone CLI in L21:00
stevemarthey were surprisd21:01
*** iurygregory has quit IRC21:01
stevemarbut they sent me logs with the deprecation message everytime keystone CLI was used21:01
Raildo_stevemar, I was in a event here in Brazil and I guy told that in your company they use the Essex release...21:03
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Common base class for unit tests  https://review.openstack.org/18777021:03
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Switch from isotime  https://review.openstack.org/18777421:03
openstackgerritBrant Knudson proposed openstack/keystonemiddleware: Unit tests catch deprecated function usage  https://review.openstack.org/18777521:03
*** Raildo__ has joined #openstack-keystone21:03
stevemarRaildo_, essex is still the best release21:04
stevemar(i've never worked on essex, and that was a joke)21:04
edmondswstevemar, bknudson the work to get all the services compatible with v3 continues, right? I'm hoping it21:05
edmondswisn't too much longer before we can remove v2 from the pipeline if we want21:05
bknudsonedmondsw: samueldmq is been working on providing a gate job that disables v221:06
bknudsonif that works then it shows that all the services work with v321:06
edmondswwe know they don't today, but they should be moving that direction...21:06
gyeejust pull v2 from pipeline and see who screams, then fix them one at a time21:07
stevemaredmondsw, yeah we're close, not there yet, but close21:07
gyeeno guts, no glory21:08
*** Raildo_ has quit IRC21:08
*** pnavarro has quit IRC21:08
edmondswI ran across that a while back21:08
edmondswlooks like it has had some recent activity21:09
*** e0ne has quit IRC21:11
*** radez is now known as radez_g0n321:11
*** radez_g0n3 is now known as radez21:14
*** jsavak has quit IRC21:19
*** Raildo__ has quit IRC21:22
*** ayoung-meeting is now known as ayoung21:25
*** iamjarvo has quit IRC21:25
*** mattfarina has quit IRC21:28
jamielennoxmorganfainberg: sorry i missed the meeting, it looks like ksa was discussed a lot21:28
morganfainbergjamielennox: yep.21:28
morganfainbergjamielennox: need to talk about auth plugins.21:30
jamielennoxi'm just reading the eavesdrop now21:30
*** jaypipes has joined #openstack-keystone21:33
jaypipesmorganfainberg, dolphm: hey what happened to the regions/ resource in the Keystone v3 API? I don't see it on http://developer.openstack.org/api-ref-identity-v3.html...21:33
*** ayoung_ has joined #openstack-keystone21:34
jamielennoxbknudson: so i did: https://github.com/jamielennox/jsonhome21:35
dolphmjaypipes: i guess it's in the spec, but it's never been added to the docs? https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3.rst#regions-v3regions21:35
stevemarjaypipes, it should be there21:35
stevemardolphm, jaypipes, yeah, use keystone-specs21:35
morganfainbergjaypipes: what dolphm said.21:36
stevemarjaypipes, the one you linked is missing a good chunk of features21:36
dolphmspecs != docs # because pretty21:36
bknudsonjamielennox: neat!21:36
jamielennoxbknudson: i'm still looking at how it integrates into keystone21:36
*** ayoung_ has quit IRC21:36
jamielennoxbknudson: keystone puts all the jsonhome documents onto the router object and then compiles them all into a document only when called21:37
bknudsonjamielennox: it creates a big dict which is the JSON Home document21:37
*** ayoung has quit IRC21:38
jamielennoxbknudson: when you have a minute do you want to have a look over the APIs of the lib and i'll look at moving it into stackforge and we can start consuming it for keystone and keystoneclient21:38
jamielennoxi've tried to keep it fairly low level for now, i'm adding helpers to the object on the keystone side and we'll see if they are generally useful to move to the library21:39
bknudsonjamielennox: looks good to me.21:41
openstackgerritMerged openstack/python-keystoneclient: Add EC2 CRUD credential support to v3 API  https://review.openstack.org/18709421:41
jamielennoxit does the inherit from dict thing which i was struggling with but i think in this case it makes sense21:42
bknudsonusing uritemplate makes the replacement pretty easy21:43
jamielennoxbknudson: yea, that's a nice little library21:44
*** nkinder_ has quit IRC21:44
*** dtroyer has quit IRC21:44
bknudsonlooks like you could also use it to validate that all the variables are mentioned in the json home21:44
jamielennoxbknudson: yea, i was experimenting with ways of putting this into keystone21:45
jamielennoxand the latest one i've got a parameter repo on the Document so it always ensures that all the appropriate params are listed, and you don't always have to reference the same Paramters.domain_id or whatever it is21:46
bknudsonsadly, flask uses a different format21:46
jamielennoxwe might be able to just process that21:47
bknudsony, we could accept regular RFC paths and convert to the flask value21:47
jamielennoxi was thinking the other way as we wouldn't have the type information21:47
bknudsonI don't know if the type is all that useful for keystone21:48
bknudsoncan you have your own converters?21:48
bknudsonmaybe we could tell json-home about the type and it could put it on the flask path.21:48
jamielennoxbknudson: i started looking into flask but dstanek was looking at it as well so i've left it to him21:49
jamielennoxbut i imagine there is a way we can abstract our own decorator that handles this all magically21:49
bknudsonthat maniac was trying to get rid of the paste pipeline21:49
jamielennoxbknudson: i don't entirely disagree21:49
jamielennoxbut i was going to just strip it down for now21:50
*** ayoung has joined #openstack-keystone21:50
*** ChanServ sets mode: +v ayoung21:50
*** aix has joined #openstack-keystone21:50
jamielennoxall the extensions in paste is one of the problems i was having with pecan21:50
bknudsonwe were already planning to make extensions core21:51
*** dguerri is now known as dguerri`away21:51
jamielennoxright, so i started on that and dave chen was doing some as well21:52
bknudsonhttps://review.openstack.org/#/c/187751/ passed jenkins (fixes unit tests in keystone)21:52
jamielennoxand dstanek was looking at the whole dependency resolution thing which was another problem21:52
*** Raildo has joined #openstack-keystone21:53
*** edmondsw has quit IRC21:55
*** bknudson has quit IRC21:56
*** radez is now known as radez_g0n321:59
*** lhcheng has quit IRC22:04
*** timcline has quit IRC22:04
morganfainbergjamielennox: ok back22:06
jamielennoxmorganfainberg: i'm about to go out for 30 min or so22:07
jamielennoxbut quickly, why does relmgmt care about us doing a 1.6?22:07
*** lhcheng has joined #openstack-keystone22:08
*** ChanServ sets mode: +v lhcheng22:08
*** sigmavirus24 is now known as sigmavirus24_awa22:09
morganfainbergjamielennox: more than anything just making sure we don't have any carziness going on22:11
morganfainbergdhellmann has been releasing lots of stuff, and to ensure we're not going to cause an issue22:11
morganfainbergnot because they need to be directly involved22:11
morganfainbergjamielennox: thats all22:12
morganfainbergjamielennox: keep in mind unless the project looking to consume the new functionality of KSC has conditional logic to not break if the feature is missing, the g-r will need an update as well22:13
morganfainbergnot just a release of ksc22:13
morganfainberglhcheng: you around?22:14
lhchengmorganfainberg: o/22:14
*** dtroyer has joined #openstack-keystone22:19
*** Rockyg has quit IRC22:31
*** dims__ has joined #openstack-keystone22:31
*** dims_ has quit IRC22:34
gyeedstanek, morganfainberg, trying to understand your comments for https://review.openstack.org/#/c/180769/10/keystonemiddleware/auth_token/__init__.py22:35
gyeeis there a way to lookup the package version from the code?22:35
gyeeI am referring to "{project}/{project_version} ksv.auth_token/{ksm_version}"22:35
jamielennoxmorganfainberg: right - i was going to do an immediate bump of g-r because i need this for OSC22:38
morganfainbergjamielennox: ok22:39
morganfainberggyee: i just recommented on it22:39
morganfainberggyee: look at the standard format for user-agents22:39
*** ayoung has quit IRC22:39
morganfainberggyee: you might be able to use pbr.. but that isn't a good option.22:39
morganfainberggyee: since then it becomes a runtime requirement22:39
gyeemorganfainberg, thanks, I was looking for a way to lookup package version from the code22:39
morganfainberggyee: uhmm... not sure what to reocmmend22:40
gyeeI was tempting to do popen but then the permission gods may disagree with me22:40
morganfainberggyee: i might break your fingers for a popen :P22:41
openstackgerritAlan Pevec proposed openstack/keystone: Run WSGI with group=keystone  https://review.openstack.org/18780022:42
*** diegows has joined #openstack-keystone22:53
*** liusheng has quit IRC22:55
*** afazekas has quit IRC22:55
morganfainbergjamielennox: ok going to release KSC22:56
*** liusheng has joined #openstack-keystone22:56
*** zzzeek has quit IRC23:03
*** stevemar has quit IRC23:12
*** stevemar has joined #openstack-keystone23:12
*** ChanServ sets mode: +v stevemar23:12
*** csoukup has quit IRC23:18
*** markvoelker_ has quit IRC23:18
*** Sayaji has joined #openstack-keystone23:19
*** chlong has joined #openstack-keystone23:22
jamielennoxmorganfainberg: great! thanks for that23:33
*** lhcheng has quit IRC23:35
*** markvoelker has joined #openstack-keystone23:40
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Base use webob  https://review.openstack.org/17420023:43
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Don't rely on token_info for header building  https://review.openstack.org/17419923:43
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Move project included validation  https://review.openstack.org/17419823:43
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Depend on keystoneclient for expiration checking  https://review.openstack.org/17419723:43
openstackgerritJamie Lennox proposed openstack/keystonemiddleware: Don't store expire into memcache  https://review.openstack.org/17419623:43
*** bradjones has quit IRC23:43
*** bradjones has joined #openstack-keystone23:45
*** diegows has quit IRC23:56
*** browne has quit IRC23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!