Monday, 2019-02-18

openstackgerritMerged openstack/octavia master: Speed up pylint by using multiple cores
openstackgerritMerged openstack/neutron-lbaas master: Fix the neutron-lbaas-to-octavia-migration job
*** sapd1 has joined #openstack-lbaas00:58
*** Dinesh_Bhor has joined #openstack-lbaas01:55
*** Dinesh_Bhor has quit IRC02:11
*** Dinesh_Bhor has joined #openstack-lbaas02:21
*** psachin has joined #openstack-lbaas02:51
*** sapd1 has quit IRC03:07
*** hongbin has joined #openstack-lbaas03:10
*** sapd1 has joined #openstack-lbaas03:23
*** ramishra has joined #openstack-lbaas04:07
*** sapd1 has quit IRC04:48
*** sapd1 has joined #openstack-lbaas05:00
rm_workyeah IMO abandon changes from 99cloud and inspur that aren't useful, they are running scripts to try to boost their commit stats, and usually bring no value (and won't respond to anything)05:09
*** hongbin has quit IRC05:42
openstackgerritReedip proposed openstack/octavia-tempest-plugin master: Check Monitor in Member Scenario Tests
*** AlexStaf has quit IRC06:20
*** yboaron_ has quit IRC07:02
*** ccamposr has joined #openstack-lbaas07:11
*** ccamposr__ has joined #openstack-lbaas07:12
*** ccamposr has quit IRC07:15
*** gcheresh has joined #openstack-lbaas07:20
*** pcaruana has joined #openstack-lbaas07:43
*** yboaron_ has joined #openstack-lbaas08:02
*** yboaron_ has quit IRC08:06
*** yboaron_ has joined #openstack-lbaas08:07
*** AlexStaf has joined #openstack-lbaas08:12
*** rpittau has joined #openstack-lbaas08:17
cgoncalvesrm_work, your message passed spell check. congrats!08:19
*** fnaval_ has quit IRC08:34
*** fnaval has joined #openstack-lbaas08:44
*** fnaval has quit IRC08:49
*** pcaruana|afk| has joined #openstack-lbaas09:01
*** pcaruana has quit IRC09:02
*** ramishra has quit IRC09:05
*** ramishra has joined #openstack-lbaas09:09
*** ramishra_ has joined #openstack-lbaas09:21
*** ramishra has quit IRC09:23
*** ltomasbo has joined #openstack-lbaas09:32
*** sapd1 has quit IRC09:33
*** trident has joined #openstack-lbaas09:38
openstackgerritReedip proposed openstack/octavia-tempest-plugin master: Check Monitor in Member Scenario Tests
*** sapd1 has joined #openstack-lbaas09:49
*** pcaruana|afk| has quit IRC10:01
*** ramishra_ has quit IRC10:06
*** pcaruana has joined #openstack-lbaas10:07
*** ramishra has joined #openstack-lbaas10:09
openstackgerritzhulingjie proposed openstack/neutron-lbaas master: Update hacking version to 1.1.0
*** ipo has joined #openstack-lbaas10:23
*** numans has joined #openstack-lbaas10:24
ipoHello all !!!10:24
*** salmankhan has joined #openstack-lbaas10:24
ipoPlease help me to understand more smoothly octavia config parameters for health check10:26
ipoheartbeat_interval is the interval to send HB packets from amphorae.10:27
*** salmankhan has quit IRC10:29
iposo if octavia didnt received HB packet within heartbeat_timeout from amphora it moves LB to helthy amphora and kill original one ?10:33
rm_workthat's a good summary10:49
*** cgoncalves has quit IRC10:52
openstackgerritMerged openstack/octavia-tempest-plugin master: Update the live jobs to set higher retries
*** cgoncalves has joined #openstack-lbaas10:56
ipook, in this case what is it health_check_interval ?11:14
ipois this option connected with amphorae healthcheck ?11:15
rm_workthat is deployed TO the amphora's config11:19
rm_workso that's how often it broadcasts its health status packet11:19
rm_work(in seconds)11:19
*** Dinesh_Bhor has quit IRC11:20
ipoI thought it is about heartbeat_interval11:20
ipoit is 10 secs by default11:21
rm_workerr hold on11:21
rm_worksorry, half-paying attention and misread that11:21
rm_workhealth_check_interval is how often it actually CHECKS to see if the status is bad for a failover11:22
ipoSo for example each 3 secs it check state of amphorae, so after 60 secs of HB timeout in next 3 sec interval healthcheck will find amphora is down ?11:22
ipook, this is clear. Is it the same behavior  for SINGLE and ACTIVE_STEND modes ?11:25
iposo the failover will be managed on the same way (as I remember ACTIVE_STEND will failover much faster), but heartbeat_timeout is 60 secs...11:31
*** ipo has quit IRC11:35
*** ipo has joined #openstack-lbaas12:03
*** ipo has quit IRC12:09
openstackgerritNir Magnezi proposed openstack/octavia master: Refactor the unplugging of the VIP
*** trown|outtypewww is now known as trown13:06
openstackgerritCarlos Goncalves proposed openstack/octavia-tempest-plugin master: Add active/standby scenario test
*** yboaron_ has quit IRC14:04
*** yboaron_ has joined #openstack-lbaas14:04
*** psachin has quit IRC14:28
*** fnaval has joined #openstack-lbaas15:02
*** yboaron_ has quit IRC15:26
*** gcheresh has quit IRC15:54
*** AlexStaf has quit IRC16:08
*** pcaruana has quit IRC16:10
*** ramishra has quit IRC16:13
*** ramishra has joined #openstack-lbaas16:17
*** ramishra has quit IRC16:42
cgoncalvesCI is really in a bad mood. grenade queens to rocky runs fine locally, too17:00
cgoncalvesthat vs
johnsomThat is an interesting one. It implies we have an amp-agent issue, but that is hard to confirm. This is happening in rocky only?17:11
johnsomAre we sure you have the rocky image in your local setup?17:11
cgoncalvesstable/rocky only yes, but where it fails it is still pre-upgrade so queens17:12
cgoncalvesgrenade runs the octavia devstack plugin so it builds the amp (which is queens-based)17:12
cgoncalvesrunning ubuntu xenial, just like in CI17:13
johnsomOh, ok, so queens image, rocky controller?17:13
johnsomOr queens-queens?17:13
cgoncalveswhen it fails it still is queens-queens17:13
johnsomhmmmm, ok, now that is odd.17:13
cgoncalvesmega odd17:14
johnsomI see our queens gates are passing as of two days ago....17:15
cgoncalvesright, they have always passed17:16
cgoncalvesthe problem is octavia-grenade in stable/rocky17:16
*** rpittau has quit IRC17:16
johnsomHmmm, darn, we don't save the DIB logs in that job17:16
*** ccamposr__ has quit IRC17:18
*** rpittau has joined #openstack-lbaas17:19
johnsomcgoncalves Do you have an idea of when this started to fail?17:20
cgoncalvesjohnsom, december 14-1717:22
johnsomHmm, we haven't really touched that area of the agent since August 6th17:23
*** rpittau has quit IRC17:26
johnsomAh, we did touch os utils the week before that.  Let me review that.17:27
*** AlexStaf has joined #openstack-lbaas17:47
*** sapd1 has quit IRC17:59
*** trown is now known as trown|lunch18:01
*** trown|lunch is now known as trown19:06
*** hongbin has joined #openstack-lbaas19:36
*** hongbin has quit IRC19:43
*** rcernin has joined #openstack-lbaas21:40
*** trown is now known as trown|outtypewww22:02
*** fnaval has quit IRC22:06
*** fnaval has joined #openstack-lbaas22:11
* johnsom Head bangs...22:29
johnsomThis unset ACLs for barbican is a mess22:30
johnsomWhy do we care?22:30
johnsomRight now, if a ref is used as a default cert on one listener and as a sni cert on another, and the default cert listener is deleted, we no longer have access to the cert for SNI use22:31
johnsomNot to mention it's not thread safe in the least22:32
openstackgerritMichael Johnson proposed openstack/octavia master: Fix the lose of access to barbican secrets
rm_workjohnsom: erg, forgot to check SNI22:57
rm_workmy bad prolly22:57
rm_workchecked if it was still in use as a listener cert but not SNI T_T22:57
johnsomYeah, It's a nasty cross use problem that is going to get worse with the more TLS features. I think it is best to just leave the ACL in place22:58
rm_workBTW, is it possible to control how many threads are used for unit test running?22:58
rm_worklike in tox.ini maybe22:58
rm_workjohnsom: erg, that's... i mean i guess... but... eugh22:58
johnsomI think so22:58
rm_worknot exactly the best security feeling22:58
johnsomWell, as it is written right now it's not thread safe either22:59
rm_worki guess it's running stestr22:59
rm_workso i'd need to add stestr args22:59
rm_workah yeah true :/23:00
johnsomon stestr23:00
johnsomYou need to dial it back?23:01
rm_workthis is for nova, i'm hitting test issues in our gate which runs like freaking 16 at once23:01
rm_workwhere one thread mysteriously dies every time23:01
johnsomYeah, so with the bug, the threading issue, and that it has no test coverage, my vote is to nuke it23:02
rm_worktrying to see if dialing it back to what my machine does locally helps23:02
openstackgerritMichael Johnson proposed openstack/octavia master: Fix the loss of access to barbican secrets
rm_workyeah i ... can't really object23:04
rm_worki'm not sure how we'd fix a concurrency issue23:04
rm_workcan't lock something we don't even know about23:04
johnsomYeah, that is what makes it a bit hard23:04
rm_worksince it could be adding the same cert to a different LB23:05
rm_workand we can't know that23:05
rm_worki guess we could have like a....23:05
rm_workcert lock table23:05
rm_workugh that gets messy lol23:05
johnsomRight, you could create a critical region in the code, but....23:05
rm_workyeah it's not the best, but i think i'm with you]23:05
rm_workthough i believe someone could say it's laziness at the cost of security <_<]23:06
johnsomI would not argue that with them23:08
johnsomThough I think the risk is fairly low23:08
rm_workwhich is why i'm not up in arms23:10
rm_workthere's ... worse problems23:11
* rm_work shrugs23:11
rm_workthough that's not ideal logic <_<23:11
rm_workbroken window? i forget23:11
rm_workah no that's a financial thing23:12
johnsombroken arrow?23:12
johnsomI should have the bulk of the TLS client auth code cleaned up today.23:15
rm_workk, you'll be wanting reviews i guess :P23:17
rm_workpoke me at the start of the chain when you're ready23:17
johnsomI want a bunch of reviews. I'm going to re-organize the review list today/tomorrow by deadlines23:18
johnsomNext week is non-client libraries, week after is feature freeze for everything else23:18
rm_workwow already?23:19
johnsomIf you have a few minutes:
eanderssonjohnsom, rm_work lets get this merged :p
eanderssonSo I can rebase tomorrow when we are back in the office =]23:21
rm_worki'm not going to vote on it :P other than +123:22
rm_worki think your nit is correct tho <_<23:22
rm_worktempted to fix it...23:23
eanderssondo it23:23
rm_worki mean, should i also have "if Transport is not None" for the others?23:25
rm_worki guess that is ...23:25
eanderssonbut not as important23:25
rm_workrunning tests locall23:27
openstackgerritAdam Harwell proposed openstack/octavia master: Fix oslo messaging connection leakage
johnsomeasndersson FYI, the oslo folks are also looking at if they can make a change on the messaging side to improve the situation.23:30
johnsomIt was discussed at today's meeting23:30
eanderssonYea - they highlighted me a few times23:30
rm_workso i'll leave it up to another core to +223:30
rm_workah and cgoncalves needs to refresh his23:30
johnsomI am a bit concerned about what else isn't getting closed in those API threads.23:31
rm_workeandersson: the thing that tipped it for me BTW was this:
rm_worki mentioned it earlier in chat but forgot to post on the patch23:35
rm_worki should do that for posterity23:35
johnsomYeah, that would be good23:35
rm_workwhich ... thanks VSCode for showing me that error there, pycharm hadn't been23:36
rm_workbut vscode includes all the bandit results inline :P23:37
rm_workwhich is pretty cool23:37
johnsomJoy, somehow I have managed to make flake8 crash....23:38
eanderssonSure - but assertion can be fixed like this
rm_workjohnsom: i think even more important than pylint concurrency might be flake8 concurrency <_<23:40
rm_workmight solve it being stupidly slow for me, testing23:40
eanderssonIt's not really arguing the change that you emphasized on with your "singleton" pattern23:40
rm_workeandersson: asserts there may not work23:41
eanderssonbut honestly I am so over this dicussion23:41
eanderssonYou guys do what ever you want23:41
rm_workthey are completely ignored when compiled to bytecode23:41
*** eandersson has left #openstack-lbaas23:41
rm_workah yeah, that is a workaround23:45
johnsomHmm, flake8 doesn't seem too bad to me.23:46
johnsomTheir -j flag doesn't seem to do much for me. The pylint helps for me.23:47
johnsomBut I think they are all mostly IO bound to some degree23:47
rm_workhmm i'm on SSD, you?23:48
johnsomSome SSD some NAS23:48
rm_workhmm, the flake8 step doesn't print time23:49
rm_workso i'm gonna run timing tests on my own now23:49
rm_workyeah even with -j0 my CPU doesn't really increase with pep8 tests23:50
johnsomOn pylint with -j 0 it lights up my cores23:51
rm_workyeah i feel like it isn't working23:54
rm_worki still see only one python process using one core23:54
johnsom-j on flake8 seems to do nothing23:54
johnsomflake8 for me gives: real    0m25.128s23:54
rm_workreal    0m45.509s23:56
johnsompylint with the -j change: real    0m35.466s23:56
rm_workah --benchmark23:56
rm_workis nice23:56
rm_workyeah -j does not seem to be doing anything23:57
johnsomWithout -j on pylint: real    1m10.667s23:57
rm_workah it defaults to auto anyway23:58
johnsomYeah, but if I even put in -j 6 on flake, it doesn't use them23:59
rm_worknoticing the same23:59

Generated by 2.15.3 by Marius Gedminas - find it at!