Tuesday, 2017-03-21

*** edmondsw has joined #openstack-keystone00:03
*** edmondsw has quit IRC00:08
*** rderose has quit IRC00:20
*** jlopezgu has quit IRC00:21
*** masber has joined #openstack-keystone00:24
*** agrebennikov has quit IRC00:26
*** dikonoor has joined #openstack-keystone00:28
*** catintheroof has joined #openstack-keystone00:35
*** guoshan has joined #openstack-keystone00:39
*** gyee_ has quit IRC00:40
*** donu7 has quit IRC00:41
*** Aqsa has quit IRC00:43
*** adrian_otto has quit IRC00:50
*** Shunli has joined #openstack-keystone00:52
*** zsli_ has joined #openstack-keystone00:52
*** zsli_ has quit IRC00:52
*** Shunli has quit IRC00:52
*** Shunli has joined #openstack-keystone00:52
*** browne has quit IRC01:01
*** guoshan has quit IRC01:01
*** guoshan has joined #openstack-keystone01:02
*** dikonoor has quit IRC01:03
*** guoshan has quit IRC01:03
*** guoshan has joined #openstack-keystone01:03
*** prashkre has joined #openstack-keystone01:04
*** catintheroof has quit IRC01:08
*** guoshan has quit IRC01:12
*** liujiong has joined #openstack-keystone01:16
*** jamielennox is now known as jamielennox|away01:16
*** prashkre has quit IRC01:22
*** prashkre has joined #openstack-keystone01:23
*** amrith has joined #openstack-keystone01:23
amrithgreetings keystone folks. when requesting a token from keystone, can one specify a timeout (token life)? https://developer.openstack.org/api-ref/identity/v2/?expanded=authenticate-detail#authenticate doesn't provide any obvious way to do it. is it the case that the only solution is to change the global in /etc/keystone/keystone.conf token expiration?01:26
*** jamielennox|away is now known as jamielennox01:28
*** lespaul has quit IRC01:41
*** JDub has joined #openstack-keystone01:48
*** knangia has quit IRC01:51
*** guoshan has joined #openstack-keystone01:52
*** browne has joined #openstack-keystone01:53
*** JDub has quit IRC01:56
*** zhurong has joined #openstack-keystone01:57
*** pramodrj07 has joined #openstack-keystone01:59
*** pramodrj07 has quit IRC02:01
*** browne has quit IRC02:02
*** MasterOfBugs has quit IRC02:02
*** adrian_otto has joined #openstack-keystone02:15
*** wangqun has joined #openstack-keystone02:15
*** ravelar has quit IRC02:17
*** agrebennikov has joined #openstack-keystone02:47
*** aojea has joined #openstack-keystone02:48
*** zsli_ has joined #openstack-keystone02:52
*** aojea has quit IRC02:53
*** Shunli has quit IRC02:54
*** masber has quit IRC02:54
*** nicolasbock has quit IRC03:02
*** zhurong has quit IRC03:05
*** adrian_otto has quit IRC03:06
openstackgerritMerged openstack/oslo.policy master: Use Sphinx 1.5 warning-is-error  https://review.openstack.org/44660803:11
*** masber has joined #openstack-keystone03:15
*** spzala has joined #openstack-keystone03:19
*** zhurong has joined #openstack-keystone03:22
*** namnh has joined #openstack-keystone03:22
*** dave-mccowan has quit IRC03:29
*** adrian_otto has joined #openstack-keystone03:32
*** Aurelgadjo has joined #openstack-keystone03:37
*** Aurelgad1o has quit IRC03:40
*** links has joined #openstack-keystone03:44
*** MarkMielke has joined #openstack-keystone03:46
*** namnh_ has joined #openstack-keystone03:55
*** namnh has quit IRC03:58
*** spzala has quit IRC04:05
*** adrian_otto has quit IRC04:06
*** adrian_otto has joined #openstack-keystone04:07
*** jamielennox is now known as jamielennox|away04:12
*** zhurong has quit IRC04:12
*** d0ugal has quit IRC04:16
*** prashkre has quit IRC04:17
*** d0ugal has joined #openstack-keystone04:17
*** adrian_otto has quit IRC04:29
*** spzala has joined #openstack-keystone04:47
*** spzala has quit IRC04:51
*** zhurong has joined #openstack-keystone05:00
openstackgerritwingwj proposed openstack/python-keystoneclient master: Remove log translations in python-keystoneclient  https://review.openstack.org/44780505:05
*** spzala has joined #openstack-keystone05:11
*** spzala has quit IRC05:15
*** zhurong has quit IRC05:40
*** richm has quit IRC05:43
*** rcernin has joined #openstack-keystone05:43
*** guoshan has quit IRC05:46
*** markvoelker has quit IRC05:53
*** rcernin has quit IRC05:57
openstackgerritD G Lee proposed openstack/keystonemiddleware master: Remove log translations  https://review.openstack.org/44784106:00
*** knangia has joined #openstack-keystone06:02
*** guoshan has joined #openstack-keystone06:07
*** prashkre has joined #openstack-keystone06:08
*** adriant has quit IRC06:14
openstackgerritZhangHongtao proposed openstack/keystone master: Remove log translate  https://review.openstack.org/44785806:15
*** agrebennikov has quit IRC06:20
openstackgerritwingwj proposed openstack/keystone master: Remove log translations in keystone  https://review.openstack.org/44786406:21
openstackgerritSiyi Luo proposed openstack/oslo.policy master: Remove log translations  https://review.openstack.org/44786706:23
*** aojea has joined #openstack-keystone06:30
*** jaosorior has joined #openstack-keystone06:31
openstackgerritwingwj proposed openstack/python-keystoneclient master: Remove log translations in python-keystoneclient  https://review.openstack.org/44780506:38
*** aojea has quit IRC06:54
*** markvoelker has joined #openstack-keystone06:54
*** markvoelker has quit IRC06:58
*** david-lyle has quit IRC07:02
*** spzala has joined #openstack-keystone07:18
openstackgerritD G Lee proposed openstack/keystonemiddleware master: Remove log translations  https://review.openstack.org/44784107:20
*** spzala has quit IRC07:23
*** tesseract has joined #openstack-keystone07:35
*** spzala has joined #openstack-keystone07:43
*** pnavarro has joined #openstack-keystone07:44
*** maciejjozefczyk has quit IRC07:45
*** spzala has quit IRC07:48
*** spzala has joined #openstack-keystone07:50
*** spzala has quit IRC07:54
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-keystone08:00
*** spzala has joined #openstack-keystone08:02
*** spzala has quit IRC08:07
*** voelzmo has joined #openstack-keystone08:10
*** pcaruana has joined #openstack-keystone08:11
*** aojea has joined #openstack-keystone08:21
openstackgerritSiyi Luo proposed openstack/oslo.policy master: Remove log translations  https://review.openstack.org/44786708:27
*** knangia has quit IRC08:31
-openstackstatus- NOTICE: Wiki is broken with database problems, we are working to resolve it08:31
*** ChanServ changes topic to "Wiki is broken with database problems, we are working to resolve it"08:31
*** zhurong has joined #openstack-keystone08:34
*** spzala has joined #openstack-keystone08:38
*** ChanServ changes topic to "Meeting Agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h"08:39
-openstackstatus- NOTICE: Wiki problems have been fixed, it's up and running08:39
*** Aqsa has joined #openstack-keystone08:40
*** spzala has quit IRC08:42
*** markvoelker has joined #openstack-keystone08:55
*** markvoelker has quit IRC09:00
*** openstackgerrit has quit IRC09:03
*** mvk has quit IRC09:17
*** spzala has joined #openstack-keystone09:26
*** spzala has quit IRC09:31
*** spzala has joined #openstack-keystone09:38
*** spzala has quit IRC09:43
*** markvoelker has joined #openstack-keystone09:56
*** mvk has joined #openstack-keystone09:58
*** markvoelker has quit IRC10:00
*** zhurong has quit IRC10:05
*** nicolasbock has joined #openstack-keystone10:08
*** liujiong_lj has joined #openstack-keystone10:09
*** namnh_ has quit IRC10:09
*** liujiong has quit IRC10:09
*** richm has joined #openstack-keystone10:11
*** liujiong_lj has quit IRC10:12
*** jaosorior is now known as jaosorior_brb10:14
*** spzala has joined #openstack-keystone10:15
*** spzala has quit IRC10:19
*** zhurong has joined #openstack-keystone10:24
*** jamielennox|away is now known as jamielennox10:30
*** guoshan has quit IRC10:48
*** spzala has joined #openstack-keystone10:51
*** rmascena has joined #openstack-keystone10:52
*** spzala has quit IRC10:56
*** aojea_ has joined #openstack-keystone11:01
*** aojea has quit IRC11:03
*** jamielennox is now known as jamielennox|away11:05
*** jamielennox|away is now known as jamielennox11:12
*** mvk has quit IRC11:12
*** openstackgerrit has joined #openstack-keystone11:22
openstackgerritwingwj proposed openstack/keystone master: Remove log translations in keystone  https://review.openstack.org/44786411:22
Dinesh_Bhorjamielennox: Hi, may I have your attention on this? https://review.openstack.org/#/c/447377/11:23
*** mvk has joined #openstack-keystone11:25
*** guoshan has joined #openstack-keystone11:40
*** wangqun has quit IRC11:48
*** edmondsw has joined #openstack-keystone12:00
*** edmondsw has quit IRC12:05
*** edmondsw has joined #openstack-keystone12:26
*** dave-mccowan has joined #openstack-keystone12:37
*** jaosorior_brb is now known as jaosorior12:38
*** zhurong has quit IRC12:39
*** guoshan has quit IRC12:48
*** markvoelker has joined #openstack-keystone12:48
*** dave-mccowan has quit IRC12:49
openstackgerritRob Crittenden proposed openstack/keystone master: Include the requested URL in authentication errors  https://review.openstack.org/44672012:54
openstackgerritMerged openstack/oslo.policy master: oslopolicy-sample-generator description support  https://review.openstack.org/44333012:56
*** kencjohnston_ has quit IRC12:56
*** dave-mccowan has joined #openstack-keystone12:57
dstanekamrith: i don't think there is a per token way to do that13:01
amrithdstanek, thanks. I'm playing with just bumping it in keystone.conf for now13:03
dstanekdid you have a usecase where you wanted to limit some of the tokens to a shorter expiration?13:03
*** zsli_ has quit IRC13:06
*** kbaegis has joined #openstack-keystone13:08
*** voelzmo has quit IRC13:10
*** guoshan has joined #openstack-keystone13:15
*** links has quit IRC13:24
*** voelzmo has joined #openstack-keystone13:26
*** spilla has joined #openstack-keystone13:29
*** voelzmo has quit IRC13:30
*** guoshan has quit IRC13:34
*** adrian_otto has joined #openstack-keystone13:40
*** agrebennikov has joined #openstack-keystone13:51
*** spzala has joined #openstack-keystone13:55
lbragstadis anyone else getting this running `tox -e pep8` on python-keystoneclient master - http://cdn.pasteraw.com/m9gjo2vvsqbzvjfs5tc3aauj0dflbob13:57
*** catintheroof has joined #openstack-keystone13:57
*** adrian_otto has quit IRC13:58
*** voelzmo has joined #openstack-keystone14:02
*** voelzmo has quit IRC14:06
*** voelzmo has joined #openstack-keystone14:06
gagehugobut the requrement is wanting < 2.0.014:09
gagehugothat's odd14:09
gagehugolbragstad: https://review.openstack.org/#/c/439355/14:13
lbragstadgagehugo huh - i swear i approved that before14:14
lbragstadi guess not14:14
lbragstadi also saw a bunch of reviews proposing pbr 2.0.0 to stable branches14:14
lbragstadwhich i thought was strange - but the release team didn't seem to think it would be a problem14:15
* lbragstad shrugs14:15
gagehugoyeah there's one for stable/ocata as well: https://review.openstack.org/#/c/443881/14:16
*** guoshan has joined #openstack-keystone14:16
*** prashkre has quit IRC14:16
Dinesh_Bhorlbragstad: Hi, looks like this: https://review.openstack.org/#/c/439355/  will fix the failing test cases: https://bugs.launchpad.net/python-keystoneclient/+bug/167376114:18
openstackLaunchpad bug 1673761 in python-keystoneclient "py27 and py35 test cases are failing on current master" [Medium,In progress] - Assigned to Dinesh Bhor (dinesh-bhor)14:18
*** chlong has joined #openstack-keystone14:18
lbragstadDinesh_Bhor yeah - i just hit that, too14:18
lbragstadDinesh_Bhor I've approved it14:18
*** prashkre has joined #openstack-keystone14:18
Dinesh_Bhorlbragstad: I will abandon my patch: https://review.openstack.org/#/c/447377/ Could you please mark that bug as fixed then?14:19
lbragstadDinesh_Bhor yeah - i'll do that once the patch from the proposal bot merges14:19
*** knangia has joined #openstack-keystone14:19
Dinesh_Bhorlbragstad: ok, thanks a lot14:19
lbragstadDinesh_Bhor no problem - thanks for keeping me posted14:20
lbragstadstevemar dolphm notmorgan we're going to need someone to come through and start doing some stable reviews - https://review.openstack.org/#/c/443808/ https://review.openstack.org/#/c/443810/ https://review.openstack.org/#/c/443881/14:21
* lbragstad refills coffee14:22
notmorganI might need to step down as stable core14:22
notmorganwe will see how the week or next two progress14:22
*** prashkre has quit IRC14:23
*** chlong has quit IRC14:24
dolphmlbragstad: i can do that today14:24
*** guoshan has quit IRC14:25
*** lamt has joined #openstack-keystone14:27
*** guoshan has joined #openstack-keystone14:28
*** guoshan has quit IRC14:30
lbragstadnotmorgan thanks for the heads up14:33
lbragstaddolphm ack - thank you14:33
*** kbaegis has quit IRC14:39
*** rderose has joined #openstack-keystone14:42
*** kbaegis has joined #openstack-keystone14:42
dolphmstevemar: lbragstad: are the "clean up release notes" patches still applicable to stable branches?14:48
lbragstaddolphm i asked stevemar that question when I rebased a couple of them14:48
dolphmi've skipped reviewing those because it sounded like a mistake from some comment somewhere14:48
dolphmlbragstad: probably from you then14:48
lbragstada lot of the commit titles were referencing specific branches but the patches themselves were proposed to mismatching branches14:49
*** david-lyle has joined #openstack-keystone14:49
lbragstadand i'm not entirely sure if that how it was suppose to be because they were backports or not14:49
dolphmlbragstad: no word back from stevemar though?14:51
* lbragstad double checks logs14:51
dolphmlbragstad: also, i think the -1 can be reversed https://review.openstack.org/#/c/438354/14:51
*** ravelar has joined #openstack-keystone14:51
*** lamt has quit IRC14:52
lbragstaddolphm done14:52
lbragstaddolphm https://review.openstack.org/#/c/429178/1//COMMIT_MSG14:54
*** lamt has joined #openstack-keystone14:54
openstackgerritAnthony Washington proposed openstack/oslo.policy master: Add release note for 439070  https://review.openstack.org/44813914:55
*** belmoreira has joined #openstack-keystone14:56
*** dave-mccowan has quit IRC15:02
*** guoshan has joined #openstack-keystone15:04
*** lamt has quit IRC15:08
*** guoshan has quit IRC15:08
*** david-lyle has quit IRC15:09
*** kbaegis has quit IRC15:09
*** phalmos has joined #openstack-keystone15:15
*** david-lyle has joined #openstack-keystone15:15
*** guoshan has joined #openstack-keystone15:17
*** guoshan has quit IRC15:21
*** dave-mccowan has joined #openstack-keystone15:23
*** jrist has quit IRC15:33
*** phalmos_ has joined #openstack-keystone15:33
*** phalmos has quit IRC15:34
*** phalmos_ has quit IRC15:34
*** phalmos has joined #openstack-keystone15:36
*** adrian_otto has joined #openstack-keystone15:38
*** jrist has joined #openstack-keystone15:40
openstackgerritRichard Avelar proposed openstack/keystone master: Don't persist revocation events when deleting a role  https://review.openstack.org/44442415:50
*** adrian_otto has quit IRC15:52
*** auvipy has joined #openstack-keystone15:54
*** david-lyle has quit IRC15:54
openstackgerritRichard Avelar proposed openstack/keystone master: Don't persist rev event when deleting access token  https://review.openstack.org/44754915:55
*** jlopezgu has joined #openstack-keystone15:56
openstackgerritRichard Avelar proposed openstack/keystone master: Don't persist rev event when deleting access token  https://review.openstack.org/44754915:56
*** david-lyle has joined #openstack-keystone16:01
*** adrian_otto has joined #openstack-keystone16:01
*** lamt has joined #openstack-keystone16:03
*** lamt has quit IRC16:05
*** lamt has joined #openstack-keystone16:06
*** spzala has quit IRC16:10
EmilienMlbragstad: hey, would it make sense to revert https://review.openstack.org/#/c/439194/ and restore the spec? I don't want to have to approve https://review.openstack.org/#/c/445592/ and fix it in tripleo only16:19
EmilienMlbragstad: if it's a matter of human resource, please let me know and I can look internaly16:20
lbragstadEmilienM i'm not sure a revert would be the answer but a new spec could be proposed that goes through the official process16:20
EmilienMlbragstad: ok I see16:21
lbragstadEmilienM we removed the older spec because it was outdated and somewhat inaccurate16:21
EmilienMlbragstad: i'll try to push some efforts into this16:21
lbragstadEmilienM cool - i'll be on the look out for a new proposal16:21
*** kbaegis has joined #openstack-keystone16:23
*** voelzmo has quit IRC16:25
*** belmoreira has quit IRC16:25
*** jaosorior has quit IRC16:29
openstackgerritRichard Avelar proposed openstack/keystone master: Remove unnecessary revocation events revoke grant  https://review.openstack.org/44819216:39
*** rmascena has quit IRC16:45
*** Daviey_ is now known as Daviey16:49
*** jaosorior has joined #openstack-keystone16:55
*** aojea_ has quit IRC16:59
*** kbaegis has quit IRC17:00
lbragstadmfisch ping - curious if you'd be able to confirm dstanek's latest comment here https://bugs.launchpad.net/keystone/+bug/157840117:04
openstackLaunchpad bug 1578401 in OpenStack Identity (keystone) "tokens in memcache have no/improper expiration" [Low,Confirmed] - Assigned to David Stanek (dstanek)17:04
*** rmascena has joined #openstack-keystone17:05
dstaneklbragstad: looking at the meeting etherpad now. the answer to the py3 spec is no. we never merged a 3.4 spec - it was about moving the py3. 3.4 was just the latest at that time.17:05
lbragstadah - so that spec merged but it was never implemented?17:05
dstaneklbragstad: we already are py3 compatible17:06
lbragstaddstanek you said that there were a couple things we still needed to do to get better 3.5 coverage?17:06
dstanekto my knowledge there is no work to be done. i have a personal goal to add some unicode testing, but that's just testing17:06
lbragstadok - so i should be able to update our community goals for pike17:07
lbragstadto reflect that information17:07
*** kbaegis has joined #openstack-keystone17:07
dstaneklbragstad: yep. we've had the py3 tag for quite a while now17:07
lbragstadnice - i'll propose that patch then17:09
lbragstadgrabbing lunch17:09
dstaneklbragstad: mfisch: i believe that they reason we don't use oslo.cache is that we don't want to force it on middleware consumers. limiting deps and all that. so that's why there is a different.17:09
dstanekmy patch was merely a hack to make oslo.cache entries in memcache look more like memcache.py entries.17:10
dstaneklbragstad: that was so looong ago...it's all coming back to me now17:12
*** kbaegis has quit IRC17:27
*** kbaegis has joined #openstack-keystone17:27
*** spzala has joined #openstack-keystone17:27
*** lamt has quit IRC17:29
*** catintheroof has quit IRC17:30
*** catintheroof has joined #openstack-keystone17:30
*** prashkre has joined #openstack-keystone17:31
*** spzala has quit IRC17:32
*** david-lyle_ has joined #openstack-keystone17:37
*** david-lyle has quit IRC17:38
*** spzala has joined #openstack-keystone17:38
*** nkinder has quit IRC17:39
*** spzala has quit IRC17:41
*** spzala has joined #openstack-keystone17:41
lbragstadping agrebennikov, amakarov, annakoppad, antwash, ayoung, bknudson, breton, browne, chrisplo, cmurphy, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lamt, lbragstad, kbaikov, ktychkova, morgan, nishaYadav, nkinder, notmorgan, portdirect, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, SamYaple, shaleh, spilla, srwilkers,17:50
lbragstad StefanPaetowJisc, stevemar, topol, shardy, ricolin17:50
lbragstadreminder that the weekly keystone meeting will be starting in ~10 minutes in #openstack-meeting17:50
*** nkinder has joined #openstack-keystone17:53
notmorganwhoa, i spy an nkinder in the channel17:55
dstaneklbragstad: can't wait!17:57
nkindernotmorgan: hey!17:57
lbragstaddstanek get your coffee now ;)17:57
*** jaosorior has quit IRC17:57
dstaneklbragstad: way ahead of you water is already on its way to a boil17:58
lbragstaddstanek make a cup for me17:58
*** spzala has quit IRC17:59
dstaneklbragstad: np. i'll drink it for you too!18:01
*** spzala has joined #openstack-keystone18:01
*** lamt has joined #openstack-keystone18:01
lbragstaddstanek you're such a good friend!18:01
*** markd_ has quit IRC18:04
*** spzala has quit IRC18:05
*** spzala has joined #openstack-keystone18:07
*** spzala has quit IRC18:10
*** spzala has joined #openstack-keystone18:10
*** aojea has joined #openstack-keystone18:17
*** mvk has quit IRC18:18
*** spzala has quit IRC18:27
*** Aqsa has quit IRC18:28
*** tesseract has quit IRC18:31
*** henrynash has joined #openstack-keystone18:31
*** henrynash has left #openstack-keystone18:31
*** henrynash has joined #openstack-keystone18:33
*** spzala has joined #openstack-keystone18:34
*** henrynash has quit IRC18:36
*** henrynash has joined #openstack-keystone18:38
*** spzala has quit IRC18:38
*** pcaruana has quit IRC18:39
*** Tahvok has left #openstack-keystone18:40
*** aojea has quit IRC18:40
*** Tahvok has joined #openstack-keystone18:40
*** rmascena has quit IRC18:44
*** aojea has joined #openstack-keystone18:46
*** david-lyle_ has quit IRC18:46
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:49
*** mvk has joined #openstack-keystone18:53
lbragstaddstanek o/19:00
lbragstadbreton o/19:00
dstanekhey lbragstad19:01
dstaneklong time no see19:01
bretonlbragstad: o/19:01
lbragstadwe have a lot of carry over stuff from the meeting - if anyone is interested in hanging out here to continue talking about stuff we can19:01
*** henrynash has quit IRC19:02
lbragstad(er, i'll block of time to do so)19:02
dstaneki'm hanging out19:02
lbragstadok - so tags19:02
lbragstadall i was trying to say is that if we do tags, we should default the tag policies to the same policies required for projects19:03
lbragstadthinking that it would make it so that it was restrictive19:03
gagehugolbragstad: ++19:03
*** rmascena has joined #openstack-keystone19:04
gagehugothat is the intended goal19:05
dstaneklbragstad: but ayoung had a good point19:05
lbragstadotherwise - we'd have to put the tag stuff off until policy was a little more granular, right?19:05
dstanekthe current design is either admin only (for some definition of admin) or anybody19:05
*** lamt has quit IRC19:06
dstanekso i think that won't do anything19:06
dstanekwe have to decide if the binary admin vs. everybody matters.19:07
dstanekif we do what both to work in the same installation they we'd have to bake that into the design19:07
lbragstadso the problem is the domain-admin case, right?19:08
dstanektags may have their own policy. you could do domain scoped tags (but i see lots of problems here), and i could probably think of other solutions19:08
dstaneklbragstad: it's cloud admin vs everyone else19:08
lbragstadbecause its introducing a level in between "admin" and "everyone else" that we currently can't solve for.19:09
dstanekwe could with policy19:09
lbragstadbut not with default policy19:09
lbragstadper ayoung's security concern19:09
bretoni'll have to pass now19:10
bretonbut please review https://review.openstack.org/#/c/437533/19:10
dstaneklbragstad: right. we would have to allow people to include policy along with the tag19:10
gagehugoeach tag would have to have it's own policy?19:11
*** chlong has joined #openstack-keystone19:13
dstanekgagehugo: sure, it could19:13
*** spzala has joined #openstack-keystone19:13
dstanekit depends on if we care about that usecase right now or not19:13
dstanekwe could also defer because the policy thing would be easy to add on later19:14
*** spzala has quit IRC19:15
*** spzala has joined #openstack-keystone19:15
*** aojea has quit IRC19:17
*** aojea has joined #openstack-keystone19:18
lbragstadthe usecase would allow project owners to have their own tags, but also have tags they can't modify that are only viewable/editable by the cloud admin19:18
dstaneklbragstad: yes, exactly19:18
dstanekat a minimum we need to document that case.19:19
lbragstadi don't see a problem with clearly documenting that case and encouraging deployers to not use tags until we figure out how to address that case if it applies to them19:20
dstanekbreton: is it a viable option to just use the group from the token to create the trust and not check them at use time?19:20
*** auvipy has quit IRC19:20
dstaneklbragstad: or to only use tags for the admin-only case19:20
lbragstadand don't support project owner tags (or advertise that both can't be achieved in a secure model today)19:21
*** aojea has quit IRC19:22
lbragstadgagehugo so maybe what we do is modify the spec to detail how tags are expected to work with default policy from the perspective of an administrator, domain-admin, and user19:23
gagehugolbragstad: sure19:25
gagehugoI wonder if we can ask operators about this at Boston19:25
gagehugoadmin vs users for tags19:25
lbragstadThat should give us the opportunity to put a big red sticker on there that says "if you rely on domain-admin functionality to provision projects, but want to use tags for sensitive information that domain-admins aren't support to see, don't use this"19:25
dstaneklbragstad: gagehugo: the thing i like about the current proposal is that there is no 'create_tag' api, but there may need to be in the future if we need to associate policy with a tag19:25
lbragstaddstanek what would an example of that look like?19:26
*** gyee has joined #openstack-keystone19:26
dstanekPOST /tags {'tag': 'dev', 'policy': 'rule:cloud_admin'}19:28
dstanekthen policy would be checked within the context of the policy file. do the existing rules are there19:28
dstanekother than setting policy you wouldn't need to use create19:30
lbragstadthen you'd associate an existing tag like you normally would using PUT?19:32
samueldmqhi keystone!19:32
dstaneklbragstad: yeah, the editing of a project wouldn't change19:33
gagehugoso just the creation would be separate19:33
lbragstadbut - how does the policy of adding or removing of a tag to or from a project get enforced?19:34
lbragstadthe policy would have to be pulled from the tag reference?19:35
dstaneklbragstad: the API that is currently being proposed as well as create/update project would have to enforce19:35
samueldmquhh my review list is huge19:35
dstanekgagehugo: lbragstad: this is just one possible solution for if/when we care about this usecase19:36
*** MasterOfBugs has joined #openstack-keystone19:36
samueldmqdstanek: lbragstad: gagehugo: is there a spec on what you guys are talking about ?19:36
dstanekit's my off the cuff reaction so i'd need to spend some time actually thinking through all of the issues19:37
lbragstadsamueldmq yeah - the project tags spec https://review.openstack.org/#/c/431785/19:37
samueldmqlbragstad: thanks19:37
lbragstadfor now - if we want to make progress with it, i would say that we need to document the expected behavior of using tags from various user perspectives19:37
*** kbaegis has quit IRC19:37
*** kbaegis has joined #openstack-keystone19:38
dstaneklbragstad: yep. in my mind there are just a few steps. doc the usecase that was brought up in the current spec. decide if we care about it. if we do then decide if we care now (update spec) or later (new spec).19:39
*** kbaegis has quit IRC19:40
*** kbaegis has joined #openstack-keystone19:41
ayounggagehugo, really what you want is project "groups"  where a project-group admin can decided to add or remove a project from the group19:41
lbragstadgagehugo dstanek cool - so i think we've made progress19:41
ayoungI know that tags are the cool way to talk about things, but they really are for socialized organization of content19:42
ayoungAnd I know that Kubernetes uses Labels for all this kind of stuff, but K8S labels are scoped by namespace19:42
dstanekayoung: what is the difference between a group and a tag?19:43
ayoungdstanek, a tag is something the project admin can add or remove from a project.19:43
*** kbaegis has quit IRC19:43
ayounga group is an external entity that can add or remove the project itself from the grouping19:43
ayoungits all in "who can affect the change of relationship" I guess19:43
*** nicodemus_ has joined #openstack-keystone19:44
dstanekayoung: what i was proposing is tags in a very similar way19:44
*** kbaegis has joined #openstack-keystone19:44
dstaneki've worked in cms system where tags where owned by groups and could only be added by that group19:44
ayoungdstanek, I'm OK if that is what we are doing.  I just think the term "Tags" indicates that the project admin can add them19:45
ayoungand what we really mean is that the tag itslef is a scope of responsibility19:45
nicodemus_I have two keystone servers (v. Mitaka) loadbalanced under haproxy... one keystone works like a charm, but the second one is showing the following error: http://paste.openstack.org/show/603678/19:45
nicodemus_the config between them both is the same, and both use the same memcached servers19:46
ayoungnicodemus_, what kind of tokens?19:46
dstaneknicodemus_: do they have the same fernet keys?19:46
nicodemus_has anyone seen such behavior? someone that could point me to where to look, perhaps?19:46
nicodemus_yes, fernet tokens19:47
lbragstadnicodemus_ they need to share the same key repository19:47
nicodemus_and the keys are the same19:47
ayoungnicodemus_, I think you lie19:47
nicodemus_ayoung, maybe I'm mistaken :P let me check19:47
ayoungseriously, though, it looks like the tokens issued by one keystone are not honored by the other19:47
dstaneknicodemus_: 'cksum *' both key resositories19:48
lbragstadnicodemus_ the contents of each key should be the same19:48
ayoungnicodemus_, so, confirm that, and then come back.  Check permissions on the files, too, just to be sure19:48
dstaneknicodemus_: lots of people have had similar issues because they were rotating on each node instead of rotating on one and syncing the result19:48
nicodemus_hmm the checksum of both keys in both server in /etc/keystone/fernet-keys are the same...19:49
lbragstadnicodemus_ what about file permissions?19:49
lbragstad(though I would think it would fail before getting to that point in validation)19:50
ayoungnicodemus_, you are using a single Database for the Keystone backend?  Users in SQL and so on?19:50
nicodemus_yeah, all files in /etc/keystone are owned by the keystone user19:50
nicodemus_both keystone servers point to the same MySQL database19:50
dstaneknicodemus_: the DB and memcache shouldn't matter for this case. this is the server not being able to decrypt the token19:51
nicodemus_strangely enough, only one of the two keystone servers is complaining19:51
lbragstadnicodemus_ and both are the same version?19:52
ayoungdstanek, you sure?  There is a 404 at the end of the error, I wondered if maybe that was based on a failed lookup for one of the elements inside the fernet payload19:52
*** MasterOfBugs has quit IRC19:52
notmorganayoung: afair we don't negative cache, so memcache should not be an issue19:52
nicodemus_yes... I had a mismatching python-keystonemiddleware, but now both are the same version of *keystone*19:52
ayoungnotmorgan, if he restatrts memcached does that dump all the caches?19:53
*** lamt has joined #openstack-keystone19:53
dstaneknicodemus_: ayoung: this is where that error message comes from - http://git.openstack.org/cgit/openstack/keystone/tree/keystone/token/providers/fernet/token_formatters.py#n9119:53
notmorganayoung: yes. memcache would dump the cache (new ram allocation) if memcache is restarted19:54
*** spzala has quit IRC19:54
notmorganayoung: but like i said, we don't negative cache.19:54
lbragstadyeah - this is the only place we use that - https://github.com/openstack/keystone/blob/7de0a759e22a48391ce78e0c1fd5cceb16f1a1d8/keystone/token/providers/fernet/token_formatters.py#L90-L9419:54
ayoungdstanek, that sure looks like a key error to me19:54
*** prashkre has quit IRC19:54
ayoungnicodemus_, you can actually perform all the steps manuall;y19:54
samueldmqgagehugo: lbragstad: reviewed! couple of comments inline regarding project tags19:54
nicodemus_so, no doubt the error is from the second keystone server not being able to decrypt tokens issued by the first one19:54
*** prashkre has joined #openstack-keystone19:54
gagehugosamueldmq: thanks19:54
ayoungnicodemus_, what release of Keystone is this?19:55
*** kbaegis has quit IRC19:55
samueldmqgagehugo: it is looking well-written btw, could contain less implementation details (as you will see my comments)19:55
samueldmqgagehugo: but good job overall19:56
nicodemus_ayoung, Mitaka (v 2:9.2.0-0ubuntu1 installed from packages)19:56
dstaneksamueldmq: you want less details?19:56
samueldmqdstanek: implementation details should be in an API ref patch19:56
lbragstadsamueldmq are you talking abou thte API?19:56
lbragstadnicodemus_ this is the cryptography implementation https://github.com/pyca/cryptography/blob/master/src/cryptography/fernet.py#L7319:56
ayoungnicodemus_, ok, so you can open a python prompt and actually try to run that code yourself19:57
nicodemus_will give it a try19:57
*** kbaegis has joined #openstack-keystone19:57
ayoungimport keystone/token/providers/fernet/token_formatters etc and and see19:57
ayoungnicodemus_, where are you looking for the keys?19:57
samueldmqdstanek: lbragstad: gagehugo: going deep on the behavior in the spec is good. however no need to do depth on implementation details there19:57
lbragstadsamueldmq which parts are the implementation details?19:58
ayoungnicodemus_, its more than just "all the files in  /etc/keystone owned by smae user" but specifically the key repos under there having the same content19:58
nicodemus_ayoung, it's in [fernet_tokens] key_repository = /etc/keystone/fernet-keys/19:58
samueldmqlbragstad: the ones like having all the new APIs described with Request, Parameters, Response and Response Body19:58
lbragstadsamueldmq i think that's just describing the contact - which could be implemented a bunch of different way19:58
samueldmqlbragstad: IMO that should go in a API-ref change, which could go in the same patchset19:59
*** henrynash has joined #openstack-keystone19:59
ayoungnicodemus_, so for example, on my dev server I have http://paste.openstack.org/show/603680/19:59
ayoungyou need the content of /0 and /1   to be the same on both servers19:59
ayoungas those are the keys used to encrypt and decrypt tokens20:00
nicodemus_ayoung, I have the same two keys (0 and 1), and just checked that both are the same on both servers20:00
ayoungI think only 0 is ever used to encrypt, although I defer to lbragstad20:00
*** kbaegis has quit IRC20:00
lbragstadayoung nope - it's only allowed to decrypt20:00
ayounglbragstad, and 1 is used to encrypt?20:00
lbragstadthe *only* key that is ever allowed to encrypt is the primary key, which is the key with the highest index20:01
lbragstadayoung ++ yep20:01
dstaneklbragstad: samueldmq: i have the same opinion on the level of detail in the spec. i think it's good to have the contract in there20:01
bretondstanek: very hard to implement20:01
nicodemus_that's what I don't understand, I must be missing something20:01
ayoungthought it was lowest, but wouldn't trust myself anyway20:01
bretondstanek: (re: trusts with federation)20:01
dstanekbreton: why? (no being a smartass, i don't know :)20:01
ayoungnicodemus_, maybe a bad crypto library upgrade?20:02
*** dave-mccowan has quit IRC20:02
lbragstaddstanek i don't think the API contains implementation details, i think it just describes what we should be doing when we receive certain requests (if it contained code snippets of how to do thing, then I'd consider those to be implementation details)20:02
ayoungnicodemus_, I'd try it by hand, and see if you can decrypt a token on the failing server20:02
nicodemus_ayoung, possibly since there were two pip packages in different versions20:02
ayoungnicodemus_, get those in sync, maybe20:02
samueldmqdstanek: isn't that implementation detail?20:02
nicodemus_two keystone-* pip packages, that is20:02
dstaneklbragstad: i know. i was agreeing with you :-P20:03
lbragstadsamueldmq i would consider an implementation detail to be some specific to how *keystone* would have to do something20:03
lbragstaddstanek sorry - i'm getting my tabs/names mixed up20:03
samueldmqlbragstad: like "Utilize the resource_options table for projects.."20:03
lbragstaddstanek don't agree with me! ;)20:03
bretondstanek: there are not only groups, but also concrete role assignments, and we expect that if we remove concrete assignment, the trust is invalid20:04
dstaneklbragstad: so this is implementation detail in a way....and we do have an API doc for the contract....but i like enough of it here for discussion and history20:04
samueldmqdstanek: yes that's why I suggested it could be added in the same patch, but as the API-ref docs20:04
*** kbaegis has joined #openstack-keystone20:05
dstaneksamueldmq: so when i go to the website for specs and read out the spec. where do i go to see a simplified version of the API that was talked about?20:05
dstaneki think this is largely a preference issue and i wouldn't push back on specs written in either way. i would probably write mine more like this20:06
samueldmqdstanek: well, normally you go to the user (api-ref)/deployer docs to learn about the functionality, right?20:07
samueldmqnot really the specs20:07
dstanekalthough i probably wouldn't put in response code details, etd.20:07
samueldmqdstanek: I agree with you, I don't want to bike-shed on that20:07
dstaneksamueldmq: no. that is the current API. no necessarily related to the spec i am researching20:07
samueldmqI thought the spec was supposed to be a developer level agreement on the solution20:08
samueldmqnot final docs final users were supposed to read20:08
samueldmqdstanek: lbragstad: gagehugo: but regarding that spec, again, I am fine with that, it is very well written and easy to read.20:08
dstanekbreton: wouldn't that be true? you don't validate that the groups are still attached to the user, but you would need to validate that the roles are on the groups that the token claims to have20:09
nicodemus_ayoung, apparently it was a versin mismatch in the cryptography package (1.7.2 the working one vs 1.2.3 the broken one)20:09
ayoungnicodemus_, good to know20:09
nicodemus_lbragstad, dstanek, ayoung thank you all for you help! much appreciated20:10
dstanekbreton: i may be over simplifiying this, but i was just thinking that upon validation the validation of the groups would be guarded with 'if token is from federated_trust:'20:10
dstaneknicodemus_: whoa, that's actually scary20:10
nicodemus_someone must have installed something on this server that downgraded cryptography version20:11
*** MasterOfBugs has joined #openstack-keystone20:11
dstanekthat's bad for our upgrade story.....20:12
dstaneklbragstad: dolphm: ^20:13
*** henrynash has quit IRC20:13
bretondstanek: i would have to fetch concrete role assignments, check them, then do not check group assignments... well, we just don't do that anywhere. We just get "role assignments", wherever they come from, and they get assembled in assinments code20:15
bretondstanek: your solution would work too though20:15
*** browne has joined #openstack-keystone20:16
bretoni just think that mine will be easier to implement. Maybe i'm wrong.20:16
* breton should code a POC for the next meeting20:16
*** rmascena has quit IRC20:17
dstanekbreton: i'm just wondering about the ephemeral-ness of the user. this could give use the best of both worlds (although trusts would still not be ideal, everything else would)20:17
*** chlong has quit IRC20:21
*** lamt has quit IRC20:23
lbragstaddstanek interesting20:24
*** Aqsa has joined #openstack-keystone20:25
*** clenimar has joined #openstack-keystone20:26
lbragstadsamueldmq dstanek gagehugo reading the scroll back - just got out of a meeting, one benefit that i see of having the API in the spec is that it makes it really easy to port the API to docs after the implementation lands20:26
samueldmqlbragstad: that makes sense if we want to merge the docs after the impl20:27
*** lamt has joined #openstack-keystone20:28
*** lamt has quit IRC20:29
gagehugolbragstad: ++, the api-ref is pretty much 90% written then20:31
*** dave-mccowan has joined #openstack-keystone20:32
*** aojea has joined #openstack-keystone20:41
*** chlong has joined #openstack-keystone20:48
*** phalmos has quit IRC21:00
*** lamt has joined #openstack-keystone21:11
*** kbaegis has quit IRC21:17
*** kbaegis has joined #openstack-keystone21:17
notmorganlbragstad: i know it is a beast but: https://review.openstack.org/#/c/438701/ improves password hash security21:19
notmorganlbragstad: and we store password hashes, so we should aim for the most secure option(s)_21:20
*** david-lyle has joined #openstack-keystone21:23
*** spilla has quit IRC21:24
*** alex_xu has quit IRC21:37
*** alex_xu has joined #openstack-keystone21:38
*** chris_hultin|AWA is now known as chris_hultin21:41
*** chris_hultin is now known as chris_hultin|AWA21:48
*** nicodemus_ has quit IRC21:49
*** pnavarro has quit IRC21:54
*** lamt has quit IRC21:54
*** lamt has joined #openstack-keystone21:56
*** catintheroof has quit IRC21:57
*** catintheroof has joined #openstack-keystone21:58
*** catintheroof has quit IRC21:58
*** henrynash has joined #openstack-keystone22:04
openstackgerritColleen Murphy proposed openstack/keystone master: Speed up check_user_in_group for LDAP users  https://review.openstack.org/44745922:17
*** henrynash has quit IRC22:18
*** browne has quit IRC22:19
*** chlong has quit IRC22:27
*** lamt has quit IRC22:29
*** adrian_otto has quit IRC22:44
*** adriant has joined #openstack-keystone22:52
*** aojea has quit IRC22:53
*** david-lyle has quit IRC22:57
*** _d34dh0r53_ has joined #openstack-keystone23:00
*** _d34dh0r53_ has quit IRC23:00
*** _d34dh0r53_ has joined #openstack-keystone23:04
*** eglute_s has joined #openstack-keystone23:04
*** harlowja has quit IRC23:06
*** eglute_s has quit IRC23:07
*** _d34dh0r53_ has quit IRC23:07
*** eglute_s has joined #openstack-keystone23:34
*** _d34dh0r53_ has joined #openstack-keystone23:34
*** jamielennox is now known as jamielennox|away23:35
*** jamielennox|away is now known as jamielennox23:39
*** _d34dh0r53_ has quit IRC23:46
*** eglute_s has quit IRC23:46
*** _d34dh0r53_ has joined #openstack-keystone23:47
*** eglute_s has joined #openstack-keystone23:47
*** eglute has quit IRC23:50
*** d34dh0r53 has quit IRC23:50

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