Thursday, 2018-06-07

openstackgerritMerged openstack/keystonemiddleware master: fix tox python3 overrides
*** bigdogstl has joined #openstack-keystone00:15
*** bigdogstl has quit IRC00:23
*** threestrands has quit IRC00:25
*** jmlowe has quit IRC00:26
*** jmlowe has joined #openstack-keystone00:27
*** threestrands has joined #openstack-keystone00:28
*** liuzz has joined #openstack-keystone01:00
*** itlinux has joined #openstack-keystone01:00
*** Dinesh_Bhor has joined #openstack-keystone01:04
*** eEbx has quit IRC01:08
*** eEbx has joined #openstack-keystone01:08
*** felipemonteiro has joined #openstack-keystone01:12
sapdlbragstad: I have same result, But when use `time` command I get real time.
*** felipemonteiro_ has joined #openstack-keystone01:14
*** felipemonteiro has quit IRC01:18
*** felipemonteiro_ has quit IRC01:24
*** threestrands has quit IRC01:35
*** threestrands has joined #openstack-keystone01:35
*** threestrands has quit IRC01:36
*** threestrands has joined #openstack-keystone01:37
*** threestrands has quit IRC01:37
*** threestrands has joined #openstack-keystone01:37
*** threestrands has quit IRC01:38
*** threestrands has joined #openstack-keystone01:38
*** threestrands has quit IRC01:38
*** threestrands has joined #openstack-keystone01:38
*** threestrands has quit IRC01:39
*** threestrands has joined #openstack-keystone01:40
*** threestrands has quit IRC01:40
*** threestrands has joined #openstack-keystone01:40
*** threestrands has quit IRC01:41
*** edmondsw has joined #openstack-keystone01:42
*** edmondsw has quit IRC01:47
*** blake has quit IRC01:56
*** r-daneel has joined #openstack-keystone01:56
openstackgerritMerged openstack/oslo.policy master: fix tox python3 overrides
*** threestrands has joined #openstack-keystone02:11
*** threestrands has quit IRC02:11
*** threestrands has joined #openstack-keystone02:11
*** d0ugal_ has joined #openstack-keystone02:49
*** d0ugal has quit IRC02:51
*** lifeless_ has joined #openstack-keystone03:03
*** lifeless has quit IRC03:03
*** boris_42_ has quit IRC03:05
*** threestrands has quit IRC03:13
*** edmondsw has joined #openstack-keystone03:30
*** sonuk has joined #openstack-keystone03:34
*** edmondsw has quit IRC03:35
*** germs has quit IRC03:37
*** germs has joined #openstack-keystone03:38
*** blake has joined #openstack-keystone03:57
*** blake has quit IRC04:02
*** blake has joined #openstack-keystone04:09
*** blake has quit IRC04:14
*** germs has quit IRC04:16
*** links has joined #openstack-keystone04:28
*** annp has joined #openstack-keystone04:29
*** blake has joined #openstack-keystone04:45
*** blake has quit IRC04:50
*** mvk has joined #openstack-keystone04:54
*** Dinesh_Bhor has quit IRC05:00
openstackgerritMerged openstack/keystone master: fix tox python3 overrides
*** edmondsw has joined #openstack-keystone05:19
*** edmondsw has quit IRC05:23
*** Dinesh_Bhor has joined #openstack-keystone05:30
*** Dinesh__Bhor has joined #openstack-keystone05:52
*** Dinesh_Bhor has quit IRC05:53
*** gyee has quit IRC05:53
*** pcichy has quit IRC05:54
*** pcichy has joined #openstack-keystone06:00
*** Dinesh__Bhor has quit IRC06:23
*** Dinesh_Bhor has joined #openstack-keystone06:26
*** bigdogstl has joined #openstack-keystone06:29
*** dklyle has quit IRC06:29
*** namnh has joined #openstack-keystone06:31
*** bigdogstl has quit IRC06:33
*** pcaruana has joined #openstack-keystone06:35
*** AlexeyAbashkin has joined #openstack-keystone07:04
*** edmondsw has joined #openstack-keystone07:07
openstackgerritmelissaml proposed openstack/python-keystoneclient master: fix a typo in docstring
*** edmondsw has quit IRC07:11
*** jistr|mtgs is now known as jistr07:22
*** Dinesh_Bhor has quit IRC07:26
*** Dinesh_Bhor has joined #openstack-keystone07:31
*** dklyle has joined #openstack-keystone07:32
*** Alexey_Abashkin has joined #openstack-keystone07:34
*** AlexeyAbashkin has quit IRC07:35
*** Alexey_Abashkin is now known as AlexeyAbashkin07:35
*** AlexeyAbashkin has quit IRC07:46
*** jaosorior has joined #openstack-keystone07:52
*** AlexeyAbashkin has joined #openstack-keystone07:56
*** jaosorior has quit IRC08:10
*** akovi has joined #openstack-keystone08:15
*** AlexeyAbashkin has quit IRC08:23
akoviHi keystone team!08:23
akoviI'm trying to solve this bug in Mistral
openstackLaunchpad bug 1775140 in Mistral "Keystoneauth does not consistently add the collect-timing parameter" [Medium,Confirmed] - Assigned to Brad P. Crochet (brad-9)08:23
akoviTried to follow the comment from @wangxiyuan but ran into issues08:24
akoviI tried to use register_session_conf_options, like this:08:25
akoviloading.register_session_conf_options(cfg.CONF, _base.AUTHTOKEN_GROUP)08:25
akoviThe issue is that it tries to re-register the cafile option which fails as the module uses keystonemiddleware that already initialized the options with `loading.register_auth_conf_options(cfg.CONF, _base.AUTHTOKEN_GROUP)`. What can I do here?08:25
wxyakovi: Hi I think you should register these options in a new section. Not keystone_authtoken08:26
akoviah, ok08:26
*** AlexeyAbashkin has joined #openstack-keystone08:26
akoviwxy: but this will imply configfile changes and code changes, right?08:27
*** d0ugal_ has quit IRC08:29
*** d0ugal has joined #openstack-keystone08:29
*** d0ugal has quit IRC08:29
*** d0ugal has joined #openstack-keystone08:29
wxyakovi: I think so. it means that these options will be separated from [keystone_authtoken] section.08:29
*** AlexeyAbashkin has quit IRC08:33
*** AlexeyAbashkin has joined #openstack-keystone08:38
*** AlexeyAbashkin has quit IRC08:45
*** jaosorior has joined #openstack-keystone08:54
*** edmondsw has joined #openstack-keystone08:55
*** edmondsw has quit IRC09:00
*** pooja-jadhav is now known as pooja_jadhav09:14
*** lifeless_ has quit IRC09:17
*** lifeless has joined #openstack-keystone09:18
*** AlexeyAbashkin has joined #openstack-keystone09:31
yankcrimeping knikolla, want to talk to you about as we're thinking about using it....09:35
*** links has quit IRC09:48
*** dklyle has quit IRC09:50
*** david-lyle has joined #openstack-keystone09:50
*** AlexeyAbashkin has quit IRC09:50
*** david-lyle has quit IRC09:52
*** dklyle has joined #openstack-keystone09:52
*** dklyle has quit IRC09:53
*** david-lyle has joined #openstack-keystone09:53
*** david-lyle has quit IRC09:53
*** AlexeyAbashkin has joined #openstack-keystone10:02
*** dklyle has joined #openstack-keystone10:04
*** links has joined #openstack-keystone10:05
*** pcichy has quit IRC10:06
*** AlexeyAbashkin has quit IRC10:13
*** Alexey_Abashkin has joined #openstack-keystone10:13
*** namnh has quit IRC10:15
*** Alexey_Abashkin is now known as AlexeyAbashkin10:16
*** akovi has left #openstack-keystone10:16
*** Dinesh_Bhor has quit IRC10:17
d0ugalwxy: Hey - if you have a moment can you let me know if this is a better fix? (You commented on the alternative: )10:21
d0ugaloh, I see you spoke with akovi in here about it10:22
* d0ugal reads the backlog10:22
d0ugalIt isn't clear to me which is the best direction - is seems like 572788 might be the safer fix.10:23
*** AlexeyAbashkin has quit IRC10:23
bretonhow is policy.v3cloudsample.json edited today - manually or it fetches policies from some python code?10:24
*** AlexeyAbashkin has joined #openstack-keystone10:25
bretoni mean when i want so create a new review on gerrit10:26
*** bigdogstl has joined #openstack-keystone10:29
*** bigdogstl has quit IRC10:34
wxyd0ugal: yeah, 572788 is safer. Because the backwards compatibility should be considered in 57230010:37
*** Alexey_Abashkin has joined #openstack-keystone10:38
*** AlexeyAbashkin has quit IRC10:39
*** Alexey_Abashkin is now known as AlexeyAbashkin10:39
*** links has quit IRC10:39
d0ugalwxy: Thanks for confirming.10:40
*** edmondsw has joined #openstack-keystone10:43
*** edmondsw has quit IRC10:47
*** Anurag has joined #openstack-keystone10:54
*** Anurag has quit IRC10:54
*** Anurag has joined #openstack-keystone10:55
*** Anurag has quit IRC10:55
*** Anurag has joined #openstack-keystone10:56
*** Anurag has quit IRC10:56
*** links has joined #openstack-keystone10:56
*** Anurag has joined #openstack-keystone11:00
*** AlexeyAbashkin has quit IRC11:01
*** anurag has joined #openstack-keystone11:05
*** anurag has quit IRC11:13
knikollayankcrime: o/11:18
yankcrimehi knikolla!11:19
yankcrimeso johnthetubaguy came back from the vancouver summit having discovered ksproj, and it seems like an ideal fit for a project we're involved in11:20
* johnthetubaguy nods11:20
yankcrimei was just wondering what your plans are for it really, i can see it's being actively worked on still but there's a fair bit of stuff in there that's specific to the mass open cloud11:21
yankcrimeis there anything we can do to help?11:21
knikollayankcrime: plans are to make it a self-service project management tool for "project admins"11:21
knikollacurrently it only has the invite feature11:21
*** edmondsw has joined #openstack-keystone11:22
knikollai used it january-ish to invite a class of about 100 students to 10 or so projects11:22
knikollabut hasn't received a lot of love since then due to time constraints and other priorities11:23
knikollai'd be happy if you could use it and we could beat it to shape together with both our use cases11:24
yankcrimeknikolla: sounds good, should i start off with the 'devel' branch?11:25
yankcrimeit looks like that might be partway through a bit of a refactor...11:25
knikollayankcrime: true, midway refactor and burnout.11:26
knikollagive me a day or two, as i have a few local commits i haven't pushed.11:27
yankcrimeknikolla: no worries, that's great11:29
* knikolla opens pycharm11:30
knikollaseems last time i touched it i almost finished the refactor11:30
cmurphysounds a bit like adjutant
knikollai just need to test it before i push it11:30
knikollacmurphy: true11:30
knikollai was planning on investigating that as well. though adjutant felt very general purpose11:31
yankcrimeyeah i've come across adjutant as well11:31
yankcrimeits scope is much more broad11:32
breton b"oslo_db.exception.DBError: (pymysql.err.InternalError) (1071, 'Specified key was too long; max key length is 767 bytes')11:40
bretonhas anybody seen this issue in tests?11:40
* knikolla starts heading to the office after finishing morning coffee. 11:41
cmurphybreton: sounds familiar, i think that's a charset issue
*** raildo has joined #openstack-keystone11:48
bretoncmurphy: yes, i've found that too, thanks. But it all feels so wrong11:50
*** AlexeyAbashkin has joined #openstack-keystone11:51
cmurphyi could have sworn it was documented11:53
*** nicolasbock has joined #openstack-keystone12:11
*** dave-mccowan has joined #openstack-keystone12:14
*** dave-mcc_ has joined #openstack-keystone12:16
*** dave-mccowan has quit IRC12:18
*** rcernin has quit IRC12:56
johnthetubaguyin other news yankcrime is working on that federation blog post I said was on its way, that should help with the spec for the federation mapping changes, with any luck13:06
*** AlexeyAbashkin has quit IRC13:08
*** Alexey_Abashkin has joined #openstack-keystone13:08
*** Alexey_Abashkin is now known as AlexeyAbashkin13:10
yankcrimethere's an introductory one in review now which outlines the work we're doing (and with who), and a part-two which is in draft and which will elaborate on the AAI specifics13:13
lbragstadsapd: so it looks like you're getting half a second response times when you authenticate13:32
*** openstackgerrit has quit IRC13:34
lbragstadcurious if folks want to take a final peak at
* cmurphy about to13:36
lbragstadthanks - i appreciate people putting up with my persistent pesting13:38
*** dave-mcc_ has quit IRC13:41
*** dave-mccowan has joined #openstack-keystone13:42
*** AlexeyAbashkin has quit IRC13:43
lbragstadevrardjp: o/ did you have some questions about secret storage and keystone?13:43
evrardjpnot real questions from OSA to keystone, but I'd like to hear what could be going on13:44
lbragstadyeah - it's a topic that's been brought up several times13:44
evrardjpI think keystone, more than some other projects, require the generation of secrets, and their handling (like fernet tokens on the filesystem)13:45
lbragstadand the most recent use case that we gravitate towards is using something like castellan/barbican for storing fernet keys13:45
evrardjpif there is a change happening, I guess we need to know13:45
evrardjpunderstand what the best practices will be13:45
lbragstadas of right now, we're not doing anything to put secrets into a proper secret storage utility - yet...13:45
evrardjpis there something else on that castellan level than fernet tokens?13:46
lbragstadlike- something else we could use it for?13:46
evrardjpyes, what do you expect in the near future13:46
*** dave-mccowan has quit IRC13:46
evrardjpif anything else13:47
lbragstadfernet tokens are the main things that jump out at me... in the future, if we have another token provider implementation based on authenticated encryption, that would be another candidate13:47
evrardjpyeah but that's an if :)13:47
evrardjpfor the moment I guess we are good13:47
lbragstadideally, it would be nice to offer support for more secure key storage13:47
lbragstadwe tripped trying to generalize the key rotation logic13:48
evrardjpyeah, I guess that's the hardest for many13:48
*** dave-mccowan has joined #openstack-keystone13:48
lbragstadthe current key rotation stuff is pretty specific to fernet, which is fine... but i suppose we'd need it to behave the same regardless of keys living on local disk or in a secret storage container13:49
evrardjpI am completely unaware of how things work with castellan/barbican, would keystone request the rotation of secrets directly?13:49
evrardjpwell I guess that's my question13:49
lbragstadi'm inclined to say that keystone should provide a facade that handles the rotation regardless of the backend13:49
evrardjpit looks like it would be simpler to just have the deployer handle it13:49
evrardjpyes, but that's more work13:50
lbragstadagree to disagree :)13:50
*** dave-mcc_ has joined #openstack-keystone13:50
evrardjpwell I am fine with that13:50
*** AlexeyAbashkin has joined #openstack-keystone13:50
lbragstadiirc - that's where discussions tipped over13:50
lbragstadwhen we were looking at a specification to make the fernet key backend pluggable13:51
evrardjpit brings a reference implementation code vs documentation13:51
evrardjpI see13:51
johnthetubaguylbragstad: slight nit on the spec, it doesn't cover A using any resources, its not a big deal, just a Nit, otherwise looks good.13:51
lbragstadjohnthetubaguy: in the new examples?13:51
johnthetubaguyit only covers the error case I think13:52
lbragstadjohnthetubaguy: oh - you mean sum(A.limit, B.limit, C.limit) needs to be represented on line 66?13:53
*** dave-mccowan has quit IRC13:53
lbragstadinstead of just sum(B.limit, C.limit) ?13:53
lbragstadwait - maybe i'm not parsing that properly13:54
johnthetubaguylbragstad: I think so, I added comments, having said that, I don't think its a blocker, more something we could clarify later in a follow up, if needed13:54
lbragstadi can spin up a follow-on, but i'm not sure i completely understand the comment after reading it again13:54
lbragstadlines 66 - 70 are specific to validating limits in the API in keystone13:55
*** Alexey_Abashkin has joined #openstack-keystone14:02
*** AlexeyAbashkin has quit IRC14:02
*** Alexey_Abashkin is now known as AlexeyAbashkin14:02
*** anurag has joined #openstack-keystone14:08
*** anurag has quit IRC14:13
johnthetubaguylbragstad: so that was probably a miss-read on my part, looking at it again14:14
*** felipemonteiro has joined #openstack-keystone14:15
*** felipemonteiro_ has joined #openstack-keystone14:15
*** openstackgerrit has joined #openstack-keystone14:18
openstackgerritMerged openstack/pycadf master: fix tox python3 overrides
openstackgerritMerged openstack/pycadf master: Remove moxstubout usage
*** felipemonteiro has quit IRC14:20
*** links has quit IRC14:23
*** itlinux has quit IRC14:26
ayounglbragstad, kmalloc on the spec for quota (I'm fine with it going in) do we want to name things a little better so we can find them in the future?14:32
ayoungInstead of the commit being14:32
ayoungHierarchical Unified Limits14:32
ayoungit should be14:32
ayoungTwo Level Hierarchical Unified Limits14:32
lbragstadi'm working on addressing follow ups now14:32
ayoungand the file name itself should match14:32
lbragstadi can fix taht14:33
ayoungdidn't want to mess things up if the spec freeze is today or something14:33
lbragstadyeah - it's the end of the week14:33
ayounglbragstad, we really should have a placeholder for the multi-level Hierarchical limits.14:34
hrybackilbragstad: are those freeze dates up to the services to determine? I know M2 is June4-8, but I thought the actual freeze date was today14:34
ayoungI'd hate to be stuck with 2 level forever14:34
lbragstadhrybacki: projects can pick their own deadlines, so long as they are reasonable i think14:35
hrybackiack ack14:35
lbragstadayoung: i have a section detailing future work in the current specification that should serve as a base for a new spec if we need it to14:35
lbragstadwhich includes details from your post14:36
ayounglbragstad, yeah, but we really should get the spec going14:36
lbragstadand the concept the tracking aggregates14:36
ayoungI'm just afraid we are going to get to two level and stop14:36
*** Alexey_Abashkin has joined #openstack-keystone14:38
*** spilla has joined #openstack-keystone14:39
*** AlexeyAbashkin has quit IRC14:41
*** Alexey_Abashkin is now known as AlexeyAbashkin14:41
ayoung  jaosorior you flippin rock14:51
cmurphywow that's cool14:53
*** lifeless_ has joined #openstack-keystone14:53
*** lifeless has quit IRC14:53
lbragstadkmalloc: there are a couple comments on the strict two level spec that you might be better suited to answer than i am14:58
*** Kumar has joined #openstack-keystone14:59
*** d0ugal has quit IRC15:07
*** itlinux has joined #openstack-keystone15:13
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Address follow-on comments in strict-two-level spec
lbragstadkmalloc: cmurphy johnthetubaguy attempted to clarify bits in a follow on15:16
lbragstadayoung: ^15:16
johnthetubaguylbragstad: I am fine with that, narrows down the conversion nicely15:17
lbragstadyeah - makes it a little easier to see what the controversial points are :)15:17
*** Alexey_Abashkin has joined #openstack-keystone15:20
*** AlexeyAbashkin has quit IRC15:22
*** Alexey_Abashkin is now known as AlexeyAbashkin15:22
*** AlexeyAbashkin has quit IRC15:22
*** AlexeyAbashkin has joined #openstack-keystone15:23
*** Kumar has quit IRC15:24
*** Kumar has joined #openstack-keystone15:25
-openstackstatus- NOTICE: Zuul update for Ansible 2.5 in progress. Scheduler crashed as unexpected side effect of pip upgrade. Will be back and running shortly.15:30
*** Alexey_Abashkin has joined #openstack-keystone15:37
*** AlexeyAbashkin has quit IRC15:37
*** Alexey_Abashkin is now known as AlexeyAbashkin15:37
*** gyee has joined #openstack-keystone15:46
*** Kumar has quit IRC15:48
*** AlexeyAbashkin has quit IRC15:53
kmalloclbragstad: nice15:59
-openstackstatus- NOTICE: The zuul upgrade to ansible 2.5 is complete and zuul is running again. Changes uploaded or approved between 15:25 and 15:45 will need to be rechecked. Please report any problems in #openstack-infra16:10
*** lifeless has joined #openstack-keystone16:16
*** lifeless_ has quit IRC16:16
*** bigdogstl has joined #openstack-keystone16:20
*** ckonstanski has quit IRC16:31
*** lifeless_ has joined #openstack-keystone16:35
*** lifeless has quit IRC16:36
*** dklyle has quit IRC16:36
openstackgerritLance Bragstad proposed openstack/keystone master: Clarify scope responses in authentication api ref
*** Kumar has joined #openstack-keystone16:40
cmurphylbragstad: did you mean to change a bunch of error code lists in ^ ?16:42
*** felipemonteiro_ has quit IRC16:42
lbragstadi did - but i can make that a separate change if needed16:42
*** felipemonteiro_ has joined #openstack-keystone16:42
lbragstador if that's more appropriate16:42
cmurphyoh you did mention it in the commit message16:43
cmurphysorry to nitpick but i would rather it be separate, the error codes don't really have anything to do with the bug imo16:44
lbragstadthat's fair16:44
openstackgerritBoris Bobrov proposed openstack/keystone master: Allow domain admin listing their domain
openstackgerritLance Bragstad proposed openstack/keystone master: Clarify scope responses in authentication api ref
openstackgerritLance Bragstad proposed openstack/keystone master: Update response codes for authentication API reference
*** Kumar has quit IRC17:05
*** Kumar has joined #openstack-keystone17:05
kmalloccmurphy: ++17:08
*** r-daneel has quit IRC17:10
*** raildo has quit IRC17:12
*** itlinux has quit IRC17:30
*** boris_42_ has joined #openstack-keystone17:32
*** openstackgerrit has quit IRC17:34
*** spilla has quit IRC17:35
*** raildo has joined #openstack-keystone17:37
*** bigdogstl has quit IRC17:37
*** spilla has joined #openstack-keystone17:43
*** Kumar has quit IRC17:47
*** felipemonteiro__ has joined #openstack-keystone17:48
*** felipemonteiro_ has quit IRC17:52
*** r-daneel has joined #openstack-keystone18:09
kmalloclbragstad: ok looking at token model then going to write some code to move version to flask (and maybe app cred? or ... maybe i should do auth)18:27
lbragstadkmalloc: nice - thanks!18:28
kmalloclbragstad: i also want to explore merging some bits together, e.g. Token really is part of auth (tree structure wise)18:28
kmalloclbragstad: so we can do auth/<resulting_auth_type> [k2k, fed, token, OIDC]18:28
lbragstadoh - sure18:29
kmalloclooking at future plans for IDP->SP[IDP Proxy]->[SP, SP, SP, SP]18:29
kmallocjust code structure wise.18:29
kmallocfor the output auth result.18:29
kmallocthe validate paths and "are you who you say you are" are closely tied already18:30
lbragstadi need to mull it over, but so long as the objects are clearly separated then i think that sounds reasonable18:31
kmallocyeah i'm not sold on it yet, just thinking through if we're restructuring code18:31
lbragstadlet's explore it18:31
lbragstader - i'm open to exploring it18:32
kmallocyeah, just floating ideas to make our code tree make more sense.18:36
lbragstadyeah - i can get behind that18:37
kmalloclbragstad: i'm also going to start with Flask-RestFUL, but i'm going to make a case to go to RestPLUS and do some hacking so we get swagger ui/docs18:37
kmallocbut it'll need some work so we don't break our JSON_HOME18:37
kmallocand the fact that it is used for disc.18:37
*** spotz has quit IRC18:45
*** spotz has joined #openstack-keystone18:46
kmalloclbragstad, cmurphy: the explicit call out to say we don't address per-endpoint data/limits (just per-region) was needed to get past the -2 from ayoung, specifically calling out that we aren't solving the per-endpoint problem but we are aware that there has been requests for it [future development]18:48
kmallocand it's reasonable to be explicit that the per-endpoint-limit isn't in scope of the current spec/proposal18:48
lbragstadso - what's the per-endpoint problem?18:48
kmalloci have 2 compute endpoints18:48
kmallocsame region18:48
kmalloci can consume the entire quota on each of them18:49
kmallocendpoints do not share consumption/claim data18:49
lbragstadshouldn't the endpoint be calculating usage based on project?18:49
kmallocright, but lets say we have Nova A and Nova B18:50
kmallocwith different dbs.18:50
kmallocbecause... $reasons$ (think MOC type use case)18:50
kmallocthe quota could be consumed, say 100vms on each endpoint evne though you want to say limit the total usage in a region to 10018:50
lbragstadyeah - that seems out of scope18:50
kmallocso the addition was explicitly saying we aren't addressing that18:51
kmallocbut we need to ensure that the model can consume data from *any* data source, not just local18:51
kmallocso if we address it, you can say back to etcd and share the data18:51
lbragstadmodel? as in oslo.limit?18:51
kmallocthe limit model (enforcement)18:51
lbragstadbecause right now that's technically coming from a callback supplied to oslo.limit18:52
kmallocthe "get current usage" is a callback?18:52
lbragstadbased on the session we had in YVR18:52
*** ayoung has quit IRC18:52
kmallocbleh. i would like that to be wrapped.18:52
kmallocoh it is18:52
lbragstadyeah - it's a context manager18:52
lbragstadand it accepts a callback function18:53
kmallocwe can address it and store usagage via the context manager centrally then18:53
kmallocyeah, we're in a good place for future iteration18:53
kmallocdon't mind me.18:53
kmalloci know how to implement shared claim/usage with sync [future]18:53
kmallocwe're in a good place for that.18:54
kmalloci was worried we just wrote ourselves into a corner18:54
kmallocwe didn't18:54
kmallocit most likely will be a "watch" and issue an "update me now" request to the shared node.18:54
kmallocwhich should keep us mostly in line, and can be 100% implemented through the context manager.18:55
kmallocwrapping the callback18:55
kmalloclbragstad: anyway.. yes it is a feature request/future looking.18:55
kmalloclbragstad: and the spec just says we don't plan to solve it right now. :)18:55
lbragstadgood deal18:55
kmallocalso, i'll review the token_model for a tradesies on reviewing the rest of the flaskification stuff [current]18:56
*** ayoung has joined #openstack-keystone19:01
*** martinus__ has joined #openstack-keystone19:10
kmalloclbragstad: -1, but because you have a lot of cases where you're assigning a UUID/ID (like user_id) into a dict-returning @property19:10
lbragstadyeah - i'm wondering if there is a better way to handle that19:11
kmalloclbragstad: basically we should never assign a non-dict into a dict-returning @property especially if it's just being called from the self.user_id settr, which could do the work.19:11
kmallocjust hook it into the id-settrs19:11
kmallocand the dict setters are removed, id-settr does the lookup19:11
kmallocor you do the lookup in the @property on demand (lazy)19:11
kmallocso self.user_id = id19:12
kmallocand self.user does the lookup on demand19:12
kmallocthere is also the concern of cached/stale data19:12
lbragstadi was wondering if that was going to back a regression19:12
kmallocbut i think that is minimal and not any worse than today19:12
lbragstadtoday we load things into token_data and leave it there19:13
lbragstadthen use conditionals everywhere to short circuit if it's already populated19:13
lbragstadso - in a sense it's already cached?19:13
kmallocyeah and already stale19:13
kmallocso, ignore the cached/stale comment i just said here19:13
kmallocwe just need to not set differing data types into an @property19:13
kmallocif we expect a dict, we should only set a dict19:14
lbragstadnot sure i fully understand ^19:14
kmallocif user returns a dict19:14
kmallocself.user = user_id should be an error condition19:14
kmallocself.user_id = user_id is fine19:14
lbragstadthe second one is what happens today i thin19:15
kmallocbut you're setting a value into something that returns a dict, and it's not a dict19:15
lbragstadself.user is a dict19:15
lbragstadself.user_id is a string19:15
kmallocyour code does self.user_id = id -> self._user_id = id, self._user = id19:15
kmallocand self.user = id -> self._user = providers.lookup_user(user_id)19:16
lbragstadright - but the setting for self.user uses the id to populate the self.user attribute with the reference from the identity backend19:16
kmallocso you're assigning a string into the public setter and expecting a dict out19:16
kmallocself.user_id = id could populate self.user19:16
lbragstadi was trying to avoid this:19:16
lbragstadtoken.user_id = id19:17
lbragstaduser_ref = PROVIDERS.identity_api.get_user(id)19:17
lbragstadtoken.user = user_ref19:17
kmallocyou can be super smart about populating related fields19:17
kmallocalso lean on context_cache19:18
kmallocit's there for this very reason19:18
*** mvk has quit IRC19:18
lbragstadis that the thread local thing?19:18
kmallocif you lookup user in the request, it's stored thread_local19:18
lbragstadso - you're saying lean on thread local caching and ditch the weird setter/caching of the token object19:18
kmallocbut token.user_id = id could populate behind the scenes19:18
kmallocOR you could load when token.user is called19:19
kmallocso you save the lookup unless it's used19:19
*** mugsie has quit IRC19:19
kmallocbut right now you're doing token.user_id = id, which sets the id in token.user and populates it19:19
kmallocso you're doing: token.user_id = id; user_ref = _get_user(id), token.user = user_ref19:19
kmallocjust short circut and don't push it through the @property.settr19:20
kmallocfor token.user19:20
kmallocOR when you read token.user the first time if it isn't populated, load based upon token.user_id19:20
kmallocif you want to limit db lookups for unrelated data19:20
lbragstadthat was something i was trying to do19:21
*** mugsie has joined #openstack-keystone19:21
*** mugsie has quit IRC19:21
*** mugsie has joined #openstack-keystone19:21
kmalloccontext cache is good, but lazy load/lookup might be best.19:21
*** mugsie has quit IRC19:21
*** mugsie has joined #openstack-keystone19:21
lbragstadso - in the @property of user19:21
lbragstadcheck if self.user_id19:21
lbragstadis populated19:21
kmallocraise exception if it isn't19:21
lbragstadif so, fetch it from the identity backend19:22
kmallocwell hold on19:22
*** mugsie has quit IRC19:22
kmallocload on demand, and only load the first time19:23
*** Guest68045 has joined #openstack-keystone19:24
kmallocyou could eliminate the local cache if you want to just lean on the context_cache for data19:24
lbragstadso - why raise the exception?19:24
kmallocbecause user_id hasn't been set19:24
*** Guest68045 has quit IRC19:24
lbragstadas opposed to just returning NOne?19:24
kmallocsure, None19:24
*** mugsie_ has joined #openstack-keystone19:24
kmallocdoesn't matter19:24
lbragstadjust checking19:24
kmalloci was thinking from more assured data.19:24
kmallocwhich an exception makes a lot of sense19:25
lbragstadtechnically we'll be validating that when we mint the token19:25
kmalloc"hey, uh, i don't have a user_id, so, uh i don't have a user to give you"19:25
kmallocright you can make the model smart on that front19:25
kmallocand just catch general errors in mint19:25
kmallocrather than have mint need all that logic19:25
kmallocbut i don't care where the logic goes.19:26
kmalloci care that the tokne_model makes sense from any consumer19:26
*** felipemonteiro__ has quit IRC19:26
*** mugsie_ has quit IRC19:27
*** mugsie_ has joined #openstack-keystone19:27
*** mugsie_ is now known as _mugsie19:27
lbragstadi'll respin it to do the lazy load bit19:27
kmalloctrying to make it easier for you too, less settr and less other code.19:27
lbragstadthat was getting pretty dense19:28
*** _mugsie is now known as mugsie_19:28
*** d0ugal has joined #openstack-keystone19:29
*** d0ugal has quit IRC19:29
*** d0ugal has joined #openstack-keystone19:29
kmallocotherwise the model makes sense to me19:31
*** boris_42_ has quit IRC19:36
*** ckonstanski has joined #openstack-keystone19:54
*** felipemonteiro has joined #openstack-keystone20:09
*** scarlisle has joined #openstack-keystone20:13
*** itlinux has joined #openstack-keystone20:14
*** d0ugal has quit IRC20:21
*** felipemonteiro_ has joined #openstack-keystone20:22
*** felipemonteiro has quit IRC20:25
*** openstackgerrit has joined #openstack-keystone20:25
openstackgerritRaildo Mascena proposed openstack/keystone master: Exposing bug/1754677
openstackgerritRaildo Mascena proposed openstack/keystone master: Exposing bug/1754677
*** raildo has quit IRC20:37
*** pcaruana has quit IRC20:39
openstackgerritLance Bragstad proposed openstack/keystone master: Introduce new TokenModel object
*** spilla has quit IRC20:57
*** germs has joined #openstack-keystone20:59
*** martinus__ has quit IRC21:00
*** germs has quit IRC21:01
*** germs has joined #openstack-keystone21:03
*** germs has quit IRC21:04
*** itlinux has quit IRC21:15
*** bigdogstl has joined #openstack-keystone21:16
*** nicolasbock has quit IRC21:22
*** felipemonteiro_ has quit IRC21:28
*** felipemonteiro_ has joined #openstack-keystone21:29
*** bigdogstl has quit IRC21:38
*** edmondsw has quit IRC21:38
*** bigdogstl has joined #openstack-keystone21:57
openstackgerritMerged openstack/oslo.policy master: Clarify CLI documentation
openstackgerritMerged openstack/oslo.policy master: Add CLI usage documentation
*** bigdogstl has quit IRC22:03
*** lifeless_ has quit IRC22:03
*** lifeless has joined #openstack-keystone22:04
*** bigdogstl has joined #openstack-keystone22:14
*** bigdogstl has quit IRC22:19
*** rcernin has joined #openstack-keystone22:24
*** mchlumsky has quit IRC22:34
*** edmondsw has joined #openstack-keystone22:36
*** edmondsw has quit IRC22:41
*** bigdogstl has joined #openstack-keystone22:47
*** felipemonteiro_ has quit IRC22:48
*** felipemonteiro has joined #openstack-keystone22:49
*** bigdogstl has quit IRC22:52
*** dklyle has joined #openstack-keystone22:56
*** bigdogstl has joined #openstack-keystone23:01
*** bigdogstl has quit IRC23:09
*** bigdogstl has joined #openstack-keystone23:10
*** scarlisle has quit IRC23:14
*** bigdogstl has quit IRC23:14
*** felipemonteiro_ has joined #openstack-keystone23:21
*** felipemonteiro has quit IRC23:22
openstackgerritMorgan Fainberg proposed openstack/keystone master: Expand on debug_middleware option
*** bigdogstl has joined #openstack-keystone23:30
openstackgerritMorgan Fainberg proposed openstack/keystone master: Expand on debug_middleware option
kmalloclbragstad: ^ to address the comment on DEBUG middleware patch23:32
*** bigdogstl has quit IRC23:35
*** bigdogstl has joined #openstack-keystone23:49

Generated by 2.15.3 by Marius Gedminas - find it at!