Wednesday, 2018-07-18

*** tosky has quit IRC00:12
*** Dinesh_Bhor has joined #openstack-keystone00:38
*** Dinesh_Bhor has left #openstack-keystone00:38
*** Dinesh_Bhor has joined #openstack-keystone00:39
*** threestrands has joined #openstack-keystone00:40
*** threestrands has quit IRC00:40
*** threestrands has joined #openstack-keystone00:40
imacdonnkmalloc: I found that the hang was occurring when trying to reserve() from the the cache pool. Making the pool size larger seems to have fixed it (or delayed it????) .... also, curiously, it seems that the connections to memcached are getting closed immediately after use - if they're getting closed, I'm not sure why the pool needs to be larger ... hmmmm00:43
*** dave-mccowan has joined #openstack-keystone00:57
*** itlinux has quit IRC00:59
*** dave-mccowan has quit IRC01:09
*** harlowja has quit IRC01:13
*** dave-mccowan has joined #openstack-keystone01:17
*** dave-mcc_ has joined #openstack-keystone01:22
*** dave-mccowan has quit IRC01:24
*** annp has quit IRC01:43
openstackgerritwangxiyuan proposed openstack/keystoneauth master: Add netloc and version check for version discovery
openstackgerritDao Cong Tien proposed openstack/keystone master: Adds doc8 check to pep8
*** alex_xu has quit IRC02:31
*** alex_xu has joined #openstack-keystone02:33
openstackgerritayoung proposed openstack/keystoneauth master: Add netloc and version check for version discovery
*** mguz has quit IRC02:57
*** annp has joined #openstack-keystone03:11
*** flwang1 has quit IRC04:57
*** timburke_ has joined #openstack-keystone05:09
*** openstackgerrit has quit IRC05:10
*** timothyb89_ has joined #openstack-keystone05:12
*** chason_ has joined #openstack-keystone05:14
*** links has joined #openstack-keystone05:15
*** jmlowe has quit IRC05:16
*** wxy has quit IRC05:16
*** robcresswell has quit IRC05:16
*** mwhahaha has quit IRC05:16
*** pas-ha has quit IRC05:16
*** portdirect has quit IRC05:16
*** jamespage has quit IRC05:16
*** NobodyCam has quit IRC05:16
*** wlmbasson has quit IRC05:16
*** jmccrory has quit IRC05:16
*** timothyb89 has quit IRC05:16
*** jamielennox has quit IRC05:16
*** timburke has quit IRC05:16
*** chason has quit IRC05:16
*** tristanC has quit IRC05:16
*** harlowja has joined #openstack-keystone05:28
*** harlowja has quit IRC05:32
*** jmlowe has joined #openstack-keystone05:35
*** wxy has joined #openstack-keystone05:35
*** robcresswell has joined #openstack-keystone05:35
*** mwhahaha has joined #openstack-keystone05:35
*** portdirect has joined #openstack-keystone05:35
*** jamespage has joined #openstack-keystone05:35
*** pas-ha has joined #openstack-keystone05:35
*** NobodyCam has joined #openstack-keystone05:35
*** wlmbasson has joined #openstack-keystone05:35
*** jmccrory has joined #openstack-keystone05:35
*** jamielennox has joined #openstack-keystone05:35
*** martinus__ has joined #openstack-keystone05:47
*** tristanC has joined #openstack-keystone06:30
*** pcaruana has joined #openstack-keystone06:35
*** flwang1 has joined #openstack-keystone06:47
*** flwang1 has quit IRC06:49
*** flwang1 has joined #openstack-keystone06:58
*** ispp has joined #openstack-keystone07:00
*** peereb has joined #openstack-keystone07:09
*** tesseract has joined #openstack-keystone07:18
*** rcernin has quit IRC07:28
*** dklyle has quit IRC07:35
*** AlexeyAbashkin has joined #openstack-keystone07:45
*** tosky has joined #openstack-keystone08:06
*** markvoelker_ has quit IRC08:07
*** threestrands has quit IRC08:51
*** openstackgerrit has joined #openstack-keystone08:51
openstackgerritMerged openstack/keystone master: Strict two level limit model
*** gongysh has joined #openstack-keystone09:08
*** hoonetorg has quit IRC09:34
*** hoonetorg has joined #openstack-keystone09:48
*** markvoelker has joined #openstack-keystone10:08
*** kukacz_ has quit IRC10:12
*** kukacz_ has joined #openstack-keystone10:13
*** dmellado has quit IRC10:36
*** gongysh has quit IRC10:39
*** markvoelker has quit IRC10:42
*** dmellado has joined #openstack-keystone10:42
*** pcichy has quit IRC10:55
*** pcichy has joined #openstack-keystone10:56
*** gongysh has joined #openstack-keystone10:59
*** annp has quit IRC11:00
*** gongysh has quit IRC11:22
*** markvoelker has joined #openstack-keystone11:39
*** kevko has joined #openstack-keystone11:40
kevkoHi guys, just a question, is keystone tested against ldap by tempest ?11:40
*** pcichy has quit IRC11:52
*** raildo has joined #openstack-keystone11:53
*** markvoelker has quit IRC12:05
*** markvoelker has joined #openstack-keystone12:05
*** Dinesh_Bhor has quit IRC12:06
*** edmondsw has joined #openstack-keystone12:11
*** vigneshwar has joined #openstack-keystone12:23
vigneshwarHi hello,,12:23
cmurphykevko: sort of, we have a job that sets up a domain-specific ldap backend for devstack but I don't think the tempest tests use that domain as far as i ccan tell12:23
vigneshwarcan anyone tell me which location keystone credentials will be stored..12:23
cmurphyvigneshwar: what do you mean?12:26
vigneshwarcmurphy: after login to keystone, our credential(username & password) , where it will be stored ?12:30
cmurphyvigneshwar: the username and a hash of the password is stored in keystone's database12:31
vigneshwarhow can i access that database ?12:31
vigneshwarcmurphy : how can i access that database ?12:32
cmurphyvigneshwar: it's the mysql database that you set up when you install keystone
cmurphyvigneshwar: why do you need to access it?12:32
vigneshwarcmurphy : I thought it wont store any credentials and confidential information details in DB..12:34
vigneshwarcmurphy : i am new to keystone , just learning12:34
cmurphyvigneshwar: it doesn't store the password, only a hash of the password12:35
vigneshwaris there any mechanism in openstack that will automatically clear those credentials after logout ?12:36
cmurphyvigneshwar: I think you're confusing keystone with horizon, horizon doesn't store any credentials when you log in or out of it12:37
cmurphyyou wouldn't want to clear the credentials from keystone because you'd never be able to log back in12:38
*** sonuk has joined #openstack-keystone12:38
vigneshwarcmurphy: about horizon- is it a latest feature ?12:38
*** sonuk_ has quit IRC12:39
cmurphyhorizon is an openstack project
cmurphyit's a web dashboard12:39
kevkocmurphy: because there is issue with python3 ..keystone not working with ldap ...12:40
vigneshwaryes..i meant in the latest openstack release( horizon does'nt store password)..or it is one of the feature of horizon from the begining ?12:41
cmurphykevko: oh thats sounds likely :(12:41
cmurphykevko: what issue are you seeing?12:41
cmurphyvigneshwar: horizon has never stored passwords12:41
kevkocmurphy: there is an issue with encode and decode functions in keystone/identity/backends/ldap/common.py12:43
cmurphykevko: what release?12:43
kevkocmurphy: queens12:43
kevkocmurphy: also in master12:44
kevkocmurphy: utf8_encode , utf8_decode12:44
kevkocmurphy: also for testing has to be reworked to really have good tests for py2 and also py312:45
cmurphyyeah we do have unit tests for python 3 but i can believe they missed something12:46
cmurphykevko: can you file a bug and/or propose a patch?12:46
*** pcichy has joined #openstack-keystone12:46
kevkocmurphy: yes, tests are working ... but with real ldap on python3 it is not working ..on py2 it is working12:46
cmurphyoh i see12:47
kevkocmurphy: did you try ?13:08
cmurphykevko: sorry no I don't have a python3 installation handy at the moment, but could you file a bug and include the traceback?13:10
kevkocmurphy: yes, i will do it ..13:11
*** lbragstad has quit IRC13:19
*** mchlumsky has joined #openstack-keystone13:19
*** pcichy has quit IRC13:40
*** pcichy has joined #openstack-keystone13:45
*** pcichy has quit IRC13:45
*** pcichy has joined #openstack-keystone13:46
*** lbragstad has joined #openstack-keystone13:46
*** ChanServ sets mode: +o lbragstad13:46
*** r-daneel has joined #openstack-keystone13:48
*** dklyle has joined #openstack-keystone13:50
*** gongysh has joined #openstack-keystone13:51
*** sonuk_ has joined #openstack-keystone13:51
*** sonuk has quit IRC13:54
*** dklyle has quit IRC14:00
*** spilla has joined #openstack-keystone14:03
errrIm having touble with getting my mapping correct for my federated users. Keystone is telling me "Could not map any federated user properties to identity values"14:10
errrI have the following mapping:
errrCould someone tell me if that mapping would mean that my fed user would map its email to the username in keystone then make them a member of the federated_users group in the federated_domain domain?14:11
*** vrv_ has joined #openstack-keystone14:14
openstackgerritMorgan Fainberg proposed openstack/keystone master: Allow for 'extension' rel in json home
openstackgerritMorgan Fainberg proposed openstack/keystone master: Move trusts to flask native dispatching
*** xinran__ has joined #openstack-keystone14:18
openstackgerritMorgan Fainberg proposed openstack/keystone master: Trusts do not implement patch.
openstackgerritMorgan Fainberg proposed openstack/keystone master: Move trusts to flask native dispatching
cmurphyerrr: is "email" a property that your idp is providing in its assertion? you might see that error if that property doesn't exist14:20
errrcmurphy: yes it is there14:20
cmurphyerrr: are you using shibboleth as the service provider?14:21
lbragstadit sounds like you're trying to do auto-provisioning14:21
errrcmurphy: I used the firefox saml tracer to verify its there14:21
errrcmurphy: yes shibboleth14:21
cmurphyerrr: you might need to edit /etc/shibboleth/attribute-map.xml and add a line to get it to recognize "email" as a property14:21
errrah ok14:22
knikollayup, was just going to suggest that14:22
knikollashibboleth will only parse what's in attribute-map14:22
errrthat is exactly it14:23
cmurphylike this
errryall are the greatest :D14:23
lbragstad is a short snippet from the docs, but cmurphy's presentation is on point14:23
knikollaerrr: do you have control over the idp?14:24
cmurphylbragstad: that doesn't really cover this problem unfortunately14:24
errrI have watched her talk at the last summit like a dozen times. I wanted a longer more indepth version just on mapping :D14:24
errrknikolla: yes I do14:25
lbragstadcmurphy: the presentation or the doc link?14:25
cmurphyoh shoot that's what i should have submitted14:25
cmurphylbragstad: the doc link14:25
lbragstadoh - it was the only reference to the attribute-map.xml in our docs14:25
errrcmurphy: you should do a vlog on youtube about that mapping stuff you wanted to cover but ran out of time on14:25
knikollaerrr: instead of using just "email" as an attribute you should look into what is the standard URI for referencing email14:25
cmurphyerrr: lol14:26
errrfor reals :D14:26
errrknikolla: good idea. I will check that out14:26
errrcmurphy: there are literally dozens of us out there having to deal with this federation stuff that would eat that video up14:27
cmurphywell what we should really do is fix our docs so that this stuff isn't so hard14:28
errrit doesnt help that its not as popular as basic stuff14:28
lbragstad++ we still have two separate sections dedicated to federation in our docs14:28
knikollathen we'd be out of a job if that's too easy, haha14:28
errrfederation setup is a job Im happy to be out of14:29
lbragstadsame - i'll actively automate myself out the door on that one14:29
knikollafederation is all i do, it's not that bad14:29
errronce you get a firm understanding of it Im sure it gets easier14:31
errrIve been doing a lot of this with the OSA project so these steps are handled by ansible, and now Im having to do it on red hat osp and its all manual14:32
errrso I keep missing things14:32
errrand the only thing red hat even has documented for federation is using mellon but using keycloak and their red hat sso so it turns into a big guessing game when you want any other idp14:33
lbragstadoh - i was going to say... osa should have most of this ready to go in their os_keystone role14:33
errrthey do14:33
knikollaerrr: have you looked into openid connect?14:33
errrknikolla: no I havent14:33
knikollakeycloak supports both saml and openid connect14:34
errrthe customer Im doing this for wants okta14:34
knikollaquick google shows okta supporting openid connect14:34
knikollabut apart from that, things are pretty similar regardless of idp in terms of saml14:36
knikollaand all that needs guessing is in the metadata14:36
*** vigneshwar has quit IRC14:38
*** peereb has quit IRC14:51
*** pcaruana has quit IRC14:56
*** pcichy has quit IRC14:59
*** jmlowe has quit IRC15:00
*** gongysh has quit IRC15:13
errrknikolla: any idea why I would be getting "Group federated_users returned by mapping fico_rules_mapping was not found in the backend." when I log in now? openstack group list shows that group..15:20
errroh I think I know what the problem is. never mind15:22
*** jmlowe has joined #openstack-keystone15:24
*** ispp has quit IRC15:41
lbragstadmordred: curious if you'd be able to take another gander at sometime before tomorrow?15:46
*** links has quit IRC15:55
* lbragstad goes to get lunch15:58
*** pcaruana has joined #openstack-keystone16:00
*** lbragstad has quit IRC16:02
*** xinran__ has quit IRC16:28
imacdonnkmalloc: hi! Will bug you in a bit ... on a conf call now ... see update from last night on the cache pool thing16:29
kmallocimacdonn: sure. i think i saw it16:29
kmallocbut i was sleepy and didn't read it too closely16:29
* kmalloc does scrollback thing16:29
kmallocimacdonn: ahh16:31
kmallocimacdonn: i think i know what is happening. The pool is too small to handle the concurrency so you're just wedged in a wait-for-a-memcached and/or we have a deadlock bug16:32
kmallocimacdonn: the immediate closing of connections seems weird.16:32
imacdonnkmalloc: yeah, two weird things ... the immediate close, and the fact that the pool members still seem to be "in use" (???) but there are no connections to memcached16:33
imacdonnkmalloc: Once it gets into the bad state, it seems to stay there (doesn't recover)16:34
kmalloclike i said at the beginning, unfortunately this code is very fragile =/16:35
kmallocand a lot of that has to do with layering multiple uses of thread-local and having to reference internal interfaces16:35
*** AlexeyAbashkin has quit IRC16:36
kmallocwait, in queens you're deadlocked in "reserve()"16:37
* kmalloc tries to find this16:37
imacdonnyeah, so it appears ... I haven't been able to trace that into oslo_cache yet16:38
kmallocyou have some sort of mis-match in code bases16:38
kmalloci think16:38
*** AlexeyAbashkin has joined #openstack-keystone16:39
kmallocoh no16:39
kmallocwow, we did bad things here16:39
kmallocthis is just awful code :(16:39
*** AlexeyAbashkin has quit IRC16:43
openstackgerritGage Hugo proposed openstack/keystone master: Expose random uuid bug in cadf notifications
*** spilla_ has joined #openstack-keystone16:46
*** spilla has quit IRC16:46
*** lbragstad has joined #openstack-keystone16:50
*** ChanServ sets mode: +o lbragstad16:50
*** nels has quit IRC16:52
imacdonnkmalloc: so is the pool thing even worse than the eventlet thing? Seems to be a "rock and a hard place" :/16:53
*** jdennis has quit IRC17:06
*** jdennis has joined #openstack-keystone17:07
kmallocimacdonn: lol sadly17:09
kmallocimacdonn: i'm trying to see what could cause it to hang17:09
kmallocbut... i'm thinking there is an issue with not getting the connections back on the queue17:10
kmalloclike we're reaping them while they are active17:10
imacdonnOK ... I can try to add some debug logging if you can help me find the right place17:11
kmallocoh, no i think i see the issue.17:11
* kmalloc sighs.17:12
kmallocthe pool is just broken.17:12
kmallocyep... this is untested and i found the issue17:12
kmallocimacdonn: we don't put the connection back on the queue ever17:13
lbragstadis this an oslo.cache bug?17:13
kmalloclbragstad: probably more of an ksm bug17:13
imacdonnheh, that seems to make the pool .... of limited value ;)17:13
kmalloclbragstad: we do self._pool.get()17:14
lbragstaddid we move ksm to oslo.cache though?17:14
kmalloclbragstad: the issue is accquire does all the logic to get stuff back on the queue17:14
lbragstadand we override it?17:14
kmallocso we basically yeild out all the connections and let them expire17:14
kmallocno, we used to just do .get() which odes the logic17:14
kmallocthat accquire does (oslo.cache)17:14
kmallocwhen it was moved to oslo.cache we basically hit the queue.Queue "get" function17:15
lbragstadoh - now we're just calling into the pool directly17:15
kmallocand so we're not doing the context manager that places the connection back into the queue object17:15
kmallocbasically... 100% totally untested code17:15
lbragstadi wonder why that happened17:15
lbragstadsounds like the fix should be pretty easy? can't we just call .get() again?17:16
kmallocit's... i can fix this17:16
kmallocbut the issue is that the code in ksm was made too simple17:16
kmallocthis is an even bigger/longer running bug that i thought17:17
* kmalloc is tracing backwards 17:17
kmallocthis has been broken since pike17:18
kmallocwe broke it somewhere post ocata17:18
kmallocthen carried the brokenness forward and into oslo.cache17:18
kmallocwhen it was re-written to use queue.Queue17:19
lbragstaddo you think this is something we can address by tomorrow? or are we going to wait until stein17:19
kmallocuhm it's something we're going to have to backport17:19
kmallocit is probably a KSM only fix..17:20
kmalloci think17:20
kmallocbut i want to figure out where accquire is called.17:20
lbragstaddo we have a bug report for it yet?17:20
kmallocand right now i'm not seeing it17:20
kmallocnot yet.17:20
kmallocimacdonn: so the reason this doesn't work in pike is because it's been broken since pike =/17:20
kmalloclbragstad: give me a few minutes and i'll be able to write up a bug report on this.17:20
kmalloclbragstad: i just want to be sure i'm writing the right info.17:21
* kmalloc sighs.17:21
kmalloclets plan for a Freeze exception for this bug and backports to follow17:21
kmallocbackports to pike are going to be wonky since it didn't lean on oslo_cache17:21
imacdonnkmalloc: you mean the pool implementation, right? The issue my prod environment has on Pike is the eventlet thing consuming unbounded memcached connections ... separate issue (?)17:21
lbragstadknikolla: speaking of ksm, do you have thoughts on
kmallocthe pool implementation17:22
imacdonnI've only tried to use that on Queens, in my lab17:22
kmallocso even if you wanted to make the pool work on pike. it would have the same(ish) issues17:22
kmallocbecause it was re-written poorly and has next to zero testing17:22
kmallocand in openstack, if it's not tested... it is broken17:22
kmalloclbragstad: unrelated to this, flask for trusts should be working now.17:23
imacdonnyeah... it sounds like no one is using it, which jeopardises my warm-fuzzies a bit17:23
kmalloclbragstad: and next after trusts will be auth.17:23
kmalloclbragstad: because getting into things like users, roles, etc becomes massive patches.17:23
lbragstadkmalloc: do you think we're going to be able to convert all the API prior to stein?17:23
imacdonnI wonder how others are dealing with this .... maybe just allowing memcached to have a gazillion connections ?17:23
kmalloclbragstad: i hope so.17:23
lbragstador should we just queue them up and land them first thing in stein?17:23
kmalloclbragstad: i would expect to have them all done in Rocky as long as no one balks at the code17:24
kmalloclbragstad: it also has no effect [besides some extra code in the code base] maintaining a mix between the two methods17:24
kmalloclbragstad: it is 100% ok to have some paths on flask and some on legacy webob17:25
kmallocthe reason i wrote all the supporting code :)17:25
kmallocimacdonn: that is the easiest solution, but my guess, tight limits on WAIT states and low request numbers17:25
lbragstadif we want an exception for ksm, we'll have to get signoff by the release team (since that's not totally in our control)17:27
lbragstadfrom an exception perspective17:27
kmallocwell, i'll do what i can, but my guess is we will want to plan for one17:27
kmalloci don't know if the gate is going to be friendly with us (looking at how slow patches march through atm)17:27
kmallocfor integrated testing that is17:28
lbragstadok - as soon as we get a bug open, i can swing over to -releases and -requirements and get a feel for things17:28
imacdonnkmalloc: not sure that WAIT states can help .. the connections are all ESTABLISHED17:28
kmallocimacdonn: but connections drop out as the requests in eventlet drop17:29
kmallocso probably some tuning there.17:29
kmallocor... they don't use caching17:29
kmallocit's amazing how many installs dont17:29
kmallocOR worse.. they use in-process cache17:29
imacdonnI didn't have it configured properly for a while .. it made quite a difference when I got it right17:29
imacdonnbut then I ran into this next hurdle (with my largest deployment)17:30
* lbragstad needs to write that doc17:30
kmalloclbragstad: yeah ok i found the bug... someone got too clever, looking into the git blame now17:32
kmallocand will open a bug shortly17:32
imacdonnkmalloc: confused on the tuning thing .... is there some way to manipulate how long the connections are held in the non-pool case? It seems like most of the config options pertain to the pool17:32
kmalloci am unsure how we will logistically test this.17:32
kmalloclbragstad: i guess i just need to mock the hell out of things.17:32
kmalloclbragstad: *grump*17:32
kmallocimacdonn: i think eventlet can be mucked with in weird ways to force faster reaping of data in the thread locals17:33
kmallocimacdonn: but honestly, i try not to think about eventlet... this is a MAJOR reason keystone dropped eventlet17:33
kmallocimacdonn: we almost require caching.17:33
*** vrv_ has quit IRC17:33
*** timothyb89_ is now known as timothyb8917:35
*** tesseract has quit IRC17:35
imacdonnkmalloc: yeah ... so back from the hard place to the rock :)17:37
*** jdennis has quit IRC17:37
kmallocso, here is the quick fix to try in your lab17:37
kmallocand i'm writing up a bug.17:37
*** jdennis has joined #openstack-keystone17:37
kmallocchange KSM code: change the hanging reserve() method to be:17:37
kmalloci don't think .get() is working as a context manager the way we expect17:39
imacdonnok, working on that17:39
*** spilla has joined #openstack-keystone17:42
*** spilla_ has quit IRC17:42
imacdonnI actually see connections to memcached now ... one connection per neutron-api worker process17:42
kmallocso, i have NO idea how this isn't throwing errors all over the place right now.17:44
imacdonnno lockups so-far ... I have a loop running continually hitting neutron-api with a request that requires auth17:44
kmallocnot the fixed one17:44
kmallocthe current code base17:44
openstackgerritMerged openstack/keystone master: Switch to python-ldap
kmalloclbragstad, cmurphy: ^ if that is the case, ldappool also needs an update17:45
*** r-daneel has quit IRC17:45
imacdonnwell, the Queens code has a couple of other issues (those two bugs I mentioned yesterday) ... I suspect that no one is actually using the pool implementation :/17:45
kmallocimacdonn: as i said, sadly if "it isn't tested it is broken" is the case for most code17:46
kmallocso i'm checking a few more things, but it seems like acquire is the right entry17:46
*** r-daneel has joined #openstack-keystone17:47
kmalloclbragstad: looking17:50
kmallocalready commented17:50
*** clarkb has joined #openstack-keystone17:50
lbragstadyep - i should have looked before sending that17:50
clarkbgithub would like keystone to know that pysaml2 should be set to >= 4.5.017:51
kmallocclarkb: in lower-constraints? sure. we can spin that up shortly17:51
kmallocclarkb: thanks.17:51
clarkbrequirements.txt but will affect lower constraints too17:51
kmallocah wait... we have minimums in requirements.txt? i can't keep track of what goes in reqs17:52
kmallocvs what goes in *-contstraints17:52
clarkbreading your requirements file doens't really make sense vs what they emailed me about17:52
clarkbI think their new python dep checking must be buggy17:52
clarkbpysaml2>=4.0.2,!=4.0.3,!=4.0.4,!=4.0.5,!=4.0.5rc1,!=4.1.0,!=4.2.0,!=4.3.0,!=4.4.0 is our requirement line17:52
lbragstadwe explicity exclude a bunch17:53
clarkboh its that less than 4.5 is buggy17:53
kmallocthat looks sane[ish]17:53
clarkbso they want us to prop up the minimum17:53
*** r-daneel_ has joined #openstack-keystone17:53
lbragstadbut ultimately the first bit should cover us, yeah?17:53
kmallocgot it17:53
*** r-daneel has quit IRC17:53
*** r-daneel_ is now known as r-daneel17:53
kmallocright and thye want >=4.5.017:53
lbragstadto me, what we have should be fine?17:54
kmallocthey want the minimum higher17:54
kmalloclbragstad: i did the exact same thing man17:54
clarkbbecause of moderate security issue in 4.4017:54
clarkber 4.4.017:54
kmallocwhich is fair17:54
kmalloci'm 100% ok with bumping the minimum as long as it wont break/cause issues with anyone17:54
openstackgerritLance Bragstad proposed openstack/keystone master: Bump lower constraint for pysaml2 to 4.5.0
*** dklyle has joined #openstack-keystone17:55
lbragstadi need to fill out the commit message with details17:55
clarkblbragstad: "Known moderate severity security vulnerability detected in pysaml2 <=4.4.0 defined in requirements.txt. " says github17:55
kmallocimacdonn, lbragstad:
openstackLaunchpad bug 1782404 in keystonemiddleware "keystonemiddleware doesn't work with memcachepool" [High,Triaged] - Assigned to Morgan Fainberg (mdrnstm)17:56
kmalloclbragstad: just proposing to the stable branches is sufficient, ya? [ksm]17:56
kmallocfor the backport17:56
openstackgerritLance Bragstad proposed openstack/keystone master: Bump lower constraint for pysaml2 to 4.5.0
imacdonnkmalloc: thanks!17:57
kmallocimacdonn: i think i gave correct credit to you in the bug report17:57
kmallocfeel free to fix that if i did not17:57
lbragstadkmalloc: sweet17:57
kmallocnow let me write a test for this...17:58
kmallocat least synthetic for the memcachepool17:58
imacdonnI guess I'll try to cherrypick those other two fixes to Queens18:00
*** dklyle has quit IRC18:01
kmallocif those fixes are needed for queens we should propose backports18:01
imacdonn and
imacdonnyes, that's what I meant by cherrypick18:01
imacdonnbah .. merge conflict on the second one .. I'm going to need coffee first ;)18:03
imacdonndo ksm proposed changes not get posted here?18:04
* imacdonn pokes openstack in the ribs18:04
kmallocnot backports18:04
kmalloconly master18:04
kmallocsame as with keystone18:04
lbragstadkmalloc: you don't have a patch proposed to master for the ksm bug you just reported, do you?18:06
kmallocno, working on the tests for it now18:06
kmallocwill be posted shortly18:06
lbragstadok - not trying to rush you18:06
lbragstadjust trying to track things we need to land before tomorrow so we can cut ksm and ksa for rocky18:07
*** pcaruana has quit IRC18:08
knikollalbragstad: responded (wrt ksm docs patch)18:10
lbragstadknikolla: thanks18:11
*** itlinux has joined #openstack-keystone18:13
lbragstadso far - these are the things i think we should land before tomorrow if possible18:15
lbragstadi'll add kmalloc's ksm patch to that list as soon as it is available18:15
*** dklyle has joined #openstack-keystone18:27
kmallocposting soon.18:28
kmallocrunning pep818:28
gagehugolbragstad: looking18:29
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Fix KeystoneMiddleware memcachepool abstraction
*** itlinux has quit IRC18:31
imacdonnkmalloc: urgh, your fix is going to further merge-conflict with this:
imacdonnfor Queens backports, I mean18:34
*** itlinux has joined #openstack-keystone18:34
kmallocimacdonn: i am working on backports now18:35
kmallocimacdonn: checking tests before posting.18:35
imacdonnI guess it won't conflict if I can get that one backported first .. oh, are you backporting the other fixes too ?18:35
kmallocjust mine18:35
kmallocbut the backports can happen in any order18:35
imacdonnI already got this one started:
kmallocfor queens18:36
kmalloc for pike18:38
kmalloclbragstad: ^18:39
kmalloclbragstad: i'll leave it to you to setup release reviews to include these fixes.18:40
openstackgerritMerged openstack/keystonemiddleware master: Document endpoint interface and region behavior
lbragstadkmalloc: a release note for the connection pooling patch would be ++18:43
lbragstadotherwise the patch looks sane18:43
lbragstadimacdonn: are you able to verify ^18:43
kmallochmm. ok18:44
kmalloci am *not* backporting a release note fwiw.18:44
kmallocso i guess it was good i did it in this order18:44
imacdonnI'm all tangled up in the other change right now18:44
imacdonn <= this removed the use of "with"18:45
kmallocimacdonn: my fix solves that as well18:45
kmallocso that doesn't need to be backported if my fix is landing18:45
imacdonnright, ok .. that's what I was trying to figure out18:46
kmallocyep :)18:46
lbragstaddoes _pool  still not have an __exit__?18:46
kmallocit doesn't need one18:47
kmalloc_pool.acquire() is a context manager18:47
lbragstadbecause it's using .aquire()?18:47
kmalloc*THAT* was the fix that should have been, not just removing with18:47
kmallocremoving with is what got us into this broken-ness18:47
kmallocinstead of fixing to call the context manager18:48
lbragstadthisis only in master
kmallocand the fix made reserve() hang18:48
lbragstadso we're fixing it in rocky, which is good18:48
kmallocthe correct fix would have been -> make it use acquire() not "remove the with" context18:49
* kmalloc glares at the release note command18:49
lbragstadbut we wont have a gap where we're letting the broken behavior slip through a release18:49
kmallocright, we just previously had the whole system error when being used18:50
kmalloci dunno, both seem super broken to me18:50
lbragstadyeah - but we won't have a broken rocky release18:50
lbragstador a queens release18:50
kmallocwell.. uh18:52
kmallocre have a broken queens release18:52
kmallocno __exit__ :P18:52
kmallocand a broken pike release18:52
imacdonncurrent queens releases are broken ... but kmalloc's patch will fix it .. it's just that the fix looks slightly different for queens vs master18:52
lbragstadbut we just need kmalloc's backport18:53
imacdonndue to the other "fix" not having been backported18:53
*** harlowja has joined #openstack-keystone18:54
openstackgerritMorgan Fainberg proposed openstack/keystonemiddleware master: Fix KeystoneMiddleware memcachepool abstraction
kmalloclbragstad: ^ with release note18:57
*** dklyle has quit IRC19:23
*** felipemonteiro_ has joined #openstack-keystone19:24
*** felipemonteiro_ is now known as felipemonteiro19:24
openstackgerritBen Nemec proposed openstack/oslo.policy master: Avoid redundant policy syntax checks
*** felipemonteiro_ has joined #openstack-keystone19:30
*** felipemonteiro has quit IRC19:33
openstackgerritBen Nemec proposed openstack/oslo.policy master: Avoid redundant policy syntax checks
*** felipemonteiro_ has quit IRC19:50
*** felipemonteiro_ has joined #openstack-keystone19:50
*** flwang1 has quit IRC19:54
*** itlinux has quit IRC20:09
openstackgerritGage Hugo proposed openstack/ldappool master: Switch to python-ldap again
gagehugocmurphy kmalloc
mordredkmalloc: wanna see a weird bug?20:26
mordredkmalloc: I'm not sure if it's sdk or ksa yet ...20:26
*** martinus__ has quit IRC20:30
*** r-daneel has quit IRC20:31
openstackgerritMerged openstack/keystone master: Add project_id filter for listing limit
*** jmlowe has quit IRC20:36
mordredkmalloc: oh - wait - does v3password auth plugin skip discovery?20:37
*** itlinux has joined #openstack-keystone20:37
*** dklyle has joined #openstack-keystone20:39
*** r-daneel has joined #openstack-keystone20:40
*** itlinux has quit IRC20:42
*** felipemonteiro__ has joined #openstack-keystone20:48
*** felipemonteiro_ has quit IRC20:52
*** flwang1 has joined #openstack-keystone20:58
*** raildo has quit IRC21:06
openstackgerritGage Hugo proposed openstack/keystone master: Expose random uuid bug in cadf notifications
*** felipemonteiro__ has quit IRC21:07
*** felipemonteiro__ has joined #openstack-keystone21:07
*** felipemonteiro__ has quit IRC21:28
lbragstadrelated bug
openstackLaunchpad bug 1782434 in keystoneauth "passwordv3 plugin doesn't implement discovery" [Undecided,New]21:28
*** dklyle has quit IRC21:42
*** dklyle has joined #openstack-keystone21:45
*** david-lyle has joined #openstack-keystone21:53
*** dklyle has quit IRC21:54
*** edmondsw has quit IRC21:54
*** elibrokeit has quit IRC22:00
kmallocmordred: oh fun.22:01
kmallocmordred: yeah v3 should skip, it should know it's already v322:01
*** linkmark has joined #openstack-keystone22:03
imacdonnkmalloc: FYI, trying to enable the "advanced pool" on Pike produces a different failure, prob similar to the "arguments" one for Queens - haven't dug into it too much yet -
kmallocimacdonn: yep22:07
kmallocimacdonn: that would be my guess22:07
kmallocsomething weird for sure22:07
imacdonnlooks kinda sorta like
openstackLaunchpad bug 1440493 in keystonemiddleware "Crash with python-memcached==1.5.4" [Undecided,In progress]22:14
*** ztrawhcse has joined #openstack-keystone22:15
cmurphythanks gagehugo22:17
*** ztrawhcse is now known as elibrokeit22:17
*** jmlowe has joined #openstack-keystone22:24
*** jmlowe has quit IRC22:25
*** gongysh has joined #openstack-keystone22:25
*** jmlowe has joined #openstack-keystone22:26
*** lbragstad has quit IRC22:29
*** david-lyle has quit IRC22:31
*** rcernin has joined #openstack-keystone22:32
*** imacdonn has quit IRC22:44
openstackgerritMerged openstack/ldappool master: Switch to python-ldap again
*** imacdonn has joined #openstack-keystone22:45
*** jmlowe has quit IRC22:58
*** jmlowe has joined #openstack-keystone22:58
*** itlinux has joined #openstack-keystone23:04
*** jmlowe has quit IRC23:05
*** dklyle has joined #openstack-keystone23:09
imacdonnkmalloc: It looks like the following didn't make it into ksm. Applying the change seems to work. Thoughts?
kmallocMost of that is in oslo_cache23:13
imacdonnpost-Pike, you mean ?23:13
kmallocLooks like we might be doa in Pike. But we can land that still to make it work.23:14
imacdonnI'm contemplating whether I want to make it work with Pike, or use it as leverage to get the Ops team to do the upgrade to Queens23:15
*** itlinux has quit IRC23:16
imacdonnis there process for getting a fix into a "stable" release, when it's not a backport?23:18
*** tosky has quit IRC23:20
kmallocproposing the fix, usually needs to land in master, but this case a bug and fix specific for the release is fine23:20
kmallocthen the stable team will evaluate it23:20
kmallocbasically lbragstad[m] and myself are stable-core for keystone.23:20
imacdonnright, ok23:21
kmallocchances are, as long as it doesn't break anything, we can fix it.23:21
imacdonnI applied the same fix as in the above URL, and it seems to be working fine (along with your acquire() fix)23:21
imacdonnI'll do a bug and proposed fix, and you guys can decide if you like it ....23:22
*** itlinux has joined #openstack-keystone23:28
*** jmlowe has joined #openstack-keystone23:37
*** threestrands has joined #openstack-keystone23:50
*** threestrands has quit IRC23:50
*** threestrands has joined #openstack-keystone23:50

Generated by 2.15.3 by Marius Gedminas - find it at!