Wednesday, 2016-01-20

*** shoutm has joined #openstack-keystone00:01
openstackgerrithenry-nash proposed openstack/keystone-specs: Add filter to control listing projects acting as domains  https://review.openstack.org/26942200:06
*** topol has quit IRC00:07
*** doug-fish has joined #openstack-keystone00:09
*** topol_ has joined #openstack-keystone00:09
*** shoutm_ has joined #openstack-keystone00:11
* jamielennox still thinks implied roles should just have been part of roles 00:13
*** doug-fish has quit IRC00:14
*** markvoelker has quit IRC00:14
*** shoutm has quit IRC00:14
*** markvoelker has joined #openstack-keystone00:17
*** shoutm_ has quit IRC00:19
*** diazjf has joined #openstack-keystone00:20
openstackgerritJorge Munoz proposed openstack/keystone: Fix trust redelegation and associated test  https://review.openstack.org/26982400:20
*** spzala has quit IRC00:21
*** spzala has joined #openstack-keystone00:22
*** spzala_ has joined #openstack-keystone00:24
*** spzala has quit IRC00:26
*** shoutm has joined #openstack-keystone00:26
openstackgerrithenry-nash proposed openstack/keystone: Alloe project domain_id to be nullable at the manager level  https://review.openstack.org/26453300:28
*** spzala_ has quit IRC00:28
openstackgerritMerged openstack/keystone: Implied roles driver and manager  https://review.openstack.org/26426000:58
openstackgerritOpenStack Proposal Bot proposed openstack/keystone: Updating sample configuration file  https://review.openstack.org/26947901:03
*** vivekd has joined #openstack-keystone01:09
*** henrynash has quit IRC01:11
*** EinstCrazy has joined #openstack-keystone01:17
*** gonzalo2kx has quit IRC01:19
*** su_zhang has quit IRC01:24
*** harlowja has quit IRC01:30
*** spzala has joined #openstack-keystone01:30
*** harlowja has joined #openstack-keystone01:30
*** david-lyle has quit IRC01:31
*** spzala has quit IRC01:34
*** browne has joined #openstack-keystone01:36
*** jasonsb has joined #openstack-keystone01:38
*** bill_az has quit IRC01:41
*** EinstCrazy has quit IRC01:41
*** EinstCrazy has joined #openstack-keystone01:50
*** EinstCrazy has quit IRC01:55
*** EinstCrazy has joined #openstack-keystone01:55
*** davechen has joined #openstack-keystone01:58
*** EinstCra_ has joined #openstack-keystone02:00
*** EinstCrazy has quit IRC02:03
openstackgerritMerged openstack/python-keystoneclient: Merge pep8 and bandit into linters  https://review.openstack.org/26926802:03
*** gonzalo2kx has joined #openstack-keystone02:05
*** davechen1 has joined #openstack-keystone02:06
*** davechen has quit IRC02:09
stevemartime to rebase all the things :(02:16
*** _cjones_ has quit IRC02:18
*** spzala has joined #openstack-keystone02:19
openstackgerritSteve Martinelli proposed openstack/keystone: Remove LDAP Resource and LDAP Assignment backends  https://review.openstack.org/23187202:21
*** spandhe has quit IRC02:28
openstackgerritSteve Martinelli proposed openstack/keystone: Remove LDAP Role Backend  https://review.openstack.org/26938502:28
openstackgerritSteve Martinelli proposed openstack/keystone: Remove LDAP Resource and LDAP Assignment backends  https://review.openstack.org/23187202:28
openstackgerritSteve Martinelli proposed openstack/keystone: Removes KVS catalog backend  https://review.openstack.org/15844202:28
*** browne has quit IRC02:30
openstackgerritSteve Martinelli proposed openstack/keystone: List assignments with names  https://review.openstack.org/24995802:31
stevemarrebase all the things!02:32
openstackgerritSteve Martinelli proposed openstack/keystone: Deprecate `hash_algorithm` config option  https://review.openstack.org/25626002:33
*** shaleh has quit IRC02:36
*** edmondsw has quit IRC02:37
openstackgerritSteve Martinelli proposed openstack/keystone: Mark memcache and memcache_pool token deprecated  https://review.openstack.org/26922902:39
openstackgerritSteve Martinelli proposed openstack/keystone: Deprecate `hash_algorithm` config option  https://review.openstack.org/25626002:39
openstackgerritSteve Martinelli proposed openstack/keystone: deprecate write support for identity LDAP  https://review.openstack.org/25625702:39
*** doug-fish has joined #openstack-keystone02:39
ayounglhcheng, regarding the circular deps on implied roles02:41
ayoungI have a patch, but it breaks some of henry's tests, and I am trying to figure out if I am OK with that02:42
stevemarholy smokes there are a log of conflicts02:42
*** dansmith has quit IRC02:42
*** markvoelker has quit IRC02:42
lhchengayoung: cool, I'll defer that to you then :)02:43
ayounglhcheng, question02:43
lhchengayoung: I am addressing other comments at the moment02:43
ayoungin an implied role we have the prior02:43
ayounglike this:02:43
ayoung {'project_id': u'e41b973c39664b3291918c375a9a9543', 'indirect': {'role_id': u'6826ebab18cb405097add293d34e0b12'}, 'user_id': u'5adba18e351b43fc91d6843d79bb1718', 'role_id': u'01a9b0009c094fb7acb872cff5fb3820'}02:43
*** spzala has quit IRC02:43
ayounglhcheng, what if a role is both explicitly assigned and a prior role.02:43
ayoungSHould we have both in ther,or just the explicit02:43
ayounghenry has both.02:44
*** doug-fish has quit IRC02:44
ayoungand if a role is implied via multiple priors, all of them are in there02:44
ayoungI think...I don't want that02:44
ayoungI think that explicit masks implicit, and implicit might be only one of the priors states02:44
ayoungstated02:44
*** spzala has joined #openstack-keystone02:45
openstackgerritSteve Martinelli proposed openstack/keystone: Mark memcache and memcache_pool token deprecated  https://review.openstack.org/26922902:46
ayounglhcheng, what do you think?02:46
lhchengayoung: I think it should also be there..02:46
lhchengayoung more for consistency02:46
ayounglhcheng, I'm also worried about size02:46
lhchengayoung: if you look at the logic in here: https://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L62802:47
ayounglhcheng, what about it?02:47
openstackgerritSteve Martinelli proposed openstack/keystone: Deprecate `hash_algorithm` config option  https://review.openstack.org/25626002:47
*** PsionTheory has quit IRC02:47
lhchengeven if the implied roles are already appended before, we keep on adding it just because the prior role could be different02:48
openstackgerritSteve Martinelli proposed openstack/keystone: deprecate write support for identity LDAP  https://review.openstack.org/25625702:48
*** dansmith has joined #openstack-keystone02:48
*** dansmith is now known as Guest3846202:48
lhchengayoung: that makes me think that we should return both..02:48
lhchengsince we are returning all anyway02:49
ayounglhcheng, that is just because that is what he is doing now02:49
stevemarso i think i queued up all the patches properly............02:49
stevemarsorry for the spam everyone!02:49
lhchengbut yeah, the size worries me02:49
ayoungbut...it is going to expand the size of the tokens02:49
ayoungand checking for role in roles means that it could be multiple...02:49
ayoungit should be a single entry like02:49
lhchengayoung: horizon takes the first hit with bigger token size :/02:50
ayoung {'project_id': u'e41b973c39664b3291918c375a9a9543', 'indirect': {'role_ids': [u'6826ebab18cb405097add293d34e0b12','icantbebotherdtorunuuidgen']}, 'user_id': u'5adba18e351b43fc91d6843d79bb1718', 'role_id': u'01a9b0009c094fb7acb872cff5fb3820'}02:50
jamielennoxayoung: your putting the indirects in the token?02:50
*** topol_ is now known as topol02:51
*** ChanServ sets mode: +v topol02:51
lhchengayoung: do you expect the prior and implied to be used in the policy file?02:51
ayounglhcheng, no02:52
ayounglhcheng, that is the thing, I think maybe putting it in there at all is a mistake now02:52
lhchengayoung: maybe we should not include prior02:52
lhchengeasier to add things later...02:52
lhchengonce we have it out there, we can't remove it02:52
ayounglhcheng, well, it is there now...patch merged02:52
lhchengayoung: it is merged on the backend code, but not exposed yet02:53
lhchengayoung: there's still time :)02:53
* lhcheng trying to be optimistic02:55
ayounglhcheng, I think I want to talk it over with Henry tomorrow03:00
ayoungUI'll write up my thoughts and send an email to openstack-dev, actually.03:01
lhchengayoung: sure, thanks for raising that concern.03:01
lhchengayoung: I am trying to write a test to raise a RoleNotFound error when an implied role is created. The creation keep on passing even if the pass a dummy role_id.03:03
ayounglhcheng, really?03:03
lhchengayoung: this code seems working even if I pass dummy role_ids: https://github.com/openstack/keystone/blob/master/keystone/assignment/role_backends/sql.py#L8303:03
ayoungSQL  not checking that the role exisits>?03:03
lhchengthe foreign_key is not kicking-in03:03
ayounglhcheng, are you running against SQLITe?03:04
ayoungI don;t think that enforces the integrity constraints03:04
ayoungtry against mysql03:04
lhchengyeah, against SQLite03:04
lhchengayoung: our tests run on SQLite?03:05
*** browne has joined #openstack-keystone03:06
ayounglhcheng, yeah, I think that is the onlty option thus far03:06
ayounglhcheng, unit tests, not functional.03:06
ayoungfunctional should ruin against MySQL.  To run unit tests against them would be prohibitive, I think03:07
lhchengayoung: if SQLite can't support foreignKey, should I skip the test for checking role existence? or perhaps do a get_role(..), before creating03:07
*** richm has quit IRC03:10
*** avarner_ has quit IRC03:12
*** davechen1 is now known as davechen03:12
ayounglhcheng, not worth coding explicitly for a broken DB.  We need functional tests against MySQl...write a03:13
ayoungWrite that03:13
*** su_zhang has joined #openstack-keystone03:16
openstackgerritDave Chen proposed openstack/keystone: Create V9 version of catalog driver interface  https://review.openstack.org/26945503:17
*** davechen has quit IRC03:17
*** davechen1 has joined #openstack-keystone03:19
lhchengayoung: agreed03:21
*** Ephur has quit IRC03:28
openstackgerritDave Chen proposed openstack/keystone: Create V9 version of catalog driver interface  https://review.openstack.org/26945503:39
*** _cjones_ has joined #openstack-keystone03:40
*** vivekd has quit IRC03:42
*** vivekd has joined #openstack-keystone03:44
*** gyee has quit IRC03:44
*** EinstCrazy has joined #openstack-keystone03:44
*** spzala has quit IRC03:45
openstackgerritLin Hua Cheng proposed openstack/keystone: Address comments from Implied Role manager patch  https://review.openstack.org/26999003:45
*** spzala has joined #openstack-keystone03:45
*** woodster_ has quit IRC03:46
*** EinstCra_ has quit IRC03:47
openstackgerritLin Hua Cheng proposed openstack/keystone: Address comments from Implied Role manager patch  https://review.openstack.org/26999003:49
*** andreaf has quit IRC03:50
*** spzala has quit IRC03:50
*** andreaf has joined #openstack-keystone03:52
*** dims has quit IRC03:54
*** dims has joined #openstack-keystone03:59
*** flwang1 has quit IRC04:01
gonzalo2kxexit04:04
*** gonzalo2kx has quit IRC04:04
*** spzala has joined #openstack-keystone04:05
*** links has joined #openstack-keystone04:06
*** lhcheng has quit IRC04:07
*** spzala has quit IRC04:10
*** dims has quit IRC04:13
*** markvoelker has joined #openstack-keystone04:14
*** flwang has joined #openstack-keystone04:14
*** lhcheng has joined #openstack-keystone04:25
*** ChanServ sets mode: +v lhcheng04:25
*** lhcheng has quit IRC04:26
*** lhcheng has joined #openstack-keystone04:26
*** ChanServ sets mode: +v lhcheng04:26
*** henrynash has joined #openstack-keystone04:34
*** ChanServ sets mode: +v henrynash04:34
*** doug-fish has joined #openstack-keystone04:42
*** su_zhang has quit IRC04:43
*** david-lyle has joined #openstack-keystone04:44
*** doug-fish has quit IRC04:46
*** doug-fish has joined #openstack-keystone04:49
*** doug-fish has quit IRC04:53
*** Nirupama has joined #openstack-keystone04:55
*** rderose has quit IRC05:01
*** josecastroleon has quit IRC05:03
*** oomichi_away has quit IRC05:04
*** jaosorior has joined #openstack-keystone05:06
*** spzala has joined #openstack-keystone05:06
*** su_zhang has joined #openstack-keystone05:07
*** oomichi has joined #openstack-keystone05:10
*** spzala has quit IRC05:11
*** Nirupama has quit IRC05:16
openstackgerrithenry-nash proposed openstack/keystone: Allow project domain_id to be nullable at the manager level  https://review.openstack.org/26453305:18
*** vivekd_ has joined #openstack-keystone05:23
*** vivekd has quit IRC05:23
*** vivekd_ is now known as vivekd05:24
openstackgerritDave Chen proposed openstack/keystone: Add schema for OAuth1 consumer API  https://review.openstack.org/26679105:26
stevemartopol: around?05:26
*** shoutm has quit IRC05:30
*** Nirupama has joined #openstack-keystone05:32
*** vivekd_ has joined #openstack-keystone05:33
*** vivekd has quit IRC05:35
*** vivekd_ is now known as vivekd05:35
*** Nirupama has quit IRC05:35
*** Nirupama has joined #openstack-keystone05:36
*** shoutm has joined #openstack-keystone05:38
*** vgridnev has joined #openstack-keystone05:44
lhchengstevemar: quick question, v2 token works on v3 endpoint right? but not the other way around.05:44
stevemarlhcheng: yes and sometimes, if the v3 token has the default domain, then i think it'll work...05:47
stevemarjeez, this pip failure could not have come at a worse time -_-05:48
lhchengstevemar: good pointer on reqt on having the default domain! :)05:48
stevemarlhcheng: this aint my first rodeo05:48
lhchengstevemar: heh05:48
lhchengstevemar: btw, I've responded on the comments for: https://review.openstack.org/#/c/269990/2/keystone/assignment/role_backends/sql.py05:49
stevemarlhcheng: yeah, i saw them05:49
lhchengstevemar: tried to generate the FK error on the tests, but it doens't work :(05:49
stevemarlhcheng: in my email, i didn't like the answers :P05:50
stevemarlhcheng: hehe05:50
stevemari figured something must have come up that made it hard, you're normally awesome about that05:50
stevemari grumbled a bit05:50
lhchengstevemar: l asked adam about that awhile ago, we'll cover those test in functional tests instead since the FK error doesn't trigger on SQLite.05:53
lhchengor I could be lazy too.. since adam already came up with the response :P05:53
stevemarlhcheng: ah it's fine05:54
lhchengstevemar: what does the magic word "recheck pep8 release" do?05:55
stevemarlhcheng: nothing05:56
lhchengforce job to use linter?05:56
stevemarlhcheng: starting anything with "recheck" just kicks off the job again05:56
lhchenglol oh okay, job still fails05:56
stevemarrecheck $reason05:56
stevemaryou give a reason so that it's easily searchable in elastic recheck05:57
stevemarrecheck wtihout a reason makes mriedem upset05:57
lhchengI see. I thought its a "secret code" that stevemar uses to make test pass :)05:58
lhchenggotcha05:58
stevemarlhcheng: nope, that's: up up, down down, left right, left right, a b a b select start05:58
lhchengHAH05:58
*** topol has quit IRC05:58
stevemarnooooo i got it wrong!05:59
stevemarhttps://en.wikipedia.org/wiki/Konami_Code05:59
stevemarit is: b, a; not a, b, a, b05:59
stevemar:(05:59
lhchengoh the cheat also works for Gradius!06:00
*** vgridnev has quit IRC06:00
*** tobasco has quit IRC06:00
lhchengoold games06:00
*** topol_ has joined #openstack-keystone06:00
stevemarworks on a a lot of konami games :O06:01
*** roxanaghe has joined #openstack-keystone06:01
*** tobasco has joined #openstack-keystone06:02
*** fawadkhaliq has joined #openstack-keystone06:02
*** spandhe has joined #openstack-keystone06:03
*** spzala has joined #openstack-keystone06:07
*** vgridnev has joined #openstack-keystone06:09
*** vivekd has quit IRC06:11
*** spzala has quit IRC06:12
lhchengstevemar: I got guilty and spent more time on looking at the foreign key for sqlite.. :P06:18
lhchengstevemar: looking at our code base, we don't expect the constraints to work: https://github.com/openstack/keystone/blob/af399474b2e67b023225a8abffe8933af40c1548/keystone/common/sql/migrate_repo/versions/062_drop_assignment_role_fk.py#L3106:18
stevemarlhcheng: lol06:19
stevemarwell then, that settles it06:19
lhchengstevemar: it can work, but it requires SQLite to be recompiled: http://docs.sqlalchemy.org/en/latest/dialects/sqlite.html#foreign-key-support06:21
lhchengwhew! I was worried I would find something that says "it should work"06:22
lhchenglol06:22
* lhcheng looking for sites to play contra online 06:24
*** spandhe has quit IRC06:24
lhchengstevemar: I'm off, have a good night!06:27
stevemarlhcheng: good night sir06:27
stevemarlhcheng: have fun playing contra06:27
lhcheng:D06:28
*** lhcheng has quit IRC06:28
*** roxanaghe has quit IRC06:32
stevemardolphm: notmorgan dstanek ayoung jamielennox marekd henrynash bknudson latest revision of the user survey, i think this is enough questions... https://etherpad.openstack.org/p/keystone-mitaka-user-survey06:36
*** vgridnev has quit IRC06:39
davechen1stevemar: where is the survey sent to?06:39
*** spandhe has joined #openstack-keystone06:39
stevemardavechen1: to 351 different operators!06:39
*** davechen1 is now known as davechen06:39
stevemardavechen: https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf06:40
davechenstevemar: where is those operators come from? :)06:40
*** jamielennox is now known as jamielennox|away06:40
stevemardavechen: no idea, the openstack foundation sends out the survey06:40
stevemardavechen: the link i sent has some info on it, it's the most recent survey i think06:41
davechenstevemar: ha, they did this every release cycle.06:41
stevemardavechen: i think companies have representatives that they get to answer the questions06:42
stevemaromg the gate is finally not barfing :O06:42
*** fawadk has joined #openstack-keystone06:43
*** yangyapeng has joined #openstack-keystone06:43
stevemarwhile it was down i lined up all the patches to go in one at a time, so we don't have merge conflicts06:43
stevemari think i'll cry if i wake up and a conflict happens06:43
davechenstevemar: good job!!!!06:43
*** odyssey4me has quit IRC06:44
*** bradjones has quit IRC06:45
*** bradjones has joined #openstack-keystone06:45
*** bradjones has quit IRC06:45
*** bradjones has joined #openstack-keystone06:45
*** fawadkhaliq has quit IRC06:47
*** jasonsb has quit IRC06:50
*** odyssey4me has joined #openstack-keystone06:51
*** jasonsb has joined #openstack-keystone06:52
*** henrynash has quit IRC06:52
*** gildub has quit IRC06:52
*** jaosorior has quit IRC06:54
*** ajayaa has joined #openstack-keystone06:55
*** jasonsb has quit IRC06:57
ajayaaHi stevemar, Is the gate not behaving nicely?06:58
stevemarajayaa: hasn't been behaving nicely for hours :(06:58
ajayaaIt seems like a lot of patches are getting -1 from Jenkins.06:58
ajayaaokay.06:58
ajayaacool06:58
davechennot nicely for couples of days!06:59
ajayaaI am looking for something to work on. Is there something I can help with now?06:59
ajayaaFor Mitaka-2 maybe!06:59
ajayaastevemar ^^06:59
*** vivekd has joined #openstack-keystone07:01
ajayaaAs of now just looking at patches in gerrit.07:01
*** rcernin has joined #openstack-keystone07:02
*** browne has quit IRC07:02
*** spzala has joined #openstack-keystone07:08
*** vgridnev has joined #openstack-keystone07:09
*** markvoelker has quit IRC07:11
*** markvoelker has joined #openstack-keystone07:12
*** spzala has quit IRC07:12
*** henrynash has joined #openstack-keystone07:15
*** ChanServ sets mode: +v henrynash07:15
stevemarajayaa: mitaka-2 is due tomorrow/today!07:16
stevemarajayaa: so mitaka-3 :)07:16
stevemarajayaa: any of the bugs here: https://launchpad.net/keystone/+milestone/mitaka-3 would be awesome07:16
stevemarajayaa: or just reviewing the blueprints, good reviewing is always helpful07:16
stevemarjamielennox|away: around... no you're not07:17
*** markvoelker_ has joined #openstack-keystone07:18
*** markvoelker has quit IRC07:20
*** su_zhang has quit IRC07:20
*** su_zhang has joined #openstack-keystone07:24
*** shoutm_ has joined #openstack-keystone07:29
*** shoutm has quit IRC07:31
ajayaahenrynash, I am working on https://bugs.launchpad.net/keystone/+bug/1535878. I think I should remove controller.protected decorator in the controller and in the backend fetch rows from assignment table to see if the user has a role on that project.07:37
openstackLaunchpad bug 1535878 in OpenStack Identity (keystone) "A user with a role on a project should be able to issue a GET /project call" [Medium,Confirmed] - Assigned to Ajaya Agrawal (ajayaa)07:37
ajayaaDo you think I am taking a right approach?07:37
henrynashajayaa: i doubt it!07:37
ajayaaI need to fetch user info from the context and pass it to the backend.07:37
ajayaaokay.07:38
ajayaaWhat would be a right way to tackle this in your opinion?07:38
henrynashajayaa: why can’t we just change the policy file?07:38
ajayaahenrynash, That also sounds like a solution. All the access control done by policy file. That's the idea I suppose. Instead of putting it in code everywhere.07:39
ajayaaThat's the right way to do it.07:40
ajayaaThanks07:40
henrynashajayaa: I was planning on fixing this tomorrow…just been busy today with the release07:40
ajayaaokay.07:40
ajayaaCan I do it today?07:40
ajayaaAnd you can jsut give a +207:40
*** belmoreira has joined #openstack-keystone07:40
ajayaa:)07:40
ajayaas/jsut/just07:41
henrynashsure07:41
ajayaaThanks!07:41
*** su_zhang has quit IRC07:42
*** markvoel_ has joined #openstack-keystone07:42
*** markvoelker_ has quit IRC07:43
openstackgerrithenry-nash proposed openstack/keystone: Allow project domain_id to be nullable at the manager level  https://review.openstack.org/26453307:44
stevemarhenrynash: you're in charge of rechecking if the gate fails again07:46
henrynashstevemar: ok!07:47
henrynashstevemar: got it, boss07:47
stevemarhenrynash: i rebased all the patches that were +2/+A'ed into a single chain, so as to reduce merge conflicts... https://review.openstack.org/#/c/256257/07:47
stevemar'deprecate write for ldap', all the way down to 'remove kvs backend'07:48
henrynashstevemar: ok…what was killing the gate?07:48
stevemarjust give it a recheck once this latest run fails (they've already failed according to zuul)07:48
stevemarhenrynash: pip v8.0.0.0 was released07:48
stevemarand it caused calamity07:48
henrynashstevemar: will do…..oh nice timing07:48
*** spandhe has quit IRC07:50
stevemarhenrynash: i'm forgetting, were you at the keystone meeting today?07:56
stevemarthis day has been a blur07:56
henrynashstevemar: yep07:56
stevemarmarekd: you were missing right?07:56
marekdi was, kind of unexpected stuff came out :(07:57
stevemarmarekd: no big deal, just wanted to tell you that a lot of topics came up, and it might be worth reading the backlog07:57
stevemarmarekd: if you're interested: https://etherpad.openstack.org/p/keystone-mitaka-user-survey you can add questions there07:57
marekdalways when I am not at the meeting big things come up :(07:58
marekdi've seen the survey.07:58
marekdi will read the backlog07:58
stevemarmarekd: hehe, no big deal, honestly. Nothing really big came up, just lots of little things07:58
ajayaahenrynash, A simple addition to the policy file like "or project_id:%(target.project.id)s08:01
ajayaadoes the job08:01
ajayaaThat is the rule I should add, I think.08:01
henrynashajayaa: it should do, yes….you should modify the tests in test_v3_protection to check it works too08:02
ajayaagot it. Already manually tested. It works.08:02
ajayaaWe are doing this only in V3 apis, right?08:02
*** _cjones_ has quit IRC08:02
*** _cjones_ has joined #openstack-keystone08:03
henrynashajayaa: yes….although Iguess there is no reason not to chnage the regualr polciy file as well, and those tests too08:03
ajayaahenrynash, agreed. So I have to change policy.json policy.v3cloudsample.json and unit tests now.08:05
henrynashajayaa: you got it08:05
ajayaaThanks a ton!08:05
*** spzala has joined #openstack-keystone08:08
*** _cjones_ has quit IRC08:10
*** spzala has quit IRC08:13
*** vivekd_ has joined #openstack-keystone08:17
*** vivekd has quit IRC08:19
*** vivekd_ is now known as vivekd08:19
*** fawadk has quit IRC08:29
*** shoutm_ has quit IRC08:33
notmorganboo, the supermicro board i have is not compat w/ my case :(08:39
*** pnavarro has joined #openstack-keystone08:39
notmorgani guess that means no ECC memory for my.08:39
notmorganme*08:39
* notmorgan packs things up to return.08:40
notmorganon the otherside, the consumer booard has an internet bios flash capability, nifty08:40
openstackgerritAjaya Agrawal proposed openstack/keystone: Change get_project permission  https://review.openstack.org/27005708:49
*** fawadkhaliq has joined #openstack-keystone08:51
*** fawadkhaliq has quit IRC08:56
ajayaastevemar, The pycadf validation is also one of the things which is scheduled for mitaka-3. https://bugs.launchpad.net/keystone/+bug/152184408:57
openstackLaunchpad bug 1521844 in OpenStack Identity (keystone) "pycadf ID validation fails for multi-domain IDs" [High,Confirmed]08:57
ajayaaYou have already a patch in https://review.openstack.org/#/c/252182/208:57
ajayaaI think it only needs a bit of polishing. Am I right?08:58
ajayaaBy that I mean address the review comments.08:58
ajayaaCan I pick it up?08:58
*** fhubik has joined #openstack-keystone09:01
*** spzala has joined #openstack-keystone09:11
*** ChanServ sets mode: +v topol_09:11
*** topol_ is now known as topol09:11
*** spzala has quit IRC09:15
*** jistr has joined #openstack-keystone09:16
*** mhickey has joined #openstack-keystone09:21
*** fawadkhaliq has joined #openstack-keystone09:26
*** vgridnev has quit IRC09:34
*** vgridnev has joined #openstack-keystone09:37
*** vivekd_ has joined #openstack-keystone09:52
*** davechen has left #openstack-keystone09:54
*** vivekd has quit IRC09:54
*** vivekd_ is now known as vivekd09:54
*** aix has joined #openstack-keystone09:56
*** EinstCra_ has joined #openstack-keystone10:01
*** jaosorior has joined #openstack-keystone10:02
*** jaosorior has quit IRC10:04
*** jaosorior has joined #openstack-keystone10:04
*** EinstCrazy has quit IRC10:04
*** EinstCra_ has quit IRC10:06
*** jaosorior_ has joined #openstack-keystone10:09
*** jaosorior has quit IRC10:11
*** spzala has joined #openstack-keystone10:11
*** spzala has quit IRC10:16
*** e0ne has joined #openstack-keystone10:25
*** fawadkhaliq has quit IRC10:26
*** fawadkhaliq has joined #openstack-keystone10:26
*** links has quit IRC10:28
openstackgerritGrzegorz Grasza (xek) proposed openstack/keystone: POC Online Schema Migration: Add BinaryHex field  https://review.openstack.org/26969310:34
*** jaosorior_ is now known as jaosorior10:39
amakarovlbragstad, it looks timezone makes it difficult for us to meet at the same time :)10:47
*** links has joined #openstack-keystone10:51
*** jasonsb has joined #openstack-keystone10:54
*** fhubik is now known as fhubik_brb10:54
*** markd_ has joined #openstack-keystone10:57
*** jasonsb has quit IRC10:59
*** vgridnev has quit IRC11:01
*** rcernin has quit IRC11:05
*** links has quit IRC11:05
*** rcernin has joined #openstack-keystone11:07
*** yangyapeng has quit IRC11:11
*** ktychkova has quit IRC11:11
*** _cjones_ has joined #openstack-keystone11:11
*** fhubik_brb is now known as fhubik11:13
*** rcernin is now known as rcernin|lunch11:13
*** vgridnev has joined #openstack-keystone11:15
*** _cjones_ has quit IRC11:16
*** daemontool has joined #openstack-keystone11:21
*** EinstCrazy has joined #openstack-keystone11:31
*** links has joined #openstack-keystone11:32
*** links has quit IRC11:38
-openstackstatus- NOTICE: review.openstack.org is being restarted to apply patches11:42
*** ChanServ changes topic to "review.openstack.org is being restarted to apply patches"11:42
*** openstackgerrit has quit IRC11:43
*** openstackgerrit has joined #openstack-keystone11:44
*** fhubik is now known as fhubik_brb11:50
*** fhubik_brb is now known as fhubik11:52
*** ChanServ changes topic to "Mitaka-2 deadline Jan 19th!!! | MidCycle: https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint | Mitaka-2: https://launchpad.net/keystone/+milestone/mitaka-2"11:53
-openstackstatus- NOTICE: Restart done, review.openstack.org is available11:53
*** vgridnev has quit IRC11:54
*** vgridnev has joined #openstack-keystone11:55
*** aix has quit IRC11:59
*** fawadkhaliq has quit IRC12:02
*** vgridnev has quit IRC12:08
*** vgridnev has joined #openstack-keystone12:10
*** spzala has joined #openstack-keystone12:13
*** boris-42 has quit IRC12:13
*** Nirupama has quit IRC12:16
*** spzala has quit IRC12:18
samueldmqdstanek: tjcocozz : lol (on everything as admin) :)12:20
dstaneksamueldmq: :-)12:20
htrutahenrynash: just saw what you did at the first patch. It was on my todo list. thanks12:22
samueldmqdstanek: henrynash: about the split of test_backend, when do you guys plan to take a look at ?12:23
samueldmqmidcycle ?12:23
samueldmqI am asking because it conflicts with too many patches (on merge conflict right now)12:24
*** gordc has joined #openstack-keystone12:25
*** doug-fish has joined #openstack-keystone12:25
amakarovsamueldmq, I think if you want something done, it's always better to come up with a proposal rather than just a request. Just make it happen and let others whine afterwards if they wish :)12:27
samueldmqamakarov: I have the proposal already, that's exactly what I am telling above12:32
samueldmqamakarov: what I want to avoid is to waste my time with rebasing it (which conflicts with too many patches) if it isn't a priority review at the moment12:33
*** aix has joined #openstack-keystone12:33
amakarovsamueldmq, oh, give a CR link please?12:33
*** davechen has joined #openstack-keystone12:33
samueldmqamakarov: https://review.openstack.org/#/c/268307/12:33
samueldmqamakarov: 7 patches starting there12:34
amakarovsamueldmq, I see. Doesn't look very popular among reviewers...12:35
samueldmqamakarov: yes, and I had discussed this before with david and henry, that's why pinging them12:36
samueldmq:)12:36
amakarovsamueldmq, I hope my +1 will help :)12:37
samueldmqamakarov: thanks12:38
*** fhubik is now known as fhubik_brb12:41
*** vgridnev has quit IRC12:46
*** dims has joined #openstack-keystone12:49
*** vgridnev has joined #openstack-keystone12:55
*** pauloewerton has joined #openstack-keystone12:59
*** rcernin|lunch is now known as rcernin13:07
openstackgerritDave Chen proposed openstack/keystone: Address comments from Implied Role manager patch  https://review.openstack.org/26999013:09
*** henrynash has quit IRC13:10
*** vgridnev has quit IRC13:11
*** ktychkova has joined #openstack-keystone13:13
*** spzala has joined #openstack-keystone13:14
*** doug-fish has quit IRC13:14
*** spzala has quit IRC13:15
*** spzala has joined #openstack-keystone13:15
*** doug-fish has joined #openstack-keystone13:16
*** daemontool has quit IRC13:18
*** belmoreira has quit IRC13:19
*** vgridnev has joined #openstack-keystone13:20
*** pumaranikar has joined #openstack-keystone13:23
*** davechen1 has joined #openstack-keystone13:23
*** ayoung has quit IRC13:24
*** davechen has quit IRC13:25
*** vgridnev has quit IRC13:31
*** dslev has joined #openstack-keystone13:34
*** bill_az has joined #openstack-keystone13:37
*** dslev has quit IRC13:43
*** haneef_ has joined #openstack-keystone13:48
*** toddnni_ has joined #openstack-keystone13:49
*** crinkle_ has joined #openstack-keystone13:49
*** sshen_ has joined #openstack-keystone13:50
*** davechen1 has left #openstack-keystone13:50
*** baffle__ has joined #openstack-keystone13:51
*** lifeless_ has joined #openstack-keystone13:51
*** trevorjay has joined #openstack-keystone13:51
*** gerhardq1x has joined #openstack-keystone13:51
*** pauloewerton has quit IRC13:52
*** kfox1111_ has joined #openstack-keystone13:52
*** vgridnev has joined #openstack-keystone13:52
*** tellesno` has joined #openstack-keystone13:54
*** rodrigod` has joined #openstack-keystone13:54
*** raildo` has joined #openstack-keystone13:54
*** mc_nair_ has joined #openstack-keystone13:54
*** raginbaj- has joined #openstack-keystone13:55
*** electrichead has joined #openstack-keystone13:55
*** bknudson_ has joined #openstack-keystone13:55
*** ChanServ sets mode: +v bknudson_13:55
*** krotscheck_ has joined #openstack-keystone13:55
*** htruta` has joined #openstack-keystone13:55
*** bradjones_ has joined #openstack-keystone13:55
*** hrou_ has joined #openstack-keystone13:55
*** mnaser_ has joined #openstack-keystone13:55
*** electrichead is now known as Guest1016413:55
*** bradjones_ is now known as Guest779113:55
*** mkoderer_ has joined #openstack-keystone13:55
*** notmorgan has quit IRC13:56
*** sshen has quit IRC13:56
*** bknudson has quit IRC13:56
*** zzzeek has quit IRC13:56
*** d0ugal has quit IRC13:56
*** toddnni has quit IRC13:56
*** haneef has quit IRC13:56
*** mnaser has quit IRC13:56
*** trevorj has quit IRC13:56
*** akscram has quit IRC13:56
*** raginbajin has quit IRC13:56
*** redrobot has quit IRC13:56
*** anteaya has quit IRC13:56
*** x58 has quit IRC13:56
*** rmstar has quit IRC13:56
*** kfox1111 has quit IRC13:56
*** gerhardqux has quit IRC13:56
*** raildo has quit IRC13:56
*** htruta has quit IRC13:56
*** rodrigods has quit IRC13:56
*** bradjones has quit IRC13:56
*** mc_nair has quit IRC13:56
*** mkoderer has quit IRC13:56
*** dulek has quit IRC13:56
*** crinkle has quit IRC13:56
*** clayton has quit IRC13:56
*** mancdaz has quit IRC13:56
*** lifeless has quit IRC13:56
*** hrou has quit IRC13:56
*** krotscheck has quit IRC13:56
*** baffle has quit IRC13:56
*** lars2 has quit IRC13:56
*** jidar has quit IRC13:56
*** toddnni_ is now known as toddnni13:56
*** mnaser_ is now known as mnaser13:56
*** krotscheck_ is now known as krotscheck13:56
*** rmstar has joined #openstack-keystone13:56
*** zzzeek has joined #openstack-keystone13:56
*** dulek has joined #openstack-keystone13:56
*** raginbaj- is now known as raginbajin13:56
*** clayton has joined #openstack-keystone13:57
*** mc_nair_ is now known as mc_nair13:57
*** LukeH has joined #openstack-keystone13:58
*** ninag has joined #openstack-keystone14:01
*** PsionTheory has joined #openstack-keystone14:02
*** d0ugal has joined #openstack-keystone14:02
*** akscram has joined #openstack-keystone14:03
*** lars2 has joined #openstack-keystone14:03
*** anteaya has joined #openstack-keystone14:03
*** raildo` is now known as raildo14:04
*** x58 has joined #openstack-keystone14:04
*** jidar has joined #openstack-keystone14:05
*** notmorgan has joined #openstack-keystone14:06
*** ChanServ sets mode: +v notmorgan14:06
openstackgerritGrzegorz Grasza (xek) proposed openstack/keystone: POC Online Schema Migration: Add BinaryHex field  https://review.openstack.org/26969314:09
openstackgerritRakesh H S proposed openstack/pycadf: Enable cadf support for Heat  https://review.openstack.org/27020614:11
*** Ephur has joined #openstack-keystone14:13
raildodstanek: ping, I need help with your python knowledge on this patch https://review.openstack.org/#/c/134095/15/keystone/tests/unit/test_sql_upgrade.py, do you have some minutes, sir?14:19
*** Ephur has quit IRC14:19
*** pauloewerton has joined #openstack-keystone14:20
*** LukeH has quit IRC14:27
*** edmondsw has joined #openstack-keystone14:33
*** petertr7_away is now known as petertr714:40
*** richm has joined #openstack-keystone14:50
*** su_zhang has joined #openstack-keystone15:02
*** daemontool has joined #openstack-keystone15:02
*** avarner_ has joined #openstack-keystone15:02
*** rodrigod` is now known as rodrigods15:02
*** josecastroleon has joined #openstack-keystone15:04
*** jaosorior has quit IRC15:06
*** petertr7 is now known as petertr7_away15:06
*** tellesno` is now known as tellesnobrega15:06
*** daemontool has quit IRC15:07
*** daemontool has joined #openstack-keystone15:07
*** jsavak has joined #openstack-keystone15:08
*** mancdaz has joined #openstack-keystone15:08
*** tellesnobrega has left #openstack-keystone15:09
*** rderose has joined #openstack-keystone15:10
ajayaadstanek, since this is one of the priorities for mitaka-3 https://review.openstack.org/#/c/252182/2, I am working on this. Since stevemar has given a -1 workflow on the patch, should I create a different review altogether for this?15:11
ajayaaor just slap a new patchset on top of the existing one?15:12
*** phalmos has joined #openstack-keystone15:12
*** daemontool has quit IRC15:13
*** su_zhang has quit IRC15:13
*** sigmavirus24_awa is now known as sigmavirus2415:13
*** boris-42 has joined #openstack-keystone15:16
*** hrou_ has quit IRC15:19
*** rderose has quit IRC15:20
*** hrou has joined #openstack-keystone15:20
*** spandhe has joined #openstack-keystone15:22
*** spandhe has quit IRC15:23
*** EinstCrazy has quit IRC15:24
*** markvoel_ has quit IRC15:25
*** fhubik_brb is now known as fhubik15:27
*** rderose has joined #openstack-keystone15:29
*** tonytan4ever has joined #openstack-keystone15:32
*** fhubik is now known as fhubik_brb15:35
*** vgridnev has quit IRC15:35
*** pushkaru has joined #openstack-keystone15:40
*** spzala has quit IRC15:41
*** fhubik_brb is now known as fhubik15:41
*** spzala has joined #openstack-keystone15:42
*** ninag has quit IRC15:43
*** spzala has quit IRC15:46
*** markvoelker_ has joined #openstack-keystone15:46
*** avarner_ has quit IRC15:48
*** jbell8 has joined #openstack-keystone15:49
*** Guest10164 is now known as redrobot15:49
*** ninag has joined #openstack-keystone15:51
*** vivekd has quit IRC15:53
*** spzala has joined #openstack-keystone16:01
*** roxanaghe has joined #openstack-keystone16:01
*** bigjools has quit IRC16:05
*** bigjools has joined #openstack-keystone16:07
*** jaosorior has joined #openstack-keystone16:08
*** roxanaghe has quit IRC16:09
*** jaosorior has quit IRC16:11
bretonraildo: ask the question to the channel please. I'd like to try to answer that too.16:15
raildobreton: sure, on that file (line 882-886) we made an assert to verify that when the de raise a duplicateEntry, the log error message was called. this tests works on python 2.7 but it is failed on python 3.4, and I don't know why...16:18
raildobreton: https://review.openstack.org/#/c/134095/15/keystone/tests/unit/test_sql_upgrade.py16:18
raildo"AssertionError: False is not true" on the last assert16:19
breton> There was an error when trying to create the unique constraint at the endpoint table: "None". There might be duplicate endpoint entries. Please remove them before upgrading.16:19
* breton is pulling the patch16:20
stevemarajayaa: thanks for asking in advance, feel free to stomp all over my patch and put up a new one16:21
stevemaron top, or separate, doesn't bother me either way16:22
*** slberger has joined #openstack-keystone16:22
*** diazjf has joined #openstack-keystone16:22
*** spandhe has joined #openstack-keystone16:23
*** rcernin has quit IRC16:25
bretonDetected a distutils installed project ('argparse') which we cannot uninstall. The metadata provided by distutils does not contain a list of files which have been installed, so pip does not know which files to uninstall.16:27
* breton sighs16:27
raildobreton: it was on that patch?16:28
bretonraildo: wel, yes, but it's unrelated16:28
bretonpy34 installdeps: -r/home/breton/src/openstack/keystone/test-requirements.txt, nose, .[memcache,mongodb]16:29
bretonoh, no ldap for py34 yet16:30
breton:(16:30
*** vgridnev has joined #openstack-keystone16:30
*** slberger has quit IRC16:31
*** slberger has joined #openstack-keystone16:34
*** henrynash has joined #openstack-keystone16:35
*** ChanServ sets mode: +v henrynash16:35
bretoncan't I run a single test with tox -e py34? :(16:36
lbragstadamakarov around?16:37
amakarovo/16:38
lbragstadamakarov have a few minutes for trust questions?16:38
amakarovlbragstad, sure, ask away16:39
*** fawadkhaliq has joined #openstack-keystone16:39
lbragstadamakarov ok, what exactly does redelegation mean? Does redelegation mean that if you are the trustor and I am the trustee, you've created a trust with role1 on project1 and allow redelegation16:40
lbragstadcan i take that trust.id and redelegate role1 on project1 to jorge_munoz ?16:40
lbragstadcreating a new trust?16:40
amakarovthat's right16:40
lbragstadok, so creating a trust with a role(s) on a project and a redelgated trust id should never happen, right?16:41
lbragstadyou should either create a trust with a role and a project, or a redelegated trust id16:42
amakarovlet's put it this way: you are trusted with role1 and role2 on project116:42
*** su_zhang has joined #openstack-keystone16:43
amakarovyou can redelegate role1 on project1 to jorge_munoz with the reference to initial trust you are redelegating16:43
amakarovso you can redelegate the scope not extending that you was delegated16:44
raildobreton: I have this problem too :P16:44
lbragstadamakarov ah, ok16:45
amakarovso a trust always has the scope16:45
lbragstadamakarov so, there is a possibility to pass a role.id, project.id, and redelegated_trust_id to create a new trust16:45
bretonraildo: which one? Running a single test?16:46
raildobreton: yes16:46
lbragstadif you pass a redelegated_trust_id, and not a role.id or project.id, does the trust api just assume the role.id and project.id from the redelegated_trust?16:46
amakarovlbragstad, I'd say everything besides redelegated_trust_id is required16:46
amakarovredelegated_trust_id is required in case you are not admin16:47
bretonraildo: .tox/py34/bin/nosetests keystone.tests.unit.test_sql_upgrade -m test_endpoint_unique_constraint_fails_if_duplicates16:47
lbragstadamakarov why is that?16:47
bretonraildo: but the funny thing is16:47
bretonraildo: that it won't fail this way16:47
bretonraildo: the test fails only when run with other tests16:48
*** fawadkhaliq has quit IRC16:48
raildobreton: that what i saw here :P16:48
*** fawadkhaliq has joined #openstack-keystone16:48
amakarovlbragstad, sorry, I'm wrong: redelegated_trust_id is required if you redelegating scope trusted to you16:49
amakarovnot assigned16:49
lbragstadamakarov ok, so an example would be16:49
amakarovlbragstad, you can create your own initial trust if you are assigned the scope you want to trust16:49
lbragstadyou are an admin and you create a trust with role1 and role2 on project1 between the two of us16:50
amakarovand if you are trusted this scope, you must reference the trust you are using16:50
amakarovok16:50
*** fawadkhaliq has quit IRC16:50
lbragstadthen, in order for me to create a trust between me and jorge_munoz - i have to pass in either role1 or role2, project1 and the redelegated trust id you gave me, right?16:50
amakarovright. of course you can trust both roles too16:51
lbragstadok, makes sense16:51
lbragstadamakarov ok, so lets say that jorge_munoz wants to redelegate role1 to ayoung on project116:54
lbragstadand - let's say that I don't have actual role assignments on project1 (the only role assignments I have are from the trust you gave me)16:54
lbragstadthen, in order for jorge_munoz to be able to successfully create a redelegated trust for ayoung, the entire redelegation trust chain needs to be traversed until it gets to you, then it checks to make sure that you actually have role1 on project 1, right?16:55
amakarovlbragstad, then he creates trust with role1 to ayoung on project1 and gives a reference to the trust between you and himself16:56
lbragstadamakarov yep - is that a valid use case16:56
lbragstad?16:56
lbragstadwhere the api needs to traverse the entire trust chain in order to verify that you (the *original* trustor) has role1 on project1?16:57
amakarovtraversal is needed to validate trust chain if needed16:57
lbragstadamakarov ok cool -16:57
lbragstadamakarov I think that is what jorge_munoz is doing here -16:57
lbragstadhttps://review.openstack.org/#/c/269824/4/keystone/trust/controllers.py16:57
amakarovlbragstad, that's a matter of consistency16:57
amakarovlbragstad, will you be on mid-cycle?16:58
lbragstadamakarov yes16:58
amakarovI want to sort out this assingment/trust mess16:59
amakarovhttps://review.openstack.org/#/c/189816/16:59
*** belmoreira has joined #openstack-keystone16:59
*** browne has joined #openstack-keystone17:01
lbragstadamakarov jorge_munoz is getting a bunch of context around trusts built up. Does that spec have to land in order for some of this stuff to get fixed?17:02
lbragstadamakarov I sat down with ayoung a couple nights ago and we determined that some of this trust works blocks making fernet the default token provider in keystone17:03
*** jsavak has quit IRC17:03
bretonraildo: at the moment when _LE() is called, it is not yet mocked17:03
*** jsavak has joined #openstack-keystone17:03
*** jistr has quit IRC17:04
amakarovlbragstad, I'm looking forward to discuss the situation17:04
*** lhcheng has joined #openstack-keystone17:04
*** ChanServ sets mode: +v lhcheng17:04
raildobreton: we tried follow this code https://github.com/openstack/keystone/blob/da3cd2dc4deed0093662e5ce098d8c022f654bc2/keystone/tests/unit/backend/domain_config/core.py#L49317:04
*** avarner_ has joined #openstack-keystone17:05
bretonif I move `from keystone.i18n import _LE` inside upgrade(), it works17:05
*** timcline has joined #openstack-keystone17:05
amakarovlbragstad, right now I'm preparing a chain of patches that can at least be a demo for unified delegation. Can you give me a link to the problem you a talking about?17:05
lbragstadamakarov I want to get fernet to be the default this cycle17:05
*** gyee has joined #openstack-keystone17:06
*** ChanServ sets mode: +v gyee17:06
raildobreton: hum... interesting17:06
lbragstadamakarov and that is dependent on merging the uuid/fernet code paths, consolidating testing, and some other refactors that include trusts17:06
amakarovlbragstad, an that impersonation issue is all that blocks fernet?17:06
lbragstadamakarov it's one of them17:06
bretonwait17:08
bretonlbragstad: I thought I fixed that17:08
lbragstadbreton fixed what exactly?17:08
bretonan issue with impersonation in fernet17:08
* breton is not sure if it's the bug you're talking about17:08
amakarovlbragstad, btw, can we add delegation_id to the token in the future? It will boost the validation speed17:08
bretonlbragstad: is there a bugreport?17:09
lbragstadbreton jorge_munoz and i were working on consolidating a bunch of the auth behavior tests - https://review.openstack.org/#/q/topic:26593117:10
lbragstadso that we can ensure we have consistent behavior when we switch from uuid to fernet17:10
lbragstadand it exposed a trust + fernet bug17:10
lbragstadhttps://review.openstack.org/#/c/265455/17:10
lbragstadand in the process, we've been trying to consolidate the behaviors of the trust stuff so that we can have all the auth behaviors running successfully with fernet17:11
lbragstadwhich is something that we've also touched on with https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:consolidate-fernet-provider because it makes both uuid and fernet use similar code paths17:12
bretonI fixed a problem related to trusts already in https://review.openstack.org/#/c/257478/17:13
*** e0ne has quit IRC17:13
breton(maybe I broke something with it, haven't looked at your patch good enough yet)17:14
lbragstadbreton they might be unrelated17:16
*** dims has quit IRC17:16
lbragstadregardless - jorge_munoz was the one doing a bunch of the testing refactor - which uncovered a bunch of questions around trust redelgation behavior - which has led us to his patch here https://review.openstack.org/#/c/26982417:17
*** _cjones_ has joined #openstack-keystone17:17
openstackgerritRon De Rose proposed openstack/keystone: Shadow users: unified identity - Separate user identities  https://review.openstack.org/26204517:18
nkinderstevemar: why isn't 8.0.1 mentioned in the timeline or available for source download here? https://launchpad.net/keystone/liberty/17:18
stevemarnkinder: we do things a bit differently now17:19
stevemarnkinder: you want the tarballs?17:19
stevemarhttp://docs.openstack.org/releases/17:19
stevemarhttp://docs.openstack.org/releases/releases/mitaka.html#mitaka-keystone17:19
stevemarhttp://docs.openstack.org/releases/releases/liberty.html#liberty-keystone17:20
nkinderstevemar: ok, thanks.  Looks like I have some tooling to update that expected the old locations.17:20
stevemarnkinder: you could bug dhellmann about it in #openstack-release17:21
stevemarbut this release has definitely changed things up17:22
openstackgerritRon De Rose proposed openstack/keystone: Shadow users: unified identity - Separate user identities  https://review.openstack.org/26204517:24
*** vgridnev has quit IRC17:25
*** tonytan4ever has quit IRC17:25
*** chris_19 has joined #openstack-keystone17:26
*** dims has joined #openstack-keystone17:26
chris_19In the keystone log, what's the number that comes between the time and the log level?17:27
stevemarchris_19: example?17:27
chris_192016-01-20 00:38:13.743 22289 INFO17:27
amakarovstevemar, hi! One colleague just asked me about adding an API call for self-testing. What do you think about the idea?17:27
amakarovstevemar, is it worthy to add it to etherpad for midcycle discussion?17:28
stevemaramakarov: self-testing? can you explain a bit more what that means?17:29
amakarovstevemar, curl /v3/self_test17:30
amakarova call that checks health of runnig instance17:30
amakarovfor ex. if database is available as given in config17:30
amakarovor memcaches are up17:31
amakarovrabbit is available17:31
amakarovstevemar, may be it's more a question to the oslo team...17:32
stevemaramakarov: my argument to that is, any API call will by default check if the database and rabbit is up :P17:32
stevemaramakarov: potentially, yes, or cross-project17:32
stevemarit's a good idea17:32
stevemarlike diagnosing the health of a system17:32
gyeestevemar, https://bugs.launchpad.net/python-openstackclient/+bug/153627817:33
openstackLaunchpad bug 1536278 in python-openstackclient "domain scoped token is broken in openstackclient " [Undecided,New]17:33
gyeewhat is os_client_config part of?17:33
amakarovstevemar, right - it may ease a life of dev-ops a bit17:33
gyeemordred, https://bugs.launchpad.net/python-openstackclient/+bug/153627817:33
stevemargyee: it's just a separate library, not a part of any project17:33
*** daemontool has joined #openstack-keystone17:34
stevemari think it's under the osc umbrella17:34
gyeestevemar, do we need to move that bug?17:34
stevemargyee: haven't looked at it yet, busy with mitaka-217:34
gyeedomain scoped token is broken right now17:34
mordredwhat's the probelm?17:34
mordredI pushed up a patch for it17:35
gyeemordred, it broken domain-scoped token17:35
mordredoh.17:35
mordredzomg17:35
mordredso - there is aNOTHER bug for this17:35
mordredwe removed this from the osc bug list yesterday17:35
mordredhttps://review.openstack.org/#/c/269704/17:35
mordredthis fixes it17:35
stevemarhttps://review.openstack.org/#/c/269704/17:35
stevemarheyooo17:35
gyeenice!17:36
stevemargyee: can you test that out and see if it resolves your issue?17:36
gyeestevemar, most def'ly17:36
stevemarmordred: so that's the bit that does the scoping?17:37
stevemarmordred: we need one more scope case, where the scope can be a trust ID17:37
mordredstevemar: I do not believe there is any support in occ for anything related to trusts at all17:38
stevemarmordred: the one hitch in trusts is that the "scope" is a trust ID, not a project or domain17:38
stevemarmordred: if you point me to the right lines to change, i'll happily put up a patch17:38
*** su_zhang has quit IRC17:38
gyeestevemar, so we can mark the bug as dup then?17:39
mordredstevemar: I'm not sure I know the right lines to change - as I'm not sure I understand the workflow with trusts17:40
mordredstevemar: do you provide neither a domain-id nor a project-id as part of your auth rcredentials to ksa?17:40
*** belmoreira has quit IRC17:43
chris_19So in the following log entry, is "22286" like a PID or something that can be tracked along other entries?17:44
chris_192016-01-20 00:38:10.405 22286 WARNING keystone.middleware.custom [req-0fb390f2-59de-451e-a4bc-1907d9e82e90 - - - - -] Bypassing the request to keystone17:44
*** daemontool has quit IRC17:44
stevemarmordred: correct, you provide neither or those, instead you provide a third, a trust_id17:44
stevemarmordred: looks like: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-trust-ext.html#consuming-a-trust17:45
mordredstevemar: SO - as long as the ksa password plugin groks trust id params, it should just work17:45
gyeemordred, stevemar, that patch works!17:45
mordredstevemar: the problem with occ in this case is that we were doing incomplete magic with inferring project_domain_name from domain_name17:46
gyeemordred, what's the release for os_client_config like?17:46
mordredwhich conflicts with how domain-scoped trusts in osc17:46
mordredgyee: we just need to land that patch, then we can cut a release easy peasy17:46
gyeemordred, cool, thanks!17:46
stevemargyee: yay17:46
*** ayoung has joined #openstack-keystone17:47
*** ChanServ sets mode: +v ayoung17:47
stevemargyee: you can turn the fire alarms off now17:47
gyeestevemar, hah17:47
*** spzala has quit IRC17:48
*** rderose has quit IRC17:48
*** spzala has joined #openstack-keystone17:49
*** spzala has quit IRC17:53
*** vgridnev has joined #openstack-keystone17:54
*** avarner_ has quit IRC17:55
openstackgerritLin Hua Cheng proposed openstack/keystone: Address comments from Implied Role manager patch  https://review.openstack.org/26999017:55
*** jsavak has quit IRC18:00
*** jsavak has joined #openstack-keystone18:01
*** tonytan4ever has joined #openstack-keystone18:01
*** crinkle_ is now known as crinkle18:04
*** browne has quit IRC18:05
dstaneki forgot to startup textual this morning :-)  i was wondering why it was so quiet18:08
dstanekdo we have an etherpad/gis/etc with the most important things to review?18:08
gyeedstanek, M3 you mean, M2 was yesterday18:11
*** lifeless_ is now known as lifeless18:12
*** markd_ has quit IRC18:12
dstanekgyee: yep, i currently have dozens of reviews on my list and no real way to prioritize them18:12
*** avarner_ has joined #openstack-keystone18:13
ayounghenrynash, so...I get what you were doing, and why your version of the expand implied roles was so different from mine.  I think you were thinking ahead to DSR, too.  The questION:  If a role is both direct and indirect, do we really need this info in the token?18:13
*** jsavak has quit IRC18:13
ayoungAnd,  if a role is indirect from multiple priors, do we really need them all?  My suspicion is that we should err on the side of terseness in the token:  keep them small18:14
*** jsavak has joined #openstack-keystone18:14
*** diazjf has quit IRC18:14
*** xek_ has joined #openstack-keystone18:14
openstackgerritAndreas Jaeger proposed openstack/keystoneauth: Remove argparse from requirements  https://review.openstack.org/27037018:16
gyeeayoung, what do you mean "indirect", isn't that implied roles about?18:17
*** kfox1111 has joined #openstack-keystone18:17
*** henrynash_ has joined #openstack-keystone18:17
*** ChanServ sets mode: +v henrynash_18:17
*** kragniz_ has joined #openstack-keystone18:17
*** e0ne has joined #openstack-keystone18:18
*** wasmum- has joined #openstack-keystone18:19
ayounggyee, yeah.  The question is how much info to provide inthe token18:19
*** chris_19 has left #openstack-keystone18:19
ayoungif a role is implied, and implied from multiple priors, do we really need to tlee that to the end application?18:19
ayoung I think the rule of thumb to go by here is only provider information that we want people to act upon18:20
*** su_zhang has joined #openstack-keystone18:20
openstackgerritAndreas Jaeger proposed openstack/python-keystoneclient: Remove argparse from requirements  https://review.openstack.org/27038618:20
ayoungso, while a user should be able to say "how did I get this role"  it does not need to be in the token18:20
*** a2hill has joined #openstack-keystone18:21
gyeeayoung, we need to entire chain in the token18:21
gyeeotherwise, implied role itself is useless18:21
*** diazjf has joined #openstack-keystone18:21
*** clayton_ has joined #openstack-keystone18:21
*** errr_ has joined #openstack-keystone18:21
ayounggyee, it is not useless, but youobviosuly have a need for the other info...what is it?18:21
*** henrynash has quit IRC18:22
*** clayton has quit IRC18:22
*** kfox1111_ has quit IRC18:22
*** med_ has quit IRC18:22
*** amakarov has quit IRC18:22
*** arif-ali has quit IRC18:22
*** xek has quit IRC18:22
*** wasmum has quit IRC18:22
*** sudorandom has quit IRC18:22
*** ptoohill has quit IRC18:22
*** kragniz has quit IRC18:22
*** errr has quit IRC18:22
*** henrynash_ is now known as henrynash18:22
gyeeeveryone still there? connections just drop like flies18:22
*** clayton_ is now known as clayton18:22
*** gyee has quit IRC18:22
*** clayton has quit IRC18:22
*** gyee has joined #openstack-keystone18:23
*** ChanServ sets mode: +v gyee18:23
*** med_ has joined #openstack-keystone18:23
*** med_ is now known as Guest6510318:23
ayounggyee, still here18:23
*** clayton has joined #openstack-keystone18:23
gyeeayoung, say, A implies B18:23
*** arif-ali has joined #openstack-keystone18:23
gyeeand my policy teeing off on B18:23
*** mhickey has quit IRC18:23
ayounggyee, why do we need the entier chain in the token?  Why not enforce RBAC on the roles, regardless of implied or not?18:23
gyeeayoung, say A implies B18:24
gyeeI have a policy that permits B18:24
gyeethat policy doesn't know anything about A yet18:24
ayoungright18:24
*** sudorandom has joined #openstack-keystone18:24
gyeeif B is not in the token, I don't have access18:24
ayoungcorrect18:25
gyeeso both A and B needs to be in the token18:25
ayounggyee, why Does A need to be in there?18:25
ayoungAnd, why does the token need to say "A implies B"18:25
ayoungif the roels weree just ['A','B']  RBAC would proceed as it does now18:26
gyeetoken just need to contain all the aggregates18:26
gyeea list of roles the user have18:26
ayounggyee, token needs only those roles that are appropriate for the requested operation.  In the future I want someone that has both A nand B to create a a token with just B to limit exposure18:26
gyeeayoung, that's your limited scoped BP?18:28
ayounggyee, does that make sense?  I think what you were saying is "don't drop A if I am going to do something that needs A'18:28
ayounggyee, yes it is that BP18:28
*** amakarov has joined #openstack-keystone18:28
ayounghttps://review.openstack.org/#/c/186979/  gyee that one18:28
ayounggyee, I wonder if even having the prior role indicated in the token is giving away too much information.18:29
ayounggyee, and...I don't see it in the specs yet, either.18:29
gyeeayoung, if I understand you correctly, say we have A -> B, you want to ability to include A but excludes B?18:29
ayounggyee, not really.   I was saying the other way around18:30
ayoungIf a-> b  I want to have a token with just B and not A...that is the more common18:30
gyeeyes, that's how it works today right?18:31
gyeewe only walk down the chain18:31
ayounggyee, todoay you get everything, everytime18:31
ayoungyou ask for a token with all the roles you are assigned on the project18:31
gyeesay a->b->c, if you are assigned b, you'll only get b and c18:31
ayoungright, that is what works today18:32
ayoungas of last night, I assume...did it merge?18:32
ayounghttps://review.openstack.org/#/c/264260/18:32
ayoungmerged .  w00t!18:32
gyeeright, lhcheng's followon patch to address the nits18:33
lhchengadded some more tests too18:34
lhchengayoung: when you get the chance: https://review.openstack.org/#/c/269990/18:34
gyeelhcheng, can you please change that debug log to error?18:34
*** sudorandom has quit IRC18:35
lhchenggyee: thought I included that, sure I'll add it.18:35
gyeelhcheng, thanks!18:36
ayounglhcheng, I just wrote this https://bugs.launchpad.net/keystone/+bug/153632118:36
openstackLaunchpad bug 1536321 in OpenStack Identity (keystone) "cyclic dependencies in implied roles" [Undecided,New]18:36
ayoungthat is the most important thing to fix.  But We kindof need henrynash here to figure out how to fix it18:36
*** ayoung has quit IRC18:37
openstackgerritJorge Munoz proposed openstack/keystone: Fix trust redelegation and associated test  https://review.openstack.org/26982418:37
*** ayoung has joined #openstack-keystone18:37
*** sudorandom has joined #openstack-keystone18:37
*** ChanServ sets mode: +v ayoung18:37
henrynashayoung: will look at it shortly18:38
openstackgerritLin Hua Cheng proposed openstack/keystone: Address comments from Implied Role manager patch  https://review.openstack.org/26999018:40
ayounghenrynash, short version.  Can we  drop "indirect" : {"role_id":"ABCD"} from the role entry in the token?18:40
ayounghenrynash, I'm mostly concerned about keeping the token small.18:41
henrynashayoung: that doesn’t go in the tokwn anyway18:41
henrynashayoung: that’s just for the result of list_role_assignments API18:41
henrynashayoung: internally when we call teh manager list_role_assignments() method for token creation, we just extract the role_id’s form the list18:42
lhchenghenrynash: let me know if you want help on tacking the cyclic issue on implied roles18:42
lhchengtacking/tackling18:43
henrynashayoung: see: get_roles_for_user_and_project() in assignment/core.py, which is actually what our token building calls18:43
henrynashlhcheng: thx!18:44
*** jasonsb has joined #openstack-keystone18:46
henrynashayoung: and do you think we should prevent circular implied roles when they are created, or evaluated, or both?18:47
*** fhubik has quit IRC18:48
*** sudorandom has quit IRC18:48
*** sudorandom has joined #openstack-keystone18:48
bknudson_stevemar: you didn't get your bonus for landing that feature?18:49
*** pnavarro has quit IRC18:49
ayounghenrynash, AH.18:49
ayounghenrynash, ok...so, I think we need to tweak tyhat API slightly18:49
*** doug-fish has quit IRC18:49
ayoungwhat if...18:50
ayoungwe collect up all of the indirect roles into a single role18:50
ayoungand add a qway to indicate , outside of that, that a role is direct , too18:50
ayoungso we have18:50
*** jasonsb has quit IRC18:51
ayounghenrynash, I'll code it up and paste it, one sec18:52
henrynashayoung: (as an aside, I’m not sure the rights or wrongs of that API help us solve the circular dependency issue….but I’ll hold fire!)18:52
ayounghenrynash, this will help...that is what I am trying toslve, but I don't want to break this part while I solve it18:53
henrynashayoung: remember we use the indrirect{} construct for group membership and inheritence already for how we shold where you got your effective roles from18:53
*** browne has joined #openstack-keystone18:53
ayounghenrynash, right...but what if something is both direct and indirect?18:53
henrynash(for how we show where….)18:53
*** doug-fish has joined #openstack-keystone18:53
ayoungwe should not have a separate entry in the role list for both, just a way of showing it18:54
ayounglike18:54
* ayoung types in paste...18:54
*** flaper87 has quit IRC18:54
*** flaper87 has joined #openstack-keystone18:54
henrynashayoung: then you see two entries in the response to list_role_assignments() - at least I think you do….18:54
ayounghenrynash, that is what we have prior to the last commit... http://git.openstack.org/cgit/openstack/keystone-specs/tree/api/v3/identity-api-v3.rst#n638318:54
ayounghenrynash, OK...so if we have multiple in the list, then when we make the token, we just have to deduplicate...18:54
ayoungI think I am IOK with that...OK...I got this18:55
ayoungI was going to do18:55
henrynashayoung: and we do that already…see: get_roles_for_user_and_project()18:55
openstackgerritTom Cocozzello proposed openstack/python-keystoneclient: set up incude names for list role assignments  https://review.openstack.org/25539218:55
ayoungrole: indirect{[r1, r2]}  but if it is just in the list, then yeah, lets leave them separate18:55
ayoungthen  the token only gets the single value.18:56
*** mc_nair has quit IRC18:57
*** mc_nair has joined #openstack-keystone18:57
*** edmondsw has quit IRC18:57
*** edmondsw has joined #openstack-keystone18:57
*** boris-42 has quit IRC18:57
*** boris-42 has joined #openstack-keystone18:57
*** hrou has quit IRC18:57
*** hrou has joined #openstack-keystone18:57
*** ninag has quit IRC18:57
*** ninag has joined #openstack-keystone18:57
*** spandhe has quit IRC18:58
*** spandhe has joined #openstack-keystone18:58
*** doug-fish has quit IRC18:58
ayounghenrynash, gyee we're good.  I'll post a fix to the cycles later on today or early tomorrow, as well as an updated implied roles patch.18:58
*** avarner_ has quit IRC18:58
*** avarner_ has joined #openstack-keystone18:58
*** sudorandom has quit IRC18:59
*** wasmum- has quit IRC18:59
*** wasmum- has joined #openstack-keystone18:59
*** ayoung has quit IRC18:59
*** ayoung has joined #openstack-keystone18:59
*** weber.freenode.net sets mode: +v ayoung18:59
*** ninag has quit IRC19:00
*** browne has quit IRC19:01
*** ninag has joined #openstack-keystone19:02
*** browne has joined #openstack-keystone19:02
*** ninag_ has joined #openstack-keystone19:03
*** woodster_ has joined #openstack-keystone19:03
*** ninag has quit IRC19:07
*** spzala has joined #openstack-keystone19:07
*** ninag_ has quit IRC19:08
*** RichardRaseley has joined #openstack-keystone19:08
*** ninag has joined #openstack-keystone19:08
*** ninag has quit IRC19:08
RichardRaseleyWhat is the best way to gracefully close a `keystoneclient.v3.Client` object?19:09
*** doug-fish has joined #openstack-keystone19:09
*** doug-fis_ has joined #openstack-keystone19:10
RichardRaseleyI was looking for something like keystone.v3.Client.disconnect, or somesuch.19:10
*** doug-fish has quit IRC19:14
gyeeayoung, ack19:16
*** aix has quit IRC19:16
openstackgerrithenry-nash proposed openstack/keystone: Change project unique constraint  https://review.openstack.org/15837219:20
openstackgerrithenry-nash proposed openstack/keystone: Change project unique constraint  https://review.openstack.org/15837219:24
*** tonytan4ever has quit IRC19:30
*** diazjf has quit IRC19:35
stevemarbknudson_: bone-us? i'm not familiar with that term19:36
notmorganstevemar: will be looking at the followup stuff, but feeling icky atm, just finished @ the dentist19:42
lbragstadxek_ I think this is looking pretty good, I only gave a +1 because I had a couple outstanding questions - https://review.openstack.org/#/c/265252/319:42
notmorganstevemar: so might be slow to get the stuff rollex up19:42
lbragstadxek_ I'd be have to upgrade that to a +2 though19:42
stevemarnotmorgan: that's fine19:45
stevemarbknudson_: thoughts on that ksm bug?19:45
stevemarhttp://lists.openstack.org/pipermail/openstack-dev/2016-January/084496.html19:46
*** diazjf has joined #openstack-keystone19:47
*** timothy_symanczy has joined #openstack-keystone19:49
notmorganxek_: I want to apologize for being hard on the binary uuid column19:49
notmorganxek_: but there are other places that could use love before we muck with datatypes for speculative/small wins19:50
*** timothy_symanczy is now known as tsymanczyk19:50
notmorganstevemar: which ksm bug?19:50
stevemarnotmorgan: the one in ML 3 lines up19:50
stevemarno bug yet, sorry, just reported regression19:51
notmorgan...19:51
notmorganahh19:51
notmorganok19:51
ajayaastevemar, looks like we need to return hex value of a UUID object, not the UUID object.19:51
notmorganbecause i was triaging bugs19:51
notmorganand was surprised a new bug showed up in the last few hours19:51
ajayaabtw, I am referring to https://review.openstack.org/#/c/252182/19:52
stevemarajayaa: i think you're right19:52
stevemarnotmorgan: i think https://github.com/openstack/keystonemiddleware/commit/f27d7f776e8556d976f75d07c99373455106de52 may be the issue?19:52
notmorganyep.19:52
notmorganwhich btw, that was not really doing anything useful19:52
stevemarjamielennox|away: not around yet?19:52
notmorgani can speak to that a lot19:53
notmorganit basically produced broken behavior19:53
stevemarnotmorgan: yeah, but now we have no caching :(19:53
notmorganso lets turn on memcache for devstack19:53
notmorganand do it right vs. wrong19:53
notmorganin-memory cache would actually [and likey has] procduced transient failures in the gate19:54
notmorganbecause each process has it's own unbounded cache19:54
notmorgani'm happy to roll up a change to get ksm stashing tokens in memcache in devstack today19:54
notmorganas the "correct" fix19:54
notmorganbut basically you can query <api> and get different validation responses because sometimes it's cached, sometimes not19:54
stevemarnotmorgan: if you can do it in a day, go ahead19:55
notmorganbased on what process you hit19:55
notmorganyeah i can probably have it rolled up in a couple hours19:55
notmorganit's not a big change, we already have memcache enable possible, so we just need to add a new ksm directive for each service19:55
notmorganin the config19:55
notmorganand it likely will be a bigger speedup because all services will share the validation cache19:55
notmorganlet me respond to that thread.19:56
notmorganand i'll spin up the devstack change19:56
stevemar++19:56
*** pushkaru has quit IRC19:58
notmorganjust responded to the ML20:00
stevemarajayaa: commented20:02
*** spzala has quit IRC20:04
*** su_zhang has quit IRC20:04
*** spzala has joined #openstack-keystone20:05
*** spzala_ has joined #openstack-keystone20:06
*** ninag has joined #openstack-keystone20:07
bknudson_stevemar: I was wondering if the change to use audit_ids wouldn't also slow things down.20:07
notmorganbknudson_: it will.20:07
bknudson_because now keystone has to fetch the extra fields20:07
bknudson_and this was an issue for a while20:08
notmorganbknudson_: but that should be minima20:08
notmorganl20:08
notmorganbknudson_: comparitive to the no-caching on the service side20:08
bknudson_so a bit of follow-on work is to put the audit IDs into a field in the table so we don't need the whole blob20:08
bknudson_another bit of work is to get auth_token using oslo.cache...20:09
bknudson_I wouldn't have a problem with reverting the no-caching change and find another way to get that done20:09
*** spzala has quit IRC20:09
*** spzala has joined #openstack-keystone20:10
*** spzala_ has quit IRC20:11
bknudson_were they ever able to show that reverting that change helped?20:12
stevemarayoung: can you undo your +A on https://review.openstack.org/#/c/269990/ - just for a day20:12
notmorganbknudson_: there is a patch to use oslo.cache, needs review20:12
notmorganbknudson_: it's on my list for today/tomorrow20:12
stevemarayoung: it conflicts with some of the stuff that is gating and i would like to get those in conflict free20:13
notmorganbknudson_: the audit_ids moved to a proper column makes sense.20:13
ayoungstevemar, will do20:13
ayoungstevemar, is that sufficient?20:14
bknudson_notmorgan: do you think it should be a string column with audit1, audit2 ; or separate columns so that it's searchable? I haven't thought about it much yet.20:14
*** spzala has quit IRC20:14
notmorganbknudson_: i don't think we need to search on audit_id20:14
notmorganbknudson_: tbh20:14
notmorganbknudson_: but i'd be ok with it either way. the overhead of 2 columns vs 1 is minimal20:15
notmorganfuture proofing says "might be nice to break it into two columns"20:15
notmorgannow, remember in fernet world... it doesn't matter20:15
notmorganso we still need the logic to handle the array packed.20:15
bknudson_I'll try 2 columns. y, for future proofing.20:15
stevemarayoung: i think so, i'll approve it when it's all in, or you can, whatever20:16
notmorganand hopefully uuid tokens become a think of the past/compat-but-not-used-in-production20:16
notmorganbknudson_: so, *shrug*20:16
ayoungstevemar, its all good.  We have a bit of work to do on implied roles, but I think I know how to make it all happen now....try to at least get the updated patches in the next day or so20:16
*** sudorandom has joined #openstack-keystone20:18
*** sudorandom has quit IRC20:28
*** jsavak has quit IRC20:33
*** diazjf1 has joined #openstack-keystone20:35
*** jsavak has joined #openstack-keystone20:35
*** diazjf has quit IRC20:37
*** sudorandom has joined #openstack-keystone20:42
*** boris-42 has quit IRC20:43
*** bknudson_ has quit IRC20:46
*** bknudson has joined #openstack-keystone20:47
*** ChanServ sets mode: +v bknudson20:47
*** timcline has quit IRC20:51
*** timcline has joined #openstack-keystone20:52
*** sudorandom has quit IRC20:53
*** timcline has quit IRC20:56
*** tonytan4ever has joined #openstack-keystone20:57
*** timcline has joined #openstack-keystone20:58
*** spandhe has quit IRC20:59
*** jsavak has quit IRC21:01
*** spandhe has joined #openstack-keystone21:03
*** jsavak has joined #openstack-keystone21:05
*** ninag has quit IRC21:06
lbragstaddolphm since you and rderose are familiar with this - just curious if you've reviewed it yet https://review.openstack.org/#/c/251455/8/keystone/common/sql/core.py21:07
*** raildo is now known as raildo-afk21:14
*** pauloewerton has quit IRC21:15
RichardRaseleyWhat is the best way to gracefully close a `keystoneclient.v3.Client` object?21:17
RichardRaseleyI was looking for something like keystone.v3.Client.disconnect, or somesuch.21:17
dolphmlbragstad: i haven't reviewed anything related to hierarchical multitenancy in a long time :-/21:17
dolphmRichardRaseley: clients don't maintain connections - there's nothing to worry about closing :)21:17
RichardRaseleydolphm: OK, good to know. Just trying to be good and clean up my mess. =]21:18
dolphmRichardRaseley: at least, keystoneclient doesn't. i imagine glance or swift could?21:18
dolphmRichardRaseley: ++21:18
bknudsonthe session might keep the connection open if the server supports it21:18
dolphmlbragstad: there's also no spec for the associated blueprint21:18
bknudsonRichardRaseley: you can close a requests session ; http://docs.python-requests.org/en/latest/api/#requests.Session.close21:19
*** diazjf1 has quit IRC21:19
RichardRaseleybknudson: That is Python requests, right? I am not directly using that library...21:20
lbragstaddolphm yeah, I noticed that21:20
dolphm!21:20
bknudsonRichardRaseley: keystoneauth / keystoneclient sessions are built on requests session, so if you were using that interface you could close it... not sure that you can close if you're not using a session21:20
bknudsonbtw - not using a session is deprecated.21:21
RichardRaseleybknudson: I am using Keystone sessions, but I didn't realize that was related to Python Requests. Thank you.21:21
notmorganRichardRaseley:  :)21:21
*** diazjf has joined #openstack-keystone21:22
notmorganRichardRaseley: the keystone session can almost [should actually be able to] be used interchangably with requests21:22
bknudsonI've got to admit I've never heard of anyone closing the session.21:22
notmorganRichardRaseley: with a little work.21:22
notmorganbknudson: depends on how long runing things are.21:22
bknudsonwe did get a complaint that servers weren't shutting down because auth_token held the connections open.21:22
notmorganbknudson: yeah that is a slightly different issue21:23
notmorganbut somewhat related...21:23
bknudsonbut that was a bug in the servers... they should shut down.21:23
notmorganyep21:23
dolphmlbragstad: dstanek: p.s. tested rderose's patch on top of the live migration one and it passes21:23
RichardRaseleyI also have a question around error handling. I have my keystone client wrapped in a try / except block (e.g. 'ks_client = keystone.v3.Client(session=s)`). Do I also have to wrap operations against that in their own try / except block? (e.g around ks_client.roles.list() )?21:23
bknudsonexceptions can happen at any time.21:23
dstanekdolphm: does that mean the live migration patch is broken?21:24
*** ayoung has quit IRC21:24
*** Ephur has joined #openstack-keystone21:24
dstanekdolphm: oh wait, we never delete the old users table do we?21:24
RichardRaseleySure, but I didn't know if those exceptions would be caught as part of the block around ks_client or if each operation would need its own try / except block21:24
lbragstaddolphm the live migration patch has a tests to check the db operations, right?21:24
lbragstaddolphm is that what you mean by test?21:24
*** ninag has joined #openstack-keystone21:25
dolphmlbragstad: yes21:26
dolphmlbragstad: the new unit tests pass against ron's new migrations21:27
*** roxanaghe has joined #openstack-keystone21:27
*** vgridnev has quit IRC21:28
openstackgerrithenry-nash proposed openstack/keystone: Change project unique constraint  https://review.openstack.org/15837221:32
lbragstaddolphm do you know if there is a way to query gerrit to not give you things you've already reviewed?21:34
dolphmlbragstad: yep!21:34
dolphmlbragstad: label:Code-Review<=+2,self21:35
dolphmlbragstad: rather, NOT label:Code-Review<=+2,self21:35
lbragstaddolphm glorious, thanks!21:35
lbragstaddolphm and NOT label:Code-Review<=+2,self is technically equivalent to -label:Code-Review<=+2,self right?21:36
dolphmlbragstad: yes21:36
*** pnavarro has joined #openstack-keystone21:37
*** htruta` is now known as htruta21:38
*** henrynash has quit IRC21:41
*** sudorandom has joined #openstack-keystone21:47
*** su_zhang has joined #openstack-keystone21:47
dstanekdolphm: actually even if we dropped the table i don't know that it would be picked up21:50
dolphmdstanek: L49? https://review.openstack.org/#/c/241603/13/keystone/tests/unit/test_sql_banned_operations.py21:57
dolphmdstanek: and test_table L6621:57
dstanekdolphm: do you know if ron plans on dropping the user table then?21:58
openstackgerritJorge Munoz proposed openstack/keystone: Fix trust redelegation and associated test  https://review.openstack.org/26982421:59
dolphmdstanek: under the online migrations guidelines, he can write the migration now, but we can't totally kill it until newton21:59
dstanekdolphm: oh wow. so we have to keep that table around that long?22:00
dolphmdstanek: yes, all tables and columns have have a N+1 cycle to be dropped22:00
*** spandhe has quit IRC22:00
dolphmdstanek: basically we have to support N-1 and N service versions running against an N version database schema22:02
dstanekdolphm: do we need to keep the data? i'm worried that if may be confusing to operators that the data lives in two places22:03
dstanekdolphm: at the same time?22:03
dolphmdstanek: that's the deal22:03
dstanekdolphm: that would be really bad if someone actually did that22:04
lbragstadjorge_munoz - https://github.com/openstack/gerrit-dash-creator22:05
dstaneklbragstad: jorge_munoz: that's how i created bit.ly/dstanek-review22:06
dolphmdstanek: actually did what?22:06
dstanekdolphm: ran N-1 and N against the same database22:07
bknudsondstanek: how else are you going to do on-line upgrade?22:08
dstanekbknudson: i'm not sure you can in many cases; take the shadows users as an example22:09
bknudsonyou wouldn't be able to use the new feature until everything was at N22:10
dstanekbknudson: with shadow users we are moving data to a new table. so any data added by N will not be readable by N-122:10
bknudsonunless N updates both the new data and the data read by N-1.22:11
*** kragniz_ is now known as kragniz22:12
dstanekbknudson: currently it doesn't22:12
*** jsavak has quit IRC22:12
bknudsonsounds like it's broken22:12
openstackgerritBrant Knudson proposed openstack/python-keystoneclient: Get revocation list with only audit ids  https://review.openstack.org/26019622:14
*** su_zhang has quit IRC22:15
notmorganso the only way schema stuff works afaik is "N can work with n-1 database" not "n-1 works with N database"22:15
*** su_zhang has joined #openstack-keystone22:15
notmorganso you can upgrade everything to N, then roll the schema forward22:15
notmorganbut trying to do the otherway is insantiy22:15
bknudsonthe only way N can work with N-1 is if we've got 2 models22:16
bknudsonthat's an sqlalchemy limitation22:16
bknudsonalso, then N would have to some how figure out when the db was migrated22:17
dolphmnotmorgan: oh yeah, i think i worded that poorly22:19
dolphmso, mitaka codebase must work with both the mitaka and liberty database schemas22:19
notmorganyesh22:19
notmorganthat would make sense22:20
notmorgan:)22:20
bknudsonhow is mitaka supposed to work with L? it's got the models for M22:20
*** ayoung has joined #openstack-keystone22:20
*** ChanServ sets mode: +v ayoung22:20
bknudsonthis is why we need to switch to mongodb22:20
dstanekbknudson: right, that was one of the points i brought up last time we talked about online schema migrations22:21
dolphmlol, sqlalchemy has some tricks we're not using yet22:21
dstanekdolphm: really?22:21
*** edmondsw has quit IRC22:21
dolphmdstanek: there's a cinder patch that demonstrates sqlalchemy handling two columns as one22:22
notmorganbknudson: i heard we can be webscale that way22:22
dolphmwhich is 90% of what we need, i think22:22
bknudsonhe he22:22
dstanekdolphm: would that work with data moving between models?22:22
dolphmall i care about is reliable tests for this22:22
dolphmdstanek: one model object has to understand both new and old schema22:23
dstanekdolphm: are you talking about using a @property with the real name that can access either column?22:23
*** boris-42 has joined #openstack-keystone22:23
dolphmdstanek: basically22:24
dstanekthat's basically what the shadow users patch does22:24
*** dims has quit IRC22:24
*** pnavarro has quit IRC22:24
dstanekhaving keystone<n> understand both database<n> and database<n-1> makes more sense :-)22:25
*** timcline has quit IRC22:26
bknudsonso how does the upgrade go in that case?22:26
dstanekrolling upgrade of keystone instances - expand database migrations - migrate data - contract database migrations?22:27
dstaneki don't really get the migration and contract parts yet22:27
*** spandhe has joined #openstack-keystone22:27
bknudsonhow does keystone know that the data is migrated?22:28
bknudsonyou could restart them again or send a signal or something?22:28
dstaneki'm guessing restart, but i'm trying to find some references22:29
dstaneki also don't know when you'd run the contractions because that would be downtime22:29
bknudsonthe alternative is -- keystone-manage db_sync to N+1, rolling upgrade22:29
dstanekalso adding an index to a large table is downtime22:29
bknudsonthe contractions happen on N+222:29
*** dims has joined #openstack-keystone22:30
dstanekbknudson: but there would be downtime for each release (except the first since there are no contractions)22:30
bknudsonwhat's the downtime?22:30
*** csoukup has joined #openstack-keystone22:31
bknudsonyou mean you've got some running N and some running N+1 and some running N+2?22:32
dstanekthe locking of tables will cause service disruption22:32
bknudsonwho's locking tables?22:32
notmorganalso table locking doesn't really work in real deployments22:33
notmorganbecause $galera22:33
dstanekthe database - mysql locks tables with doing certain (all) alters22:33
notmorganunless you're only doing one write master22:33
bknudsonthis is why nobody uses mysql22:33
notmorganor maybe it was only row locks that don't get replicated?22:33
notmorganbknudson: right. clearly that is the issue22:34
notmorganbknudson: you're sarcastic today man22:34
dstanekbknudson: i wish :-(  i really wish22:34
bknudsonwhat does mysql think is a large table?22:34
bknudsonI think nova thinks they've solved this problem somehow, so maybe it would be best to ask them.22:36
dstanekit's not that mysql thinks the table is large it's that the larger table you have the longer the lock may be held - i don't really think it would be terribly long, but i have not measured22:36
dstanekbknudson: yeah, i'm reading their spec now22:36
dstanekif you're interested https://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/online-schema-changes.html22:37
bknudsondstanek: nova-manage db doesn't have a contract like the spec says according to the help output22:40
bknudsonat least when you run keystone-manage it doesn't say `Option "verbose" from group "DEFAULT" is deprecated for removal.  Its value may be silently ignored in the future.` every time.22:41
*** phalmos has quit IRC22:41
*** BAKfr has joined #openstack-keystone22:43
*** tonytan4ever has quit IRC22:45
*** doug-fis_ has quit IRC22:46
*** jamielennox|away is now known as jamielennox22:47
openstackgerritAjaya Agrawal proposed openstack/keystone: Ensure pycadf initiator IDs are UUID  https://review.openstack.org/25218222:47
*** BAKfr has quit IRC22:47
jamielennoxstevemar: what's up?22:48
*** avarner_ has quit IRC22:49
openstackgerritAjaya Agrawal proposed openstack/keystone: Change get_project permissions  https://review.openstack.org/27051322:54
*** sigmavirus24 is now known as sigmavirus24_awa22:54
openstackgerritAjaya Agrawal proposed openstack/keystone: Ensure pycadf initiator IDs are UUID  https://review.openstack.org/25218222:58
*** henrynash has joined #openstack-keystone22:59
*** ChanServ sets mode: +v henrynash22:59
*** ninag has quit IRC23:02
*** slberger has left #openstack-keystone23:02
*** doug-fish has joined #openstack-keystone23:03
*** mordred has quit IRC23:04
*** lhcheng_ has joined #openstack-keystone23:05
*** mordred has joined #openstack-keystone23:05
*** lhcheng__ has joined #openstack-keystone23:06
*** zhiyan has quit IRC23:06
*** e0ne has quit IRC23:07
*** lhcheng has quit IRC23:07
*** dims has quit IRC23:07
*** doug-fish has quit IRC23:08
*** zhiyan has joined #openstack-keystone23:08
*** lhcheng_ has quit IRC23:09
*** jbell8 has quit IRC23:13
*** johnthetubaguy has quit IRC23:13
*** johnthetubaguy has joined #openstack-keystone23:16
*** su_zhang has quit IRC23:16
hogepodgeDoes anyone have pointers on how to integrate Keystone with OpenID Connect?23:17
*** gordc has quit IRC23:19
notmorganhogepodge: /me looks towards stevemar and marekd before answering or even trying to answer23:20
openstackgerritAjaya Agrawal proposed openstack/keystone: Change get_project permission  https://review.openstack.org/27005723:20
ajayaahenrynash, fixed in the old changeID.23:20
*** su_zhang has joined #openstack-keystone23:21
*** diazjf has quit IRC23:22
hogepodgenotmorgan: asking for a friend23:23
hogepodgethat friend being TryStack23:24
*** gildub has joined #openstack-keystone23:30
*** dims has joined #openstack-keystone23:32
openstackgerritEric Brown proposed openstack/keystone: Remove unused ProjectLdapStructureMixin class  https://review.openstack.org/27053023:35
*** lhcheng__ has quit IRC23:38
*** ajayaa has quit IRC23:39
jamielennoxdamn, i really didn't think anyone would get hit by the stop memory caching tokens thing23:39
jamielennoxeven in devstack i thought it was configured to use memcache23:39
*** lhcheng has joined #openstack-keystone23:41
*** ChanServ sets mode: +v lhcheng23:41
dolphmnotmorgan: nit! https://review.openstack.org/#/c/270474/4/lib/keystone23:41
notmorganit works either way23:42
notmorganjamielennox: nope23:42
notmorganjamielennox: but this is a real improvement fwiw23:42
notmorgandolphm: i'm gonna just roll my eyes at that option name change23:43
dolphmnotmorgan: that is understandable23:44
*** gildub has quit IRC23:44
notmorgandolphm: in-fact.. i kinda want to smack someones hands for that now23:44
dolphmnotmorgan: but, i'm more concerned about the dependency issue23:44
notmorganthat devstack requires memcache?23:44
notmorganmeh23:44
notmorganand this should reduce devstack memory footprint23:44
notmorganugh23:45
notmorganhttps://github.com/openstack/keystonemiddleware/commit/a23793a64455f8fdff740e190496d3fecaa7b7b1 that patch... CHANGED OPTION NAMES23:45
notmorganoh wait23:45
notmorganno.23:45
notmorganhttps://github.com/openstack/keystonemiddleware/commit/4810b626658e9f578c55ebd21895360b0167d54c that one23:45
notmorganreally?23:45
notmorganwhy23:46
*** sigmavirus24_awa is now known as sigmavirus2423:46
notmorganto get ATC?23:46
notmorganoh to fix for oslo.cache... that could have waited.23:46
*** BAKfr has joined #openstack-keystone23:47
notmorganstill *eyeroll*23:47
notmorgandolphm: anyway, this should be a netwin for devstack runs, since now instead of duplicating the cache all over many processes and being inconsistent on caching the validation, one validate caches for sunbsequent services down the line too23:47
dolphmnotmorgan: will your patch work on a multi node devstack deploy? because it looks like it's installing memcache where keystone is installed, not where keystonemiddleware is used23:49
notmorgandolphm: will need to check, it isn't causing failures/extended times with multinode23:49
notmorgandolphm: are you splitting API services with multinode at the moment or just compute23:50
notmorgani think it's the latter23:50
dolphmnotmorgan: we can do it either way - we design for a 27+ node control plane :P23:50
notmorganand we should add some variables in next to allow setting the memcache host.23:50
*** csoukup has quit IRC23:50
notmorgandolphm: in devstack?23:50
dolphmnotmorgan: no, in the real world23:50
notmorgandolphm: right and in realworld it works just fine to specify $memcache_host23:51
notmorganor whatever your breakdown is23:51
dolphm++23:51
notmorgan:)23:51
dolphmto be clear, i think your fix should work, but it's working slightly based on coincidence, not design :P23:51
notmorganit is working in the scope of "devstack"23:52
notmorganwhich is all it's meant to do.23:52
notmorganwhich, is by design.23:52
dolphmfair enough23:52
dolphmso, you want to roll with the deprecated name?23:52
notmorgani'll fix it will a followup to make memcache more configurable23:52
dolphmi assume there's a new warning emitted somewhere23:52
notmorganso you can get benefits of multinode in the future with devstack23:53
*** shoutm has joined #openstack-keystone23:53
notmorgani think we squash middleware warnings in devstack runs :P23:53
dolphmalright, +123:53
notmorganit passes devstack check, so clearly the warning is hiding23:54
notmorganif being emitted at all23:54
*** jbell8 has joined #openstack-keystone23:56
openstackgerritBrant Knudson proposed openstack/keystone: Parameter to return audit ids only in revocation list  https://review.openstack.org/26015323:57
openstackgerritEric Brown proposed openstack/keystone: Remove more ldap project references  https://review.openstack.org/27053023:59
*** sigmavirus24 is now known as sigmavirus24_awa23:59

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