Tuesday, 2017-03-07

*** _cjones_ has quit IRC00:21
*** _cjones_ has joined #openstack-keystone00:21
*** aasthad has quit IRC00:22
*** _cjones_ has quit IRC00:26
*** liujiong has joined #openstack-keystone00:27
*** zsli has joined #openstack-keystone00:42
*** zsli has quit IRC00:42
*** Shunli has joined #openstack-keystone00:42
*** agrebennikov has quit IRC00:53
*** zsli_ has joined #openstack-keystone01:01
*** namnh has joined #openstack-keystone01:03
*** Shunli has quit IRC01:04
*** zhurong has joined #openstack-keystone01:05
*** thorst has joined #openstack-keystone01:17
openstackgerritMerged openstack/keystone master: API-ref return code fix  https://review.openstack.org/44203401:17
*** guoshan has joined #openstack-keystone01:17
*** thorst has quit IRC01:18
*** thorst has joined #openstack-keystone01:27
*** lucasxu has joined #openstack-keystone01:28
*** edmondsw has joined #openstack-keystone02:00
*** edmondsw has quit IRC02:00
*** edmondsw has joined #openstack-keystone02:00
*** zsli__ has joined #openstack-keystone02:01
*** zsli_ has quit IRC02:03
*** erlon has quit IRC02:15
*** markvoelker has quit IRC02:16
openstackgerritAdrian Turjak proposed openstack/keystone master: Make name fields a consistent size of 255  https://review.openstack.org/44094102:21
*** MasterOfBugs has quit IRC02:21
*** pramodrj07 has quit IRC02:22
*** ngupta has joined #openstack-keystone02:26
*** thorst has quit IRC02:33
*** thorst has joined #openstack-keystone02:33
*** thorst has quit IRC02:38
*** guoshan has quit IRC02:42
*** ayoung has left #openstack-keystone02:46
*** oomichi has quit IRC02:50
*** oomichi has joined #openstack-keystone02:50
*** edmondsw has quit IRC02:55
*** edmondsw has joined #openstack-keystone02:56
*** edmondsw has quit IRC03:01
*** lucasxu has quit IRC03:15
*** guoshan has joined #openstack-keystone03:15
*** lucasxu has joined #openstack-keystone03:24
*** lucasxu has quit IRC03:24
*** rderose has quit IRC03:32
*** thorst has joined #openstack-keystone03:34
*** links has joined #openstack-keystone03:35
*** thorst has quit IRC03:38
*** browne has quit IRC03:40
*** thorst has joined #openstack-keystone03:56
*** thorst has quit IRC03:56
*** guoshan has quit IRC04:02
*** markvoelker has joined #openstack-keystone04:16
*** markvoelker has quit IRC04:21
*** ngupta has quit IRC04:36
*** ngupta has joined #openstack-keystone04:37
*** nicolasbock has quit IRC04:38
*** ngupta has quit IRC04:41
*** thorst has joined #openstack-keystone04:57
*** thorst has quit IRC05:02
*** guoshan has joined #openstack-keystone05:03
*** guoshan has quit IRC05:08
openstackgerritMerged openstack/keystone master: Revise conf param in releasenotes  https://review.openstack.org/44089405:20
*** nizam037 has joined #openstack-keystone05:37
*** rcernin has joined #openstack-keystone05:39
*** Jack_I has joined #openstack-keystone05:44
*** markvoelker has joined #openstack-keystone05:46
*** adriant has quit IRC05:50
*** markvoelker has quit IRC05:50
*** zsli__ has quit IRC05:58
*** thorst has joined #openstack-keystone05:58
*** zsli__ has joined #openstack-keystone05:59
*** thorst has quit IRC06:03
*** guoshan has joined #openstack-keystone06:03
*** guoshan has quit IRC06:08
*** tovin07 is now known as tovin07_at_work06:08
*** guoshan has joined #openstack-keystone06:10
*** rcernin has quit IRC06:13
*** gyee has quit IRC06:26
*** markvoelker has joined #openstack-keystone06:36
*** richm has quit IRC06:42
*** namnh has quit IRC06:48
*** markvoelker has quit IRC06:49
*** lamt has joined #openstack-keystone06:51
*** h5t4 has joined #openstack-keystone06:52
*** jaosorior has joined #openstack-keystone06:54
*** jaosorior has quit IRC06:54
*** zsli__ has quit IRC06:56
*** zsli__ has joined #openstack-keystone06:57
*** thorst has joined #openstack-keystone06:59
*** bigjools_ is now known as bigjools07:02
*** bigjools has joined #openstack-keystone07:03
*** thorst has quit IRC07:04
*** lamt has quit IRC07:06
*** zsli__ has quit IRC07:08
*** jrist has quit IRC07:10
*** jrist has joined #openstack-keystone07:12
*** namnh has joined #openstack-keystone07:35
*** jaosorior has joined #openstack-keystone07:40
*** tesseract has joined #openstack-keystone07:47
*** pcaruana has joined #openstack-keystone07:50
*** rcernin has joined #openstack-keystone07:55
*** arturb_ has joined #openstack-keystone07:56
*** arturb has quit IRC07:57
*** thorst has joined #openstack-keystone08:00
*** thorst has quit IRC08:04
*** zzzeek has quit IRC09:00
*** thorst has joined #openstack-keystone09:01
*** zzzeek has joined #openstack-keystone09:01
*** thorst has quit IRC09:05
*** liujiong_lj has joined #openstack-keystone09:10
*** liujiong has quit IRC09:11
*** pnavarro has joined #openstack-keystone09:17
*** mvk has quit IRC09:21
*** liujiong_lj is now known as liujiong09:22
*** sigmavirus has quit IRC09:23
*** belmoreira has joined #openstack-keystone09:24
*** woodburn has quit IRC09:25
*** woodburn has joined #openstack-keystone09:25
*** sigmavirus has joined #openstack-keystone09:30
*** sigmavirus is now known as Guest8135009:30
*** d0ugal has quit IRC09:32
*** d0ugal has joined #openstack-keystone09:35
*** jaosorior is now known as jaosorior_brb09:43
*** tovin07_at_work has quit IRC09:46
*** d0ugal has quit IRC09:48
*** d0ugal has joined #openstack-keystone09:50
*** mvk has joined #openstack-keystone09:52
*** thorst has joined #openstack-keystone10:02
*** guoshan has quit IRC10:05
*** links has quit IRC10:05
*** thorst has quit IRC10:06
*** markvoelker has joined #openstack-keystone10:10
*** namnh_ has joined #openstack-keystone10:10
*** namnh has quit IRC10:13
*** namnh_ has quit IRC10:16
*** links has joined #openstack-keystone10:19
*** liujiong has quit IRC10:20
*** mvk has quit IRC10:28
*** openstackgerrit has quit IRC10:33
*** links has quit IRC10:39
*** mvk has joined #openstack-keystone10:41
*** Guest6667 is now known as Guest666610:43
*** links has joined #openstack-keystone10:55
*** thorst has joined #openstack-keystone11:02
*** thorst has quit IRC11:07
*** richm has joined #openstack-keystone11:12
*** jaosorior_brb is now known as jaosorior11:16
*** edmondsw has joined #openstack-keystone11:19
*** nicolasbock has joined #openstack-keystone11:21
*** edmondsw has quit IRC11:23
*** markvoelker has quit IRC11:50
*** thorst has joined #openstack-keystone12:03
*** thorst has quit IRC12:08
*** pnavarro has quit IRC12:14
*** dgonzalez has quit IRC12:22
*** markvoelker has joined #openstack-keystone12:23
*** catintheroof has joined #openstack-keystone12:24
*** thorst has joined #openstack-keystone12:34
*** ngupta has joined #openstack-keystone12:41
*** ngupta has quit IRC12:41
*** ngupta has joined #openstack-keystone12:42
*** erlon has joined #openstack-keystone12:43
*** zhurong has quit IRC12:45
*** dave-mccowan has joined #openstack-keystone12:56
*** edmondsw has joined #openstack-keystone13:00
*** chlong has joined #openstack-keystone13:00
*** edmondsw has quit IRC13:06
*** openstackgerrit has joined #openstack-keystone13:07
openstackgerritSean Dague proposed openstack/keystone-specs master: WIP: block diag quota scenarios  https://review.openstack.org/44120313:07
*** edmondsw has joined #openstack-keystone13:08
*** edmondsw has quit IRC13:12
*** edmondsw has joined #openstack-keystone13:14
*** edmondsw has quit IRC13:14
*** edmondsw has joined #openstack-keystone13:15
openstackgerritSean Dague proposed openstack/keystone-specs master: WIP: block diag quota scenarios  https://review.openstack.org/44120313:15
*** akrzos is now known as guest213:25
*** guest2 is now known as akrzos13:25
edmondswjamielennox I could be wrong but I think the new API guidelines are suggesting some improper service catalog usage13:34
edmondswyou might want to take a look at the comment I dropped in https://review.openstack.org/#/c/421846/613:34
edmondswlbragstad ^13:34
*** zhurong has joined #openstack-keystone13:36
edmondswlbragstad I know you missed the first couple days at the PTG when the API WG was meeting, but they have a decidedly different stance on microversions than keystone is taking, so you might want to read over the rst with that in mind13:38
*** spilla has joined #openstack-keystone13:39
*** links has quit IRC13:51
*** raildo has joined #openstack-keystone13:52
*** pnavarro has joined #openstack-keystone13:53
*** ngupta has quit IRC14:02
*** ngupta has joined #openstack-keystone14:03
*** ngupta has quit IRC14:07
*** Guest81350 is now known as sigmavirus14:08
*** sigmavirus has quit IRC14:09
*** sigmavirus has joined #openstack-keystone14:09
openstackgerritSean Dague proposed openstack/keystone-specs master: WIP: block diag quota scenarios  https://review.openstack.org/44120314:09
*** venki has joined #openstack-keystone14:09
venkii'm getting "An error occurred authenticating. Please try again later."14:10
venkiwhile logging in..14:11
venkii'm using http://paste.openstack.org/show/601761/ local.conf14:12
venkiunable to login in dashboard14:13
venkithese are my credentials14:14
venkihttp://paste.openstack.org/show/601770/14:14
*** lamt has joined #openstack-keystone14:14
venkiAlso when i check the screen(key) service log, it shows this http://paste.openstack.org/show/601771/14:15
openstackgerritDolph Mathews proposed openstack/keystone master: Revert "Handle disk write failure when doing Fernet key rotation"  https://review.openstack.org/44251314:16
*** zhurong has quit IRC14:16
lbragstadedmondsw jamielennox --14:17
lbragstadedmondsw dave-mccowan s/--/__14:18
edmondswlbragstad ?14:18
openstackgerritIan Cordasco proposed openstack/keystoneauth master: Allow new cassettes to be recorded via fixture  https://review.openstack.org/44251614:19
lbragstadedmondsw s/--/++ ;)14:19
dolphmi'm curious if anyone can correct me if i'm wrong on proposing the revert for "Handle disk write failure when doing Fernet key rotation"  https://review.openstack.org/442513 (lbragstad?)14:22
openstackgerritDolph Mathews proposed openstack/keystone master: Revert "Handle disk write failure when doing Fernet key rotation"  https://review.openstack.org/44251314:23
*** jaosorior has quit IRC14:24
lbragstaddolphm checking14:27
*** lamt has quit IRC14:32
*** rderose has joined #openstack-keystone14:36
*** agrebennikov has joined #openstack-keystone14:47
*** ngupta has joined #openstack-keystone14:50
*** jaosorior has joined #openstack-keystone14:51
*** nicolasbock has quit IRC15:03
*** lamt has joined #openstack-keystone15:03
*** pnavarro has quit IRC15:06
*** pcaruana has quit IRC15:09
*** lucasxu has joined #openstack-keystone15:11
openstackgerritDolph Mathews proposed openstack/keystone master: Test for fernet rotation recovery after disk full  https://review.openstack.org/44255415:18
*** pcaruana has joined #openstack-keystone15:23
*** ravelar has joined #openstack-keystone15:23
*** dgonzalez has joined #openstack-keystone15:24
*** phalmos has joined #openstack-keystone15:29
dstanekdolphm: lol15:30
dstanek"if my server is on fire keystone should still validate tokens"15:31
lbragstaddstanek all the uptime15:31
dolphmdstanek: new project tag, zero-downtime-during-apocalypse15:32
dolphmas usual, testing will be the hard part15:33
dstanekwe will service all requests until the hard driver melts away15:35
dstanekthat would be a cool tag though...you should propose it15:36
dstanekdolphm: in all seriousness. can't rotate just delete the broken stage key it if fails to write content to it?15:37
dstaneki'm not sure what that "fix" does after a quick skim15:37
knikollao/15:39
*** phalmos has quit IRC15:41
dolphmdstanek: probably, but it could be loaded in the mean time15:42
dolphmdstanek: i'm tempted to try to simplify the patch15:42
lbragstaddolphm you had some comments on https://review.openstack.org/#/c/439400/15:42
lbragstaddolphm it looks like you made those comments before you abandon the revert, do they still apply?15:43
*** phalmos has joined #openstack-keystone15:43
dolphmlbragstad: i'll amend which are applicable15:44
lbragstaddolphm ok - cool15:44
lbragstaddolphm just checking15:44
dolphmlbragstad: looks like just one comment was wrong15:45
*** aasthad has joined #openstack-keystone15:45
*** adrian_otto has joined #openstack-keystone15:46
*** lamt has quit IRC15:50
openstackgerritGage Hugo proposed openstack/keystone-specs master: Remove pbr warnerrors in favor of sphinx check  https://review.openstack.org/43991415:52
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Add Policy Documentation  https://review.openstack.org/43507815:54
lbragstadantwash ^15:57
*** jdennis has joined #openstack-keystone15:58
*** jdennis1 has quit IRC15:58
*** lamt has joined #openstack-keystone16:00
antwashlbragstad : http://paste.openstack.org/show/601797/16:03
lbragstadantwash ah - yes16:04
lbragstadantwash i completely forgot about the multiple URLs16:04
lbragstadantwash let me spin another update16:04
antwashlbragstad : cool, other than that LGTM :)16:05
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Add Policy Documentation  https://review.openstack.org/43507816:06
lbragstadantwash better ^16:06
antwashlbragstad: ++16:06
antwashthanks lance16:07
*** dave-mccowan has quit IRC16:10
*** dave-mccowan has joined #openstack-keystone16:11
*** chris_hultin|AWA is now known as chris_hultin16:17
*** belmoreira has quit IRC16:22
*** adu has joined #openstack-keystone16:24
*** pcaruana has quit IRC16:26
*** chris_hultin is now known as chris_hultin|AWA16:26
sigmavirusHey all, I'm trying to use ksa's betamax fixture in a newish project and ran into some bugs that are fixed in https://review.openstack.org/#/c/442516/ and https://review.openstack.org/#/c/442536/ ... could some keystone folk review and if possible release those fixes?16:29
*** rcernin has quit IRC16:30
*** markvoelker has quit IRC16:37
*** lucasxu has quit IRC16:38
*** tesseract has quit IRC16:38
openstackgerritAnthony Washington proposed openstack/keystone master: Policy in code (part 4)  https://review.openstack.org/43575516:39
*** lucasxu has joined #openstack-keystone16:40
*** h5t4 has quit IRC16:40
*** adu has left #openstack-keystone16:47
*** nicolasbock has joined #openstack-keystone16:52
*** chris_hultin|AWA is now known as chris_hultin16:57
*** ngupta has quit IRC17:06
*** ngupta has joined #openstack-keystone17:07
*** knangia has joined #openstack-keystone17:09
*** ngupta has quit IRC17:10
*** ngupta has joined #openstack-keystone17:10
*** markvoelker has joined #openstack-keystone17:12
*** agrebennikov has quit IRC17:14
openstackgerritAnthony Washington proposed openstack/keystone master: Policy in code (part 4)  https://review.openstack.org/43575517:15
*** lucasxu has quit IRC17:16
*** phalmos has quit IRC17:16
*** phalmos has joined #openstack-keystone17:25
*** henrynash has joined #openstack-keystone17:25
*** Jack_V has joined #openstack-keystone17:25
openstackgerritMorgan Fainberg proposed openstack/keystone master: Support new hashing algorithms for securely storing password hashes  https://review.openstack.org/43870117:26
*** agrebennikov has joined #openstack-keystone17:27
*** Jack_V has quit IRC17:28
notmorgansigmavirus: +2/+A on both17:29
*** Jack_I has quit IRC17:29
notmorgansigmavirus: now... you'll need to bug lbragstad to do a release.17:29
*** Jack_I has joined #openstack-keystone17:29
sigmavirusnotmorgan: y'all don't have a release CPL?17:29
sigmavirus=P17:29
notmorganno idea who it is if we do17:29
sigmavirusAlso, thank you notmorgan17:29
* notmorgan stays out of release stuff.17:29
*** MasterOfBugs has joined #openstack-keystone17:30
*** pramodrj07 has joined #openstack-keystone17:30
*** jaosorior has quit IRC17:30
lbragstadsigmavirus nice - i'll review thsoe17:30
*** lucasxu has joined #openstack-keystone17:31
notmorganlbragstad: thye were super straightforward and mordred already +2'd them. so +2/+A now :)17:31
sigmavirusIt's nice that working on betamax is so easy =P17:31
lbragstadsigmavirus notmorgan yeah - we haven't released ksa in about 3 weeks, so doing a release for pike wouldn't be a bad idea17:32
notmorgansigmavirus: lol. more that KSA as long as you're not doing insane things in the requests parts is only a minor headache vs a major headache (not the requests part, the ksa on top of requests part)17:33
notmorganand betamax plugs in nicely17:33
sigmavirusnotmorgan: we're not17:33
sigmavirusWe just have a custom auth plugin because the project doesn't want to tie itself to keystone because it's supposed to be sort of under the cloud17:34
sigmavirusalthough interested parties what a keystone UI plugin so it needs keystone integration17:34
notmorgansigmavirus: oh neat. so KSA is providing something useful outside of keystone?17:34
sigmavirusmakes my life easier for just using ksa's Betamax fixture17:34
sigmavirusnotmorgan: yes17:34
notmorgani.. wow17:34
notmorganthat makes me happy17:34
sigmavirusthe auth plugin for it is nice and simple17:34
sigmavirusMade my life easier in being able to implement the auth nonsense so we can always use ksa and have keystonemiddleware on the server was super easy to17:35
sigmavirus*too17:35
notmorgani've long considered yanking parts of that out of KSA and seeing if we could release something more in line with requests as a generic thing17:35
sigmavirusnotmorgan: I think it works well at the moment as is17:35
notmorgannot just for openstack that is.17:35
sigmavirusthen again, I followed ksa development for a whlie when it started so I suspect it making sense to me is only due to that17:35
notmorganeh, KSA would be a lot better if two things happened17:36
* sigmavirus nods17:36
sigmaviruspydocstyle is starting to adopt Flake8 3.x's noqa syntax and now I'm pondering pulling that out into a tiny library17:36
notmorgan1) we didn't raise on non-200s17:36
notmorganand 2) if we could have wedged more into the adapter (some limitations there) instead of needing to wrap all of requests into the session17:36
*** henrynash has quit IRC17:37
sigmavirusoh, don't get me wrong, I'm not a fan of the "Adapter" in ksa17:37
sigmavirusbut that's just me17:37
notmorgani wish all of ksa was just a requests adapter17:37
notmorganso "use requests, and mount adapter"17:37
sigmavirusNot sure that'd work as well17:38
notmorganit wouldn't17:38
sigmavirusRequests does a lot at the session level17:38
sigmavirusand a lot of other stuff at the transport level17:38
notmorganthat is why we couldn't do it17:38
sigmavirusyeah17:38
*** prashkre has joined #openstack-keystone17:38
sigmavirushttps://github.com/openstack/python-cratonclient/blob/master/cratonclient/auth.py#L169 is what we're using ksa with (when not using keystone)17:38
notmorganit still doesn't make me wish that was the interface we could have used.17:38
notmorganyeah the more i think about it the more keystoneauth's interface lets us just in-line auth with simple plugins.17:39
notmorganit does make some openstack-y assumptions, but not a ton.17:39
notmorganglad it's helping you out :)17:40
*** erhudy has joined #openstack-keystone17:42
sigmavirusWas told "Hop on this project and make it use keystone for auth when configured... oh and make the client sensible please"17:42
notmorganheh17:45
notmorganlbragstad: the schedule for this weeks meeting looks a lot like last weeks?17:48
notmorganoh nope17:48
lbragstadnotmorgan yeah - there were some carry over topics17:48
notmorganwas a stale etherpad17:48
notmorganit was identical... then i saw my browser say "disconnected"17:48
notmorgansooo yeah17:48
*** david-lyle_ has joined #openstack-keystone17:52
*** david-lyle has quit IRC17:54
*** david-lyle_ is now known as david-lyle17:55
*** links has joined #openstack-keystone18:01
*** david-lyle has quit IRC18:04
*** david-lyle has joined #openstack-keystone18:05
*** _cjones_ has joined #openstack-keystone18:06
*** _cjones_ has quit IRC18:15
*** _cjones_ has joined #openstack-keystone18:20
*** david-lyle has quit IRC18:23
*** david-lyle has joined #openstack-keystone18:25
*** phalmos has quit IRC18:27
*** raildo has quit IRC18:29
*** david-lyle has quit IRC18:29
*** raildo has joined #openstack-keystone18:35
*** david-lyle has joined #openstack-keystone18:36
*** mvk has quit IRC18:36
*** phalmos has joined #openstack-keystone18:44
*** h5t4 has joined #openstack-keystone18:45
*** arunkant has quit IRC18:45
openstackgerritMerged openstack/keystoneauth master: Allow new cassettes to be recorded via fixture  https://review.openstack.org/44251618:49
*** ngupta has quit IRC18:53
*** ngupta has joined #openstack-keystone18:53
*** ngupta has quit IRC18:55
*** ngupta has joined #openstack-keystone18:55
*** ayoung has joined #openstack-keystone19:00
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Remove policy default spec  https://review.openstack.org/44268619:01
lbragstadcc ayoung ^19:03
notmorganlbragstad: +2/+A already19:03
notmorganbecause meeting convo19:03
lbragstadnotmorgan awesome - thanks19:03
lbragstadwfm19:04
ayoung+2A19:04
*** david-lyle has quit IRC19:04
lbragstadgagehugo knikolla i've updated https://etherpad.openstack.org/p/keystone-weekly-meeting with next week's agenda I have you two up first19:06
*** david-lyle has joined #openstack-keystone19:06
lbragstadgagehugo knikolla if you don't have anything by next week, that's totally fine.. I just want to make sure you have dedicated time to ask for help or reviews if you need them19:06
gagehugolbragstad: sounds good, thanks19:07
lbragstadgagehugo no problem - let me know if there's anything else you need19:07
*** mvk has joined #openstack-keystone19:07
gagehugowill do19:08
openstackgerritLance Bragstad proposed openstack/keystone master: Add in-code comment to clarify pattern in tests  https://review.openstack.org/44118719:10
openstackgerritMerged openstack/keystone-specs master: Remove policy default spec  https://review.openstack.org/44268619:44
sigmaviruslbragstad: you haven't started the release process for ksa, right?19:55
lbragstadsigmavirus https://review.openstack.org/#/c/442536/ hasn't merged yet - so i haven't proposed a new release yet19:55
lbragstadsigmavirus you need something else included?19:56
sigmavirusi think I have another bug19:56
sigmavirus=/19:56
sigmavirusI need to figure that out first =)19:56
lbragstad\o/19:56
lbragstadsigmavirus ok19:56
*** lucasxu has quit IRC19:57
knikollalbragstad: ack20:02
*** lucasxu has joined #openstack-keystone20:04
*** links has quit IRC20:09
lbragstadif anyone is looking for some quick reviews - these should be trivial20:12
lbragstadhttps://review.openstack.org/#/c/439194/20:12
lbragstadhttps://review.openstack.org/#/c/439208/20:12
lbragstadhttps://review.openstack.org/#/c/439205/20:12
lbragstadhttps://review.openstack.org/#/c/435078/20:13
*** simondodsley has joined #openstack-keystone20:13
*** ayoung has quit IRC20:16
*** agrebennikov has quit IRC20:17
*** agrebennikov has joined #openstack-keystone20:18
lbragstadthis looks ready to go - https://review.openstack.org/#/c/43560920:25
*** _cjones_ has quit IRC20:27
*** phalmos has quit IRC20:37
*** pnavarro has joined #openstack-keystone20:38
openstackgerritMerged openstack/keystone-specs master: Remove the fernet key store spec from backlog  https://review.openstack.org/43919420:38
openstackgerritMerged openstack/keystone-specs master: Remove centralized policies fetch cache spec  https://review.openstack.org/43920820:39
openstackgerritMerged openstack/keystone-specs master: Clarify bits of the alembic backlogged spec  https://review.openstack.org/43920520:39
spillalbragstad: think this is good to close? talked to stevemar a while back but we didn't reach a conclusion https://bugs.launchpad.net/keystone/+bug/164591020:40
openstackLaunchpad bug 1645910 in OpenStack Identity (keystone) "Trust creation for SSO users fails in assert_user_enabled" [Medium,In progress] - Assigned to Samuel Pilla (samuel.pilla)20:40
lbragstadspilla checking20:41
*** h5t4 has quit IRC20:41
lbragstadspilla ah - yeah.. that would make sense with all federated users now having a domain_id20:42
lbragstadspilla I can update20:42
spillalbragstad okay, thanks! :)20:42
*** raildo has quit IRC20:45
*** prashkre has quit IRC20:55
*** jaugustine has joined #openstack-keystone20:58
*** Jack_I has quit IRC21:02
lbragstadravelar so what was the deal with https://review.openstack.org/#/c/427018/5 ?21:03
lbragstadcc dstanek rderose ^21:03
dstanekravelar: so while technically that's correct. the fact responses can differ so wildly may be a sign of a problem21:03
lbragstadwe're adding attributes to the api in specific cases, but I don't think that qualifies as breaking the api21:04
ravelardstanek differ wildly?21:04
ravelardstanek just need clarification cause its a single attribute so I am confused21:05
rderoseyeah, it's pretty consistent21:05
ravelarits always added21:05
rderosethere is only a difference between list and get21:05
dstaneki mean different between deployments21:05
ravelarThere are only two possible outcomes. The user either had federated objects, so federated now has a list of those objects21:06
ravelaror there weren't any, in which case federated is an empty list21:06
*** ngupta_ has joined #openstack-keystone21:06
dstanekok, let's come at it from this angle. are we doing to add an ldap list?21:07
lbragstaddstanek adding an 'ldap' list to the user entity that contains ldap information?21:07
rderosefor ldap/local list we are not returning a federated object21:08
rderoseonly for get21:08
ravelaryeah I am thinking about it like lbragstad so again confused21:08
rderoselbragstad: ?21:08
dstaneklbragstad:  yes21:09
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements  https://review.openstack.org/43931721:09
*** ngupta has quit IRC21:10
dstanekit's too late now since it's published. i think we just need to be more careful abeout adding things to the api like that21:10
*** ngupta_ has quit IRC21:11
lbragstadrderose so with ravelar's work, we are adding a 'federated' section to the user reference, dstanek was asking if we were planning on doing the same for 'ldap'21:11
dstanekalso do we a have the ability to have multiple federated objects?21:12
rderosedstanek: yes21:12
rderosethe federated object is a list21:12
rderoselbragstad: yes, so if you are identity backend is ldap, the federated object would be included for a get api call21:13
dstanekrderose: with ldap information?21:13
rderosedstanek: the user object would be pulled from the ldap driver, so yes21:14
rderosedstanek: we just tack on the federated part21:14
dstanekwhat does the ldap object look like?21:14
rderosedstanek: which because we don't support account linking, the federated object would be an empty list21:14
rderosedstanek: it look the same as it does today, except it would have an extra federated attribute21:15
lbragstadwe include it but we don't populate it21:15
rderoselbragstad: we call the shadow backend, so if there is federated data we'll populate it21:15
ravelarwe simply don't populate the federated attribute to display back to the user that there isn't any federated objects associated with the user21:15
rderosebut again, not possible without accounting linking21:16
dstanekrderose: no, i mean in the same way that we tack on an extra thing for federated attributes will we do that for ldap attributes?21:16
rderosedstanek: no, it's not the same.  we essentially call the backend driver in core to get the ldap user and then tack on the federated object21:17
lbragstadbut we hardcode it so that it's empty21:17
rderoselbragstad: no, not hardcoding21:17
dstanekthat's partly my point. i'm disappointed that it's different21:17
rderosedstanek: how is it different21:18
dstanekwe have embeded a key for a very spedific type of user in the user object21:19
dstaneki don't see the advantage of doing that21:19
rderosedstanek: no, that's not the case21:19
rderosedstanek: unless I'm misunderstanding you21:20
rderoselbragstad: https://review.openstack.org/#/c/426449/31/keystone/identity/core.py21:20
dstanekrderose: what is the advantage of putting it in the user over using federation specific api?21:20
rderoselbragstad: line 99521:20
rderoselbragstad: nothing hardcoded21:21
lbragstadrderose right - ok21:21
lbragstadrderose but that will only be populated for federated cases because it's relying on the shadow user api21:21
rderosedstanek: account linking, it's federated attributes can be thought of as user attributes21:22
rderoselbragstad: any federated attributes that were created for that user21:22
rderoselbragstad: so when you create a user, you can add the federated object21:23
lbragstadyep21:23
rderosedstanek: and I think the rationale is that a federated user is a user21:23
dstanekrderose: i see if differently. if you want to know about federated attributes i'd have a different place for you to go21:24
rderosedstanek: yeah, that was ayoung original thought I think, but not what we described in the spec21:24
*** phalmos has joined #openstack-keystone21:24
rderosedstanek: https://github.com/openstack/keystone-specs/blob/master/specs/keystone/pike/support-federated-attr.rst21:25
dstanekrderose: i with i had paid more attention to that spec :-(  we need to be careful when adding stuff to the existing objects.21:25
dstanekwe need to have good usecases behind api changes21:26
rderosedstanek: sure21:27
rderosedstanek: and I think we do for this21:27
dstanekugg...i really don't like the unique_id filter since that isn't really a part of the user21:28
rderosedstanek: already merged21:28
rderoseit's part of the federated object for that user21:28
dstanekwe don't IMO. there is nothing in that spec that couldn't be solved in federation specific apis21:28
rderosedstanek: that was alternative in the spec21:29
dstanekthis is where i think terminology matters. it is not a part of the user at all it is part of a specify profile.21:29
rderosedstanek: to me it's more intuitive as part of the user api21:29
dstanekthere is a user which has user things. then there is a federated user that has federation things. along with a remote user that has remote user things.21:30
dstanekrderose: but it isn't actually a part of the user. if i don't use federation what is my unique_id?21:30
rderosedstanek: no users are returned21:31
dstanekrderose: no, if i don't use federation what is my unique id?21:31
rderosedstanek: if you don't use federation then you won't create any users with a federated object21:31
rderoseand the federated object would be an empty list21:32
dstanekthe answer i was looking for is that i don't have a unique id21:32
dstanekwhich is correct right?21:32
rderoseindicating that the user doesn't any federated attributes21:32
*** ayoung has joined #openstack-keystone21:32
dstanekthat asymmetry is what i don't like21:33
*** ayoung has quit IRC21:34
openstackgerritMerged openstack/keystoneauth master: Allow users to specify a serializer easily  https://review.openstack.org/44253621:36
*** ayoung has joined #openstack-keystone21:37
rderosedstanek: I sort of see your point, but again, to me the user api is a natural place for this. whether creating a local user or a federated user, I should be able to use the user api.21:37
rderosedstanek: and the spec was approved21:38
dstanekyes, unfortunately that's true21:39
rderose:)21:39
dstanekthat's what i said earlier. we can't do much about it now, but we should learn from it and make sure we're more deliberate next time21:39
openstackgerritOpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements  https://review.openstack.org/43931721:39
dstanekthe warning though is that people may call us on it and ask us why21:40
rderosedstanek: I don't know much more deliberate I could have been in that spec21:40
rderoseits'21:40
rderose*it clearly shows as being part of the user object21:40
dstanekthat's not what i mean. every api change should go through some extra scrutiny.21:41
*** frontrunner has joined #openstack-keystone21:41
rderosedstanek: ok21:41
dstaneki mean 'we should be more deliberate in our api design' - otherwise we will end up needing microversions21:41
rderosedstanek: agree21:42
rderoselbragstad: this is how you would do account linking with an ldap user:21:42
rderosePUT /v3/users/{id}21:42
rderose{21:42
rderose    "federated": {21:42
rderose        "idp_id": "1789d1",21:42
rderose        "protocols": [21:42
rderose            {21:42
rderose                "protocol_id": "saml2",21:42
rderose                "unique_id": "jdoe"21:42
rderose            }21:42
rderose        ]21:42
rderose    }21:42
rderose}21:42
dstanekrderose: this is what paste is for :-)21:42
rderose:) sorry21:43
dstanekput or patch?21:43
rderosedstanek: ah, patch21:43
dstanekor you could have POSTed/PUTed (depending on desired semantics) to OS-FEDERATION/user/{id}21:45
*** MasterOfBugs has quit IRC21:47
*** pramodrj07 has quit IRC21:47
*** MasterOfBugs has joined #openstack-keystone21:47
*** pramodrj07 has joined #openstack-keystone21:47
*** gyee has joined #openstack-keystone21:47
lbragstadrderose would the protocol id be saml2 for account linking ldap users?21:52
*** dave-mcc_ has joined #openstack-keystone21:53
dstaneklbragstad: i don't think you can link ldap users21:54
*** dave-mccowan has quit IRC21:54
rderoselbragstad: could be21:54
dstanekwhen i asked about that earlier the answer hinted that we could link a federated project to an ldap user21:55
rderosedstanek: you can add a federated object to a user21:56
rderosedstanek: that is what I was indicating in the snippet above21:58
rderoselbragstad: the client defines the protocol when creating the idp, so it doesn't have to be saml222:02
*** lucasxu has quit IRC22:02
*** lucasxu has joined #openstack-keystone22:03
rderoselbragstad: and we validate that the idp and protocol exist for write API calls22:03
*** dave-mcc_ has quit IRC22:03
dstanekrderose: i think lbragstad is asking how you add an ldap profile22:06
dstaneki have a sql user and i want to have them login through ldap and have them tied together22:07
rderoselbragstad dstanek: ah, right. we don't have a way to do that.22:07
rderoselbragstad dstanek: and I'm sure there would be a big demand for something like that22:08
dstanekrderose: that's part of why i think we need a larger 'account linking' method and deprecate the one that went in this cycle22:08
rderosemaybe22:09
rderosebut this would allow for a common use case of linking a user to their federated profile22:09
dstanekhave two different ways to do the same thing?22:10
rderosewe may never need to support linking sql to ldap22:10
dstanekrderose: the fact that it wasn't a part of the design considerations is problematic though22:11
dstanekthis is why i commented that we special cased federated users22:11
*** pnavarro has quit IRC22:11
rderosedstanek: I wasn't trying to solve account linking.  but that being said, the data model can certainly support this type of account linking22:11
*** spilla has quit IRC22:11
dstanekrderose: you were though right at least part of it22:12
rderosedstanek: the user response object would just need to change in order to support sql to ldap22:12
dstanekrderose: exactly! moar cruft is what i am afriad of22:12
*** thorst has quit IRC22:12
rderosedstanek: with sql to ldap, what is the user name; if enable in sql but disabled in ldap...22:14
rderosedstanek: and again, I'm not sure we'd ever need/want to support that22:15
rderosedstanek: I think the harder question is what if I have a federated user and a local user and conflicting roles22:15
rderosedstanek: that's what I think we will need to solve with account linking22:16
rderosedstanek: and which user ID are we going to now use...22:16
dstanekrderose: any as long as the original ones are still valid22:17
rderosedstanek: true22:19
dstanekrderose: was there a requirement from somewhere to allow operators to add federated profiles to existing users?22:21
*** adriant has joined #openstack-keystone22:22
rderosedstanek: it was part of the spec, but it didn't come from an operator22:23
dstanekrderose: was anyone asking for it?22:23
rderosedstanek: no22:24
dstanekthat may be the first thing to do for specs. see if we have a business driven usecase. we have a lot of 'it would be cool if's in keystone22:25
rderosedstanek: well, this was part of our effort to make federation a first class citizen22:26
rderosedstanek: but agree in general22:27
rderosethere definitely was feedback around how do I make concrete role assignments if my federated user doesn't exist yet, because they haven't authenticated22:28
rderoseand from a API perspective, I think it would an odd experience to not allow you to create federated objects for existing users22:30
rderose*would be an22:30
*** lucasxu has quit IRC22:36
dstanekrderose: we should probably follow up and see if they'll use it and give us feedback22:37
rderosedstanek: yeah, we should22:39
*** lucasxu has joined #openstack-keystone22:40
*** catintheroof has quit IRC22:41
*** catintheroof has joined #openstack-keystone22:42
*** catintheroof has quit IRC22:47
*** henrynash has joined #openstack-keystone22:55
*** henrynash has quit IRC23:01
openstackgerritAnthony Washington proposed openstack/keystone master: Policy in code  https://review.openstack.org/43560923:02
*** erlon has quit IRC23:05
*** phalmos has quit IRC23:10
*** lucasxu has quit IRC23:12
*** edmondsw has quit IRC23:16
*** lamt has quit IRC23:23
*** rvba has quit IRC23:24
*** rvba has joined #openstack-keystone23:25
*** rvba has quit IRC23:25
*** rvba has joined #openstack-keystone23:25
notmorganrderose: enabled/disabled is simple.23:30
notmorganrderose: Enabled/Disabled in SQL is an override regardless of other settings.23:30
notmorganredrobot: LDAP is used to check enabled/disabled if SQL is enabled (default). - only in the case of multiple account linkings (such as OIDC)23:30
notmorganrderose: ^ not redrobot23:30
* redrobot pokes head in23:31
*** jaugustine has quit IRC23:31
notmorganredrobot: sorry ;)23:31
*** catintheroof has joined #openstack-keystone23:32
notmorganrderose: so basically (SQL if > 1 link) OR (SQL if not LDAP)23:32
notmorganrderose: we could rely on LDAP in the case of LDAP + Federated23:32
*** rvba has quit IRC23:32
notmorganrderose: so revised ---  SQL unless LDAP "Remote" exists. If LDAP "remote" then LDAP. Federated relies on LDAP or SQL for "enabled"23:33
notmorgan?23:33
*** rvba has joined #openstack-keystone23:39
*** rvba has quit IRC23:39
*** rvba has joined #openstack-keystone23:39
*** chris_hultin is now known as chris_hultin|AWA23:40
*** ravelar has quit IRC23:40
*** thorst has joined #openstack-keystone23:45
adriantnotmorgan, Hey, been meaning to update you on MFA things in keystoneauth. I've been looking at it. I'm hoping to dedicate a few days to it later this month.23:46
*** adrian_otto has quit IRC23:52
*** edmondsw has joined #openstack-keystone23:52
*** thorst has joined #openstack-keystone23:55
*** edmondsw has quit IRC23:56

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