Wednesday, 2017-02-15

*** ChanServ sets mode: +o stevemar00:00
*** thorst_ has joined #openstack-keystone00:02
*** jamielennox_ has joined #openstack-keystone00:02
*** thorst_ has quit IRC00:02
*** ngupta has quit IRC00:02
*** jamielennox_ is now known as jamielennox00:06
*** ChanServ sets mode: +v jamielennox00:06
*** hyakuhei has joined #openstack-keystone00:06
*** lamt has quit IRC00:08
*** rm_work| is now known as rm_work00:11
*** rm_work has joined #openstack-keystone00:11
*** martinlopes has joined #openstack-keystone00:22
*** catintheroof has quit IRC00:29
*** esp has joined #openstack-keystone00:33
*** esp has quit IRC00:40
*** Guest3904 is now known as medberry00:43
*** medberry has quit IRC00:43
*** medberry has joined #openstack-keystone00:43
*** medberry is now known as med_00:43
*** tovin07_ has quit IRC00:46
*** bkudryavtsev has joined #openstack-keystone00:53
*** hoangcx has joined #openstack-keystone01:05
*** guoshan has joined #openstack-keystone01:06
*** thorst_ has joined #openstack-keystone01:10
*** thorst_ has quit IRC01:10
*** thiagolib has joined #openstack-keystone01:11
*** martinlopes has quit IRC01:13
*** lucasxu has joined #openstack-keystone01:21
*** liujiong has joined #openstack-keystone01:23
*** MasterOfBugs has quit IRC01:26
openstackgerritOpenStack Proposal Bot proposed openstack/python-keystoneclient master: Updated from global requirements  https://review.openstack.org/43190001:35
*** tovin07 has joined #openstack-keystone01:41
*** thorst_ has joined #openstack-keystone01:44
*** liujiong has quit IRC01:51
*** liujiong has joined #openstack-keystone01:51
*** thorst_ has quit IRC02:03
*** bkudryavtsev has quit IRC02:20
*** thorst_ has joined #openstack-keystone02:24
*** lucasxu has quit IRC02:25
*** thorst_ has joined #openstack-keystone02:25
*** thorst_ has quit IRC02:29
*** ngupta has joined #openstack-keystone02:30
*** thorst_ has joined #openstack-keystone02:31
*** thorst_ has quit IRC02:36
*** browne1 has quit IRC02:39
*** tqtran has quit IRC02:45
*** dikonoor has joined #openstack-keystone02:56
*** ravelar1 has joined #openstack-keystone03:01
*** edmondsw has joined #openstack-keystone03:02
*** markvoelker_ has joined #openstack-keystone03:02
*** edmondsw has quit IRC03:02
*** edmondsw has joined #openstack-keystone03:03
*** esp_ has joined #openstack-keystone03:03
*** ngupta_ has joined #openstack-keystone03:03
*** waj334_ has joined #openstack-keystone03:04
*** robcresswell_ has joined #openstack-keystone03:04
*** boris-42_ has joined #openstack-keystone03:04
*** nikhil_ has joined #openstack-keystone03:05
*** nikhil_ is now known as Guest1620003:05
*** tonyb_ has joined #openstack-keystone03:06
*** serverascode_ has joined #openstack-keystone03:06
*** dmellado_ has joined #openstack-keystone03:06
*** _d34dh0r53_ has joined #openstack-keystone03:06
*** sudorandom_ has joined #openstack-keystone03:06
*** edmondsw has quit IRC03:07
*** martinus__ has quit IRC03:07
*** nikhil has quit IRC03:07
*** sudorandom has quit IRC03:07
*** dmellado has quit IRC03:07
*** david_cu has quit IRC03:07
*** waj334 has quit IRC03:07
*** serverascode has quit IRC03:07
*** Tahvok has quit IRC03:07
*** markvoelker has quit IRC03:07
*** boris-42 has quit IRC03:07
*** Mech422 has quit IRC03:07
*** ngupta has quit IRC03:07
*** ravelar has quit IRC03:07
*** tonyb has quit IRC03:07
*** robcresswell has quit IRC03:07
*** lbragstad has quit IRC03:07
*** d34dh0r53 has quit IRC03:07
*** Mech422 has joined #openstack-keystone03:07
*** sudorandom_ is now known as sudorandom03:07
*** martinus- has joined #openstack-keystone03:07
*** waj334_ is now known as waj33403:07
*** Tahvok has joined #openstack-keystone03:08
*** lbragstad has joined #openstack-keystone03:08
*** ChanServ sets mode: +v lbragstad03:08
*** robcresswell_ is now known as robcresswell03:09
*** Guest16200 is now known as nikhil03:09
*** thorst_ has joined #openstack-keystone03:10
*** thorst_ has quit IRC03:11
*** aasthad has quit IRC03:13
*** serverascode_ is now known as serverascode03:18
*** jaosorior has joined #openstack-keystone03:19
*** tonyb_ is now known as tonyb03:21
*** esp_ has quit IRC03:31
*** ngupta_ has quit IRC03:37
*** thorst_ has joined #openstack-keystone03:37
*** thorst_ has quit IRC03:37
*** ngupta has joined #openstack-keystone03:37
*** ngupta has quit IRC03:41
*** dikonoor has quit IRC03:43
*** guoshan has quit IRC03:59
openstackgerritMerged openstack/python-keystoneclient master: Updated from global requirements  https://review.openstack.org/43190004:00
*** ngupta has joined #openstack-keystone04:01
*** nicolasbock has quit IRC04:06
*** thiagolib has quit IRC04:11
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Policy in code  https://review.openstack.org/42845304:21
lbragstadravelar1 rderose ^ comments have been addressed - thanks for the reviews!04:21
ravelar1lbragstad just a small typo where you made the change lol04:28
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Define a richer policy by default  https://review.openstack.org/42845404:31
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Policy in code  https://review.openstack.org/42845304:31
lbragstadravelar1 ah - nice catch! done ^04:31
*** links has joined #openstack-keystone04:34
lbragstadravelar1 johnthetubaguy has proposed a couple specs the build on the work we were talking about earlier today - https://review.openstack.org/#/c/433010/504:36
*** thorst_ has joined #openstack-keystone04:38
*** lucasxu has joined #openstack-keystone04:39
lbragstads/the/that/04:40
*** thorst_ has quit IRC04:43
*** guoshan has joined #openstack-keystone04:50
ravelar1lbragstad ha no problem it is late. And sweet, saved to book mark to discuss with anthony04:52
*** rdo has quit IRC04:53
lbragstadravelar1 awesome - just fyi but those are the next steps nova is vetting for their policy story04:53
*** wllabs has joined #openstack-keystone04:54
wllabshello, everybody.04:54
*** nkinder has joined #openstack-keystone05:02
*** adriant has quit IRC05:07
*** guoshan has quit IRC05:29
*** v1k0d3n has quit IRC05:31
*** guoshan has joined #openstack-keystone05:44
*** tqtran has joined #openstack-keystone05:44
*** tqtran has quit IRC05:49
*** gyee has quit IRC05:58
*** dikonoor has joined #openstack-keystone06:03
*** lucasxu has quit IRC06:16
*** pcaruana has joined #openstack-keystone06:20
*** rdo has joined #openstack-keystone06:25
*** ngupta has quit IRC06:33
*** ngupta has joined #openstack-keystone06:33
*** ngupta has quit IRC06:38
*** ravelar1 has quit IRC06:39
*** thorst_ has joined #openstack-keystone06:39
*** wllabs has quit IRC06:42
*** wllabs has joined #openstack-keystone06:43
*** richm has quit IRC06:43
*** thorst_ has quit IRC06:43
*** rcernin has joined #openstack-keystone07:07
*** tesseract has joined #openstack-keystone07:31
*** tqtran has joined #openstack-keystone07:46
*** tqtran has quit IRC07:50
*** masterjcool has quit IRC08:00
*** masterjcool has joined #openstack-keystone08:12
*** links has quit IRC08:36
*** thorst_ has joined #openstack-keystone08:40
*** thorst_ has quit IRC08:44
*** links has joined #openstack-keystone08:53
*** zzzeek has quit IRC09:00
*** zzzeek has joined #openstack-keystone09:00
*** cmurphy has quit IRC09:16
*** cmurphy has joined #openstack-keystone09:16
*** links has quit IRC09:26
*** links has joined #openstack-keystone09:43
*** mdavidson has joined #openstack-keystone09:54
*** hyakuhei has quit IRC10:01
*** hyakuhei has joined #openstack-keystone10:01
*** hyakuhei has quit IRC10:01
*** hyakuhei has joined #openstack-keystone10:01
*** guoshan has quit IRC10:10
*** liujiong has quit IRC10:21
*** hoangcx has quit IRC10:39
*** thorst_ has joined #openstack-keystone10:41
*** mvk has quit IRC10:43
*** thorst_ has quit IRC10:46
*** nicolasbock has joined #openstack-keystone11:02
*** richm has joined #openstack-keystone11:14
bretonlbragstad: any followup on https://review.openstack.org/#/c/429047/ ?11:15
*** mvk has joined #openstack-keystone11:15
*** edmondsw has joined #openstack-keystone11:28
*** edmondsw has quit IRC11:32
*** v1k0d3n has joined #openstack-keystone11:32
*** thiagolib has joined #openstack-keystone11:57
*** raildo has joined #openstack-keystone12:02
*** catintheroof has joined #openstack-keystone12:36
*** thorst_ has joined #openstack-keystone12:38
*** edmondsw has joined #openstack-keystone13:23
*** prashkre has joined #openstack-keystone13:23
*** edmondsw has quit IRC13:25
*** edmondsw has joined #openstack-keystone13:25
*** lamt has joined #openstack-keystone13:45
*** lamt has quit IRC13:49
*** spilla has joined #openstack-keystone13:57
robcresswelllbragstad: I'll be around today till about 2100 UTC if you want to talk PTG14:07
lbragstadrobcresswell I'm assuming we're going to do a cross-project session for horizon and keystone, are there any times that you've already committed to?14:12
*** lamt has joined #openstack-keystone14:20
robcresswelllbragstad: Our schedule is pretty open14:21
robcresswelllbragstad: (sorry, had a meeting just then)14:21
robcresswelllbragstad: I haven't assigned times to anything yet, so we can work around Keystone happily.14:22
*** jperry has joined #openstack-keystone14:24
lbragstadrobcresswell awesome - wanna shoot for an hour on wednesday afternoon?14:24
*** mvk has quit IRC14:25
lbragstadrobcresswell and do you think there will be more or less than 20 people in attendance?14:25
robcresswelllbragstad: Oh interesting, I assumed keystone would be a horizontal. So we're Mon/Tue.14:25
robcresswelllbragstad: Less then 20.14:25
lbragstadrobcresswell do you know if there is going to be anyone around from horizon on wednesday?14:26
lbragstadall keystone tracks are wednesday - friday?14:26
lbragstads/?//14:27
robcresswelllbragstad: I don't know the status of the others, but I'll be around. I would imagine david-lyle will be too.14:27
*** dmellado_ is now known as dmellado14:27
robcresswelllbragstad: btw whats your tz? I forgot :/14:28
lbragstadUTC -614:28
lbragstador Central Standard Time14:28
lbragstadrobcresswell I know most the keystone folks are getting in late tuesday or early wednesday, should we still plan on having something on wednesday afternoon in hopes there will at least be a couple horizon folks around?14:29
*** Krenair has quit IRC14:30
*** links has quit IRC14:31
robcresswelllbragstad: Yeah sure14:31
*** lamt has quit IRC14:32
lbragstadrobcresswell sweet I have it on the schedule from 2:30 - 3:30 on Wednesday in Savannah14:32
robcresswelllbragstad: Sounds good14:33
bretonlbragstad: we should also talk to Heat about the issue with trusts btw14:36
bretonlbragstad: any idea when?14:36
* breton missed all ptg planning14:36
*** Krenair has joined #openstack-keystone14:37
*** chlong has quit IRC14:37
lbragstadbreton yeah - i have that listed as one of our topics14:38
lbragstadbreton i think i have that tentatively scheduled for thursday afternoon14:39
lbragstadricolin has been contacting me about it14:39
*** mvk has joined #openstack-keystone14:39
dstaneklbragstad: i just responded to a ML thread about bringing back PKI tokens14:45
lbragstaddstanek nice - i was just about to start drafting something14:45
lbragstaddstanek i wanted to ask a bit more about their caching setup14:45
lbragstaddstanek and how large their catalog was14:46
dstaneklbragstad: the test uses nocatalog14:47
*** lamt has joined #openstack-keystone14:49
lbragstaddstanek do you happen to remember all the caching issues we fixed as a result of fernet?14:52
*** lamt has quit IRC14:56
*** lamt has joined #openstack-keystone14:56
*** lucasxu has joined #openstack-keystone14:57
*** adrian_otto has joined #openstack-keystone15:00
dstaneklbragstad: nope. did we have issues caching fernet?15:00
lbragstaddstanek not fernet specifically - but caching issues in general15:01
lbragstadfernet just exposed some of those issues15:01
*** chris_hultin|AWA is now known as chris_hultin15:02
*** haplo37_ has quit IRC15:03
*** ngupta has joined #openstack-keystone15:04
*** chris_hultin is now known as chris_hultin|AWA15:04
*** dikonoo has joined #openstack-keystone15:05
*** chris_hultin|AWA is now known as chris_hultin15:06
*** haplo37_ has joined #openstack-keystone15:06
dstaneklbragstad: i don't remember token issues, but that doesn't mean there weren't any over the last year. they are using mitaka to test i think.15:07
*** mvk has quit IRC15:07
lbragstaddstanek yeah - I thought we had some issues somewhere related to caching15:08
* lbragstad has to go dig15:08
*** dikonoor has quit IRC15:08
*** jaosorior has quit IRC15:09
*** jaosorior has joined #openstack-keystone15:10
*** nkinder has quit IRC15:19
*** mvk has joined #openstack-keystone15:19
*** lamt has quit IRC15:23
*** adrian_otto has quit IRC15:27
*** dikonoor has joined #openstack-keystone15:28
*** adrian_otto has joined #openstack-keystone15:28
*** lamt has joined #openstack-keystone15:29
*** dikonoo has quit IRC15:32
*** aasthad has joined #openstack-keystone15:49
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Policy in code  https://review.openstack.org/42845315:50
lbragstadantwash rderose ^15:50
*** ngupta has quit IRC15:51
*** ngupta has joined #openstack-keystone15:52
*** ngupta has quit IRC15:52
*** ngupta has joined #openstack-keystone15:52
*** nkinder has joined #openstack-keystone15:53
lbragstadping antwash, raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar, ravelar, morgan, raj_singh16:01
lbragstadpolicy meeting in #openstack-meeting-cp for those interested!16:01
lbragstadcc johnthetubaguy16:01
*** chlong has joined #openstack-keystone16:04
*** thorst_ has quit IRC16:08
*** mvk has quit IRC16:08
*** thorst_ has joined #openstack-keystone16:09
bretonlbragstad: https://etherpad.openstack.org/p/heat-pike-ptg-sessions16:09
bretonlbragstad: heat plans to have it thursday morning16:09
lbragstadbreton yep - i schedule it with them in their weekly meeting16:09
bretonlbragstad: perfect16:10
*** morgan_ is now known as morgan16:10
*** dikonoor has quit IRC16:10
bretonlbragstad: thanks for doing it, i dropped a ball with it16:11
lbragstadbreton no worries - the scheduling in kinda hectic right now16:11
lbragstadI want to try and have something a little more official (schedule-wise) by the end of the day16:11
*** ravelar has joined #openstack-keystone16:14
*** erhudy has joined #openstack-keystone16:14
*** agrebennikov has joined #openstack-keystone16:15
*** prashkre has quit IRC16:15
openstackgerritayoung proposed openstack/keystone master: Refactor Authorization:  https://review.openstack.org/38716116:19
openstackgerritayoung proposed openstack/keystone master: Refactor is_admin  https://review.openstack.org/38771016:20
openstackgerritayoung proposed openstack/keystone master: Add is_admin_project check to policy.json  https://review.openstack.org/25763616:20
*** agrebennikov has quit IRC16:23
*** browne has joined #openstack-keystone16:34
*** thorst_ has quit IRC16:38
*** adrian_otto has quit IRC16:39
*** rcernin has quit IRC16:43
*** thorst_ has joined #openstack-keystone16:49
*** tqtran has joined #openstack-keystone16:55
*** esp has joined #openstack-keystone16:57
*** tesseract has quit IRC16:58
*** adrian_otto has joined #openstack-keystone16:59
dstanekjohnthetubaguy: does nova have an api implemented for policy discovery?17:04
edmondswdstanek not today17:05
dstanekedmondsw: so as a deployer you still generate a policy file for horizon?17:06
lbragstadto me that sounds like something that will go hand in hand with the capability api17:06
lbragstad(or the capability api could build on it?)17:06
*** ngupta has quit IRC17:06
edmondswdstanek I don't actually use horizon17:06
edmondswbut I would assume so17:06
*** mvk has joined #openstack-keystone17:07
dstaneklbragstad: yep, i'd think so17:07
*** ngupta has joined #openstack-keystone17:07
edmondswlbragstad ++17:07
dstanekedmondsw: yeah, it wasn't immediately obvious is the generate sample config would include overrides or is there was a new way to do that17:08
edmondswdstanek good question... I haven't played with that17:09
dstanekantwash: ravelar: something to look into ^17:10
*** dikonoor has joined #openstack-keystone17:10
*** tqtran has quit IRC17:11
lbragstadlooks like oslopolilcy does all the generation17:11
dstaneklbragstad: is there a new way to include the overrides?17:15
*** d0ugal has quit IRC17:16
* dstanek thinks it's time for lunch17:18
lbragstaddstanek in the policy file?17:18
lbragstaddstanek er - in the generated policy file?17:18
lbragstaddstanek i thought so17:18
lbragstadi'm having trouble finding the nova/oslo command for it though17:19
dstaneklbragstad: same trouble i was having :-)17:19
lbragstadcc johnthetubaguy ? ^17:19
johnthetubaguysorry, which thing you looking for17:20
johnthetubaguydoes https://docs.openstack.org/developer/oslo.policy/usage.html help?17:20
johnthetubaguythe policy file just becomes overrides only17:21
johnthetubaguyso no file at all by default17:21
dstanekjohnthetubaguy: how do you generate a full policy for horizon that has the defaults and overrides?17:21
johnthetubaguywhy does horizon need that?17:22
*** ngupta has quit IRC17:22
*** ngupta has joined #openstack-keystone17:22
johnthetubaguyoslopolicy-policy-generator --namespace nova --output-file policy-merged.yaml17:22
dstanekjohnthetubaguy: i thought we still needed to deploy policy files so i knew how to display stuff17:22
johnthetubaguyI think is what you want17:22
johnthetubaguydstanek: thats news to me, not heard about that17:23
dstanekjohnthetubaguy: cool, thanks. i'll play around with that17:23
johnthetubaguyactually it tweaks a distant memory about what horizon was wanting that for now17:24
*** chlong has quit IRC17:24
dstanekwhen you deploy horizon you had project policy defaults for nova, keystone, glance and others in the conf directory. i had to change the keystone one when i use the cloud policy sample on keystone.17:25
dstanekdavid-lyle: ^ that's still the case right?17:25
johnthetubaguyso if its just the defaults, the generator should give you the default file17:27
johnthetubaguythe merge should let you look at overrides + the defaults in the code17:28
dstanekjohnthetubaguy: from what i understood the policies had to match. so you have you some overrides then they'd have to make it into the horizon copy as well17:28
johnthetubaguyjust reminds me how much we need to get the capabilities API sorted17:28
robcresswelldstanek: Yeah, Horizon still needs updated policy files if you want it to accurately display/hide what a user can do.17:28
dstanek++17:28
johnthetubaguyOK, sounds like you need the merge one then17:28
johnthetubaguy:(17:29
dstanekrobcresswell: thx17:29
johnthetubaguymust get the capabilities API sorted17:29
robcresswellIs there a common policy API or anything yet? My understand was that it didnt exist17:29
dstaneksomething to document as we change policy to be in code17:29
robcresswelljohnthetubaguy: +lots17:29
dstanekrobcresswell: not yet17:29
robcresswellHorizon could drop 3/4 of its config if we had an API to see what User X can or cant do17:30
robcresswellits nearly all just duplication.17:30
*** d0ugal has joined #openstack-keystone17:30
*** d0ugal has quit IRC17:30
*** d0ugal has joined #openstack-keystone17:30
johnthetubaguyrobcresswell: is there a good bit in the horizon code to look for the list of questions you need answering?17:31
*** thiagolib has quit IRC17:31
robcresswelljohnthetubaguy: https://docs.openstack.org/developer/horizon/topics/settings.html#openstack-neutron-network17:32
robcresswelljohnthetubaguy: We have dozens of those kinds of settings17:32
robcresswelljohnthetubaguy: If you just search the settings doc for a service name you'll find a lot of settings that should really be API controlled on login.17:33
robcresswelljohnthetubaguy: Same situation with policy, we just use copies of the files to control what a user can or cant see.17:33
lbragstadravelar antwash this seems like it would be the next logical step after moving policy into code - https://review.openstack.org/#/c/43301017:35
*** jaosorior has quit IRC17:35
* antwash adds link to 1000 tabs opened already haha 17:36
*** nkinder has quit IRC17:37
robcresswelllbragstad: Not just operators, that'd be pretty useful for Horizon too. I dislike digging through service code to find out which policy rules do what :(17:37
lbragstadrobcresswell ++17:38
lbragstadso far, i think regardless of the overall direction we take on policy, we can agree on two things. 1.) move policy into code 2.) provide well written descriptions for each policy, describing *exactly* what it does17:39
* lbragstad shamelessly stole that from johnthetubaguy 17:39
antwashlbragstad : lets use this https://etherpad.openstack.org/p/policy_links :)17:41
lbragstadantwash if that helps you and ravelar stay organized, go for it :)17:42
*** d0ugal has quit IRC17:42
antwashlbragstad : yeah centralized location for a lot of information lol17:42
*** prashkre has joined #openstack-keystone17:43
lbragstadgrabbing lunch17:54
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644917:56
*** dikonoor has quit IRC18:02
*** tqtran has joined #openstack-keystone18:13
*** jamielennox is now known as jamielennox|away18:13
*** spzala has joined #openstack-keystone18:16
*** tqtran has quit IRC18:17
*** adrian_otto has quit IRC18:17
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:17
openstackgerritRichard Avelar proposed openstack/keystone master: Api-refs for extending user api for fed attributes  https://review.openstack.org/42732018:18
*** lucasxu has quit IRC18:20
*** tqtran has joined #openstack-keystone18:31
*** adrian_otto has joined #openstack-keystone18:36
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:37
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:40
*** adrian_otto has quit IRC18:40
*** MasterOfBugs has joined #openstack-keystone18:45
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:55
openstackgerritRon De Rose proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644918:55
*** ravelar has quit IRC18:57
*** pcaruana has quit IRC19:03
*** MasterOfBugs has quit IRC19:07
*** MasterOfBugs has joined #openstack-keystone19:07
*** adrian_otto has joined #openstack-keystone19:08
*** ngupta has quit IRC19:22
*** ngupta has joined #openstack-keystone19:23
*** ngupta has quit IRC19:23
*** ngupta has joined #openstack-keystone19:23
*** chlong has joined #openstack-keystone19:36
*** ravelar has joined #openstack-keystone19:40
lbragstadbreton you wanted to talk about hierarchical quotas, right?19:40
lbragstadbreton fyi - http://lists.openstack.org/pipermail/openstack-dev/2017-February/112277.html19:42
*** chlong has quit IRC19:51
bretoni'd love if morgan or ayoung participate there, as main opposers of my ideas19:53
ayoungbreton, I have no problem with your idea.  I just think it is going to die the way it has every other time19:53
ayoungbreton, what happens is we talk through the issues with the CInder and Nova teams, and they realize that it is not a Keystone issue to solve and the proposal comes off the table19:54
ayoungI've been through it Thrice so far19:54
ayounglast time was Atlanta, IIRC19:55
bretonayoung: i agree. Not a keystone issue at all. I want to move part of the issue to keystone.20:00
bretonayoung: so come join us again in Atlanta :)20:01
morganwait what am i missing?20:04
* morgan context shifts20:05
morganbreton: summary of how far back i should read?20:05
lbragstadgagehugo https://review.openstack.org/#/c/431785/ was the only spec that existed for tags, right?20:05
morganis this re: centralizing policy in keystone again?20:05
morganaka storing policy.json there?20:06
morganayoung: ^ cc20:06
lbragstadgagehugo there isn't another one floating around somewhere that has context in it is there?20:06
gagehugolbragstad not that I'm aware of?20:06
lbragstadgagehugo ok - just double checking20:06
bretonmorgan: quota limits in keystone20:09
morganoh20:09
dstanekmorgan: not that i am aware of right now. policy is going the other way right now :-)20:09
morgandstanek: right, phew20:09
morganso, the biggest concerns with quata limits in keystone are the following:20:09
morgan1: Asking keystone every time for "are we allowed to do this, quota wise", aka, where does this data get stored/communicated to the consuming service?20:10
morgandoes it go in the token body?20:10
morganetc20:10
morganmost services do not *want* to ask keystone yet again for quota data.20:10
dstaneki'd rather have a small lib that uses something like a redis backend20:10
morgan2: is the data stored in keystone for actual consumption or in the consuming service20:10
morgan?20:11
morgani am not opposed to having quota limits set in keystone. i am opposed to creating something no one will use and adding it to our contract20:11
bretonmorgan: limits in token, usages are stored in the services themselves20:11
morganFTR: with the resource-options code, we can easily add this information20:11
morganand i am even less opposed now that we can just define (and validate) the data easily, but not need to expand columns endlessly for it.20:12
morganit's a single migration to add resource options to a resource type, then we define the options.20:13
dstanekbreton: limits in token?20:13
morganif the other projects will consume the limit, i'm happy20:13
bretoncurrent problem is that quotas are a mess20:13
morgandstanek: he's saying add the limit (aka, vm_count) in the token body scope basically20:13
morgandstanek: so the token body would hold quota information20:13
morgandstanek: not what is consumed, but what the limit(s) are20:14
dstanekhow would that actually work? the token would hold all of the limits for the project/domain it is scoped to?20:14
breton4 services with quotas, each with different naming and capabilities20:14
morgandstanek: yep.20:14
dstanek...and every parent above20:14
morgandstanek: not too difficult to do, we already have to resolve that.20:14
morganbecause we have to check "enabled" everywhere20:15
dstanekmorgan: looking up the hierarchy isn't difficult, but the variable amount of quota data feels wrong20:15
dstanekunless you now scope a token to a service (like nova) and we dump all nova's quotas in there20:16
morgannah, we would only show the limit (min) for the whole hierarchy20:16
dstanekthat was you don't also need to include glance's, neutron's, etc.20:16
morganexcept you kindof still do20:16
morganbecause -- yay --- nova talks to glance on your behalf20:17
bretondstanek: otherwise services have to do silly stuff like copying the entire project tree20:17
morgandstanek: i don't feel like quota info on a domain or project as part of the scope (limit data, not actual consumption) is inappropriate20:17
morganit is a value/option for the <resource>20:18
dstanekso in that model every token has to carry a largely static catalog of limits20:18
morgandstanek: well the body20:18
morganit would be a soft store (populated like project data) on validate20:19
morgannot something we add to the payload20:19
dstaneksure, but that's retrieved everytime you use the token20:19
morganright.20:19
morganif it is done in the same manner as the resource_option data, it will be done as a join'd load20:19
morganso, like i said, i'm really not opposed to this as long as the projects agree to consume it.20:21
morgani also can see a relatively easy side-band utility to pull the data into keystone- the only concern is re-training people to put the stuff in keystone vs when they talk to nova... or some kind of proxy (ick)20:22
dstaneki don't really like that model because you have quota defined in keystone, but the actual usage data somewhere else20:23
morgandstanek: quota centralization (for limits) kindof needs to be done somewhere20:24
*** ravelar has quit IRC20:24
morganit does feel like a property of the scope resource20:24
dstanekmorgan: what about the usage of those quotas. is that left to the service itself?20:24
morganit would be.20:25
morganthe service is the only thing that can know what is being used20:25
morganalso the service is responsible for reservation->use->marked-consumed20:25
morgancmurphy: changed your nic on us. :P just noticed.20:26
morgandstanek: we could centralize another way, but like i said, this feels like a keystone[resource-subsystem] thing20:27
morgansince quotas are tied to project/domain info20:27
dstanekthat feels very strange to me.20:27
dstanekeverything is related to a project, but not necessarily to identity20:28
bretonlets break keystone into auth and resource20:28
* breton ducks20:28
morgansince keystone is authortitative to the properties on the project...20:28
morganbreton: *cough* see specs.20:28
morgananyway20:28
morgandstanek: i worry that we have a potential issue with a new service being quota authoritative20:29
morganjust because it requires asking the service about quota each time20:29
morgansimilar issues with a policy service (i don't mean like congress, i mean something storing policy.json)20:29
dstanekif we do anything in keystone land it should be a separate "microservice" like thing that we can easily get rid of20:29
morgandstanek: i think the more important bit would be encoding it in the token or not20:30
morganif it isn't in the token, not really worth centralizing it in keystone20:30
morganif it is, everyone gets the quota information as part of the auth context20:30
morganand it makes sense.20:31
morganmordred: ^ because you have interests in quota-y things20:33
morganmordred: thoughts on centralization of the "limit" (not the consumption) bits20:33
mordreduhoh20:34
* mordred reads20:34
dstanekthe argument for putting it in keystone regardless is that it would be much easier to get it deployed20:34
*** ravelar has joined #openstack-keystone20:34
morganmordred: breton has proposed putting quota information (limit) data in keystone- attached to the resource itself, communicated via the token body20:34
morganaka, vm_limit would be a project-setting20:34
morganconsumption and the like would strill be nova's job20:35
morganjust the limit info could be calculated (inc. heirarchy data) and communicated via the token.20:35
mordredworks for me - BUT ...20:36
mordreda) currently the quotas in most projects are implemented as an unenforced key/value mess that you can think you're raising a quota/limit for a project but you aren't becaues typo20:36
*** jerrygb has joined #openstack-keystone20:36
mordredwe should fix that20:36
*** jamielennox|away is now known as jamielennox20:36
morganmordred: each limit would be validated explicitly on quota-name key and a value that makes sense20:37
morganmordred: the way i see it20:37
mordredbut then you get in to a versioned cross repo schema dance if nova wants to add a new quota/limit key20:37
mordredBUT - I love it20:37
morganmordred: they would need to define a new option20:37
morganno schama change in keystone20:37
bretonthere will be table with keys basically20:37
bretonas i see it20:37
mordredright. but that's what I'm saying is bad20:37
morganthe way i look at doing it, it would use the resource_option code20:37
mordredbecause that's what is it NOW and it's terrible20:37
mordredthere should be a set of keys defined in the API that are part of an api contract20:38
morganwe define an option in code, it is validated20:38
mordredthe keys shoudl not be data20:38
morganand it is part of the api-contract20:38
morganas well as verified on the backend20:38
* mordred hands morgan a pie20:38
morganwe actually generate json-schema20:38
morganfor the options20:38
bretoni would love to talk about it all, but lets talk at the PTG. It's 11:38pm and my brain sleeps20:39
morgananyway. i can support this concept *if* the other projects agree to consume it20:39
dstanekeach service should define it's own keys20:39
morganand we have a path forward to get limit setting from service to keystone.20:39
morganand the other services are ok with cross-repo dance to add new authoritative keys20:40
morganbreton: anyway ^, and sleep well20:41
*** aasthad has quit IRC20:42
dstanekis there already a spec for this?20:42
morgannot that i am aware of20:42
bretondstanek: there is, but in a bad shape20:43
dstanekbreton: fair enough...go get some sleep20:53
-openstackstatus- NOTICE: We're currently battling an increase in log volume which isn't leaving sufficient space for new jobs to upload logs and results in POST_FAILURE in those cases; recheck if necessary but keep spurious rebasing and rechecking to a minimum until we're in the clear.20:56
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644920:59
*** adriant has joined #openstack-keystone20:59
*** raildo has quit IRC21:11
*** aasthad has joined #openstack-keystone21:17
*** ravelar has quit IRC21:19
*** ravelar has joined #openstack-keystone21:19
*** edmondsw has quit IRC21:27
*** edmondsw has joined #openstack-keystone21:33
*** ravelar has quit IRC21:37
*** haplo37_ has quit IRC21:41
*** haplo37_ has joined #openstack-keystone21:41
cmurphymorgan: yeah, felt like the right time for a change21:47
*** ravelar has joined #openstack-keystone21:52
lbragstadmorgan python-memcached lacks py3 support, right?22:01
morganlbragstad: some cases22:01
morganit is supposed to support py3 but it doesn't really22:02
lbragstadmorgan can you give me the two minute version of the biggest pain points we have with python-memcached?22:02
*** Krenair has quit IRC22:02
morganthe maintainer is not active, py3 support is spotty at best22:02
morganlibrary is really poorly designed22:03
morgan(it was fine back in the day, but it really doesn't look like something you'd write now), all functions not really class-based22:03
lbragstadmorgan does the design of the library prevent us from doing specific things?22:03
morganand finally, it explicitly relies on thread.local22:03
morganit makes it hard for us to do thing22:03
morgans22:03
morgannot impossible22:03
morgani would like to drop it on the floor and never look at it again22:04
lbragstadmorgan just looking for a single thing that makes our lives harder22:04
morgani tried to take over the lib multiple times, and the current maintainer is very hard to reach even thogh he agreed to it22:04
morganand since i can't get the LP project and pypi bits put over to me/openstack22:04
morgani can't take it over22:04
lbragstadright22:04
lbragstadthat makes sense22:04
morganso... my new plan: drop it22:04
morgandrop it like it's hot22:04
*** wolsen has quit IRC22:04
lbragstaddumb question time22:04
morganpymemcache is the way to go22:05
lbragstadwhat about thread.local is a problem for us?22:05
morganhaha, it isn't22:05
morganit is a problem for anyone using eventlet22:05
morganwe don't use eventlet so... no issue22:05
morganbut it sucks for keystonemiddleware22:05
lbragstadin services that run in eventlet22:05
jamielennoxwhat sucks for middleware?22:05
morganthread.local allows for the lib to consume all the memcache sockets22:05
morganif a service is hit hard22:05
morganso, you can end up DOSing your memcache server itself22:06
morgansince eventlet creates green threads and each greenthread gets a connection to memcache22:06
morganit's the reason we tried the pool thing, but we're battling python-memcache to patch that out22:06
morganit's all around awful22:06
morganwe should get a pymemcache driver in dogpile22:07
morganand we should make oslo.cache default to that22:07
morganand we should never ever ever use python-memcached22:07
*** chris_hultin is now known as chris_hultin|AWA22:07
morganlbragstad: the other alternative is to fork python-memcached, but kindof feel like pymemcache is so much better why bother22:08
lbragstadmorgan ok - cool22:08
lbragstadmorgan i'm prepopulating an etherpad for the PTG on the topic22:08
morganlbragstad: https://github.com/pinterest/pymemcache22:08
morganalso pinterest folks are smart ;)22:09
lbragstadmorgan would you be interested in driving that discussion22:09
lbragstad?22:09
lbragstadI imagine it to be quick22:09
morgansure... i mean the discussion is super simple22:09
morgani might even have code posted by the PTG22:09
morganit's literally "here is dogpile driver, oslo_cache, use that"22:09
lbragstadmorgan yeah - i agree, i just want to air it out, document the tribal knowledge, and come up with a list of action items to move towards a solution22:10
morganthe bigger issue is getting keystonemiddleware to use oslo.cache22:10
lbragstadmorgan what does keystonemiddleware use now?22:10
lbragstada home grown cache implementation?22:10
morganyep22:11
morganpart of that is because swift22:11
lbragstadgotcha22:12
*** thorst_ has quit IRC22:16
lbragstadmorgan would you also be interested in driver the VMT discussion for identity related projects?22:18
morgani can participate22:19
morganthough i would prefer to not be driving that one.22:19
lbragstadmorgan moderate?22:19
morgani can help on it, mostly i can communicate what the VMT wants from the projects22:20
lbragstadmorgan that'd work22:20
lbragstadby drive I don't mean be stuck with the implementation22:20
lbragstador work22:20
morganthe work is finding folks willing to do the threat analysis22:21
morganand publish it22:21
lbragstadI want drivers to be folks who have an interest in seeing something get done and speaking to it22:21
morganthis is not something i can do, and since i'm not the PTL i don't want to drive too hard on it22:21
morgani am happy to discuss the needs22:21
lbragstadcool22:21
morganbut they are largely the same as what was put in the meeting22:21
morganand barbican has done this, so the detail can follow in their steps22:22
openstackgerritRon De Rose proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644922:22
*** chris_hultin|AWA is now known as chris_hultin22:26
*** spilla has quit IRC22:29
openstackgerritRichard Avelar proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644922:31
morganlbragstad: https://review.openstack.org/#/c/428388/7 might be something to discuss at PTG22:33
lbragstadmorgan ok - let me see if I can find a spot for it22:34
lbragstadmorgan how long are you thinking the discussion will take?22:34
morganlbragstad: and https://review.openstack.org/#/c/428472/ can probably get a +A since no one else has poked at it22:34
morganlbragstad: short discussion it's just "is there a reason we shouldn't do this deprecation"22:34
morganif we22:34
morganre really doubling down on fernet22:34
morgandropping uuid is a good plan22:34
lbragstadmorgan ++ that reminds me that we need a deprecations session22:35
*** Krenair has joined #openstack-keystone22:36
*** ngupta has quit IRC22:38
openstackgerritRon De Rose proposed openstack/keystone master: Extend User API to support federated attributes  https://review.openstack.org/42644922:39
*** prashkre has quit IRC22:44
openstackgerritGage Hugo proposed openstack/keystone master: Force SQLite to properly deal with foreign keys  https://review.openstack.org/12603022:45
*** edmondsw has quit IRC22:48
*** dave-mccowan has quit IRC22:53
*** adrian_otto1 has joined #openstack-keystone22:59
*** catintheroof has quit IRC23:00
*** adrian_otto has quit IRC23:01
*** jperry has quit IRC23:02
*** ravelar has quit IRC23:04
*** martinlopes has joined #openstack-keystone23:06
*** _d34dh0r53_ is now known as d34dh0r5323:09
*** lamt has quit IRC23:09
*** esp has quit IRC23:11
*** lamt has joined #openstack-keystone23:11
*** chris_hultin is now known as chris_hultin|AWA23:12
*** esp has joined #openstack-keystone23:12
*** lamt has quit IRC23:15
*** spzala has quit IRC23:17
*** adrian_otto1 has quit IRC23:17
*** thorst_ has joined #openstack-keystone23:17
*** gyee has joined #openstack-keystone23:18
*** ravelar has joined #openstack-keystone23:18
*** adrian_otto has joined #openstack-keystone23:19
*** thorst_ has quit IRC23:21
*** browne has quit IRC23:25
*** thorst_ has joined #openstack-keystone23:27
*** thorst_ has quit IRC23:32
*** thorst_ has joined #openstack-keystone23:32
*** thorst_ has quit IRC23:37
*** aasthad has quit IRC23:42
*** masterjcool has quit IRC23:49
*** jerrygb_ has joined #openstack-keystone23:52
*** jerrygb has quit IRC23:53
*** spzala has joined #openstack-keystone23:55
*** jerrygb_ has quit IRC23:59
*** jerrygb has joined #openstack-keystone23:59
*** spzala has quit IRC23:59

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