Tuesday, 2018-05-15

*** longkb has joined #openstack-lbaas00:23
rm_workjohnsom: ever used multitail? omg00:42
bzhao__johnsom: ping00:44
bzhao__Hi micheal, thanks for review udp patches, but I think it's better to access with you. So I just want to discuss how to fit the requirement of both. And willing to get your kind opinion.00:44
bzhao__template part00:44
bzhao__https://review.openstack.org/#/c/525420/15/octavia/common/jinja/lvs/jinja_cfg.py00:44
bzhao__For my thought, another jinja_cfg for keepalivedlvs may be good for split them, as the target file and the function processer are different. Another benefit is the split process.00:44
bzhao__agent part00:44
bzhao__https://review.openstack.org/#/c/529651/17/octavia/amphorae/backends/agent/api_server/keepalivedlvs.py00:44
bzhao__For the member's 'no check' status during get_udp_listener_status, your suggestion is to check the lvs running status for setting it, right?00:44
bzhao__service part00:45
bzhao__https://review.openstack.org/#/c/539391/8/octavia/api/v2/types/health_monitor.py00:45
bzhao__For removing the default value of health_monitor requests, sorry for confused. As if users don't specify the fields "http_method", "url_path", "expected_codes" in UDP request, the generated Post obj will still contains these fields, it is contradictory in the udp spec which we not allowed this kind request.00:45
bzhao__Sorry for fresh the screen.00:46
johnsombzhao__: give me 5 minutes and I can chat00:47
bzhao__johnsom:  Thank you. :)00:47
johnsombzhao__ Hi.  Ok, let's chat.  So, I read through your responses today, but didn't get to respond yet.  But this is even better00:52
johnsomOn the jinja template. I think I just got myself confused.  I agree the keepalived template should have it's own jinja_cfg.00:52
johnsomHowever, I do think we need  to clean it up and only have values that matter for the keepalived template.  This was part of what led to my confusion, so I'm sure it will be an issue for others.00:53
johnsomMaybe I am mistaken, but I don't think you need all of those values. I did not get a chance to match them against the macros.00:55
johnsombzhao__ Did I just mis-interpret? Are all of those values used in the keepalived jinja template?00:57
johnsomLike line 163, 'peer_port': listener.peer_port, I don't see that variable in the jinja macros00:58
*** threestrands has quit IRC01:00
bzhao__johnsom: Thanks, you are right. I follow u now. It's sure that the part not used in lvs jinjia.  I will remove them .01:03
johnsomOk, cool, yeah, just a little cleanup there should be good.01:03
bzhao__johnsom: ha01:04
johnsomOk, second topic01:04
johnsomYes, with the TCP protocol we provide monitoring information back to the user via the "operating" status.  I wanted to research today if there was a way we can provide the same actual health information with the UDP listener.01:05
johnsomI was thinking there might be a /sys or /proc filesystem place we can look at that.01:05
johnsomI'm pretty sure lvsadm can provide those status, so there is some way. Hopefully something nicer than running lvsadm01:06
bzhao__johnsom:   Thanks for suggest. I will take a deep look into how to check the status also. And discuss with u tomorrow.01:07
bzhao__johnsom:  Yeah, I also think if we run the lvsadm cmd directly is not suitable for this patrt01:07
johnsomsorry, I meant ipvsadm, but yeah, command line is not the best.  I will also research this more.01:10
bzhao__johnsom:  Oh, sorry for the typo.01:10
johnsomNo, I think that was my typo...01:11
johnsomhttp://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.monitoring_lvs.html01:12
johnsomThat looks like an interesting place to start01:12
bzhao__Thanks very much, micheal. The pain point is the 3rd part. How to fit the API level? I also don't want to change our existing API default value.  But seems not other good way to match the invalid udp requests.01:14
johnsomOk, give me a minute to re-read this and think about it.01:14
johnsomSo my expectation for those three fields is we handle them the same as TCP.  Let me look at the code.01:16
*** longkb has quit IRC01:17
*** longkb has joined #openstack-lbaas01:17
*** yamamoto has joined #openstack-lbaas01:18
johnsombzhao__ Yeah, this is an anomaly in our code. Even a TCP health monitor gets those defaults even though they are not used.  I will create a patch to fix this.  Please leave the defaults as they are and my patch will decide how to fix this in the API controller code.01:22
johnsomhttps://www.irccloud.com/pastebin/v2l3IOzy/01:22
bzhao__Yeah,  I wrote it like now for raising something. :). I'm sure that it maybe bad.01:22
bzhao__Thanks.01:23
johnsomYeah, leave that one for me, I will fix it.01:23
bzhao__Thank you. Micheal. I will depend on your provider support patch for re-construct the udp part also. :)01:24
johnsombzhao__ Any other questions for today?01:24
johnsomOh, yeah, it's a bit of a big change, but very necessary.01:24
bzhao__no more.  Thank you for clear and huge help to me.01:25
*** yamamoto has quit IRC01:25
johnsomBTW, I am putting down UDP support as a Rocky feature on my OpenStack Summit slides. It's a good feature.01:25
bzhao__Yeah, that's very necessary.01:25
johnsomI look forward to trying it out once the file path issue is resolved.01:25
bzhao__I mean the provider support01:25
bzhao__haha.01:26
bzhao__I will fix asap.01:26
johnsomRight now I have to jump between tasks, so I will do a review as far as I can, then switch.  Great, thank you.01:26
bzhao__OK, Thanks for your time.  Take a good rest after work. :)01:27
johnsomThanks!  Time to make dinner01:27
*** yamamoto has joined #openstack-lbaas01:41
*** yamamoto has quit IRC01:46
*** yamamoto has joined #openstack-lbaas02:02
*** yamamoto has quit IRC02:06
*** ivve has joined #openstack-lbaas02:09
*** xuhaiwei has joined #openstack-lbaas02:18
*** yamamoto has joined #openstack-lbaas02:23
*** yamamoto has quit IRC02:29
*** yamamoto has joined #openstack-lbaas02:45
*** rcernin has quit IRC02:46
*** yamamoto has quit IRC02:50
*** rcernin has joined #openstack-lbaas02:50
*** yamamoto has joined #openstack-lbaas03:06
*** yamamoto has quit IRC03:10
*** yamamoto has joined #openstack-lbaas03:27
*** yamamoto has quit IRC03:33
*** links has joined #openstack-lbaas03:37
*** yamamoto has joined #openstack-lbaas03:50
*** yamamoto has quit IRC03:54
*** gans has joined #openstack-lbaas04:10
*** longkb has quit IRC04:12
*** yamamoto has joined #openstack-lbaas04:12
*** gans has quit IRC04:12
*** longkb has joined #openstack-lbaas04:12
*** yamamoto has quit IRC04:17
*** annp has quit IRC04:18
*** annp has joined #openstack-lbaas04:18
*** pcaruana has joined #openstack-lbaas04:31
*** yamamoto has joined #openstack-lbaas04:33
*** yamamoto has quit IRC04:33
*** yamamoto has joined #openstack-lbaas04:35
*** linhnm has joined #openstack-lbaas04:38
*** dayou has quit IRC04:53
*** linhnm has quit IRC05:04
*** AlexStaf has quit IRC05:09
*** linhnm has joined #openstack-lbaas05:26
*** dayou has joined #openstack-lbaas05:26
*** yboaron has joined #openstack-lbaas05:39
*** linhnm has quit IRC05:56
*** kobis has joined #openstack-lbaas06:17
*** linhnm has joined #openstack-lbaas06:22
*** kobis has quit IRC06:52
*** rcernin has quit IRC07:13
*** tesseract has joined #openstack-lbaas07:13
*** yamamoto_ has joined #openstack-lbaas07:15
*** pcaruana has quit IRC07:17
*** pcaruana has joined #openstack-lbaas07:17
*** pcaruana has quit IRC07:18
*** yamamoto has quit IRC07:18
*** pcaruana has joined #openstack-lbaas07:23
*** annp has quit IRC07:28
*** linhnm has quit IRC07:36
*** AlexeyAbashkin has joined #openstack-lbaas07:36
*** kobis has joined #openstack-lbaas07:42
*** salmankhan has joined #openstack-lbaas08:23
*** salmankhan has quit IRC08:59
*** salmankhan has joined #openstack-lbaas09:06
*** linhnm has joined #openstack-lbaas09:11
*** devfaz has quit IRC09:33
*** devfaz has joined #openstack-lbaas09:34
*** annp has joined #openstack-lbaas09:41
*** linhnm has quit IRC09:42
*** kobis has quit IRC09:45
openstackgerritMerged openstack/octavia master: Devstack plugin: Check for IPv6 support  https://review.openstack.org/56757809:49
*** kobis has joined #openstack-lbaas10:17
openstackgerritVadim Ponomarev proposed openstack/octavia master: Add a soft check for the allowed_address_pairs extension.  https://review.openstack.org/56854610:22
*** tesseract is now known as info10:41
*** info is now known as tesseract10:41
*** xuhaiwei has quit IRC10:48
*** atoth has joined #openstack-lbaas11:20
*** longkb has quit IRC11:29
*** samccann has joined #openstack-lbaas11:56
*** kobis has quit IRC12:08
*** kobis has joined #openstack-lbaas12:13
*** numans has quit IRC12:31
*** numans has joined #openstack-lbaas12:35
openstackgerritVadim Ponomarev proposed openstack/octavia master: Add a soft check for the allowed_address_pairs extension.  https://review.openstack.org/56854613:02
*** rpittau has quit IRC13:02
*** kobis has quit IRC13:57
mnaserhey everyone14:46
xgerman_o/14:46
mnaserso at the summit, there might be a keynote demo, and it might have octavia with k8s :)14:46
mnaserand i'm just running it through to show off how loadbalancer resources in k8s create actual load balancers in openstack14:46
mnasereverything works, but in the dashboard, the operating status of the load balancer is 'Offline'14:47
mnaseris there a reason behind this?  i'd rather people not see that as it might give "oh this isn't real" type of feeling14:47
xgerman_mmh, my k8s LB are ACTIVE/online14:49
xgerman_k8s has a tendency to move members around so I cycle through DEGRADE/ERROR soem times14:50
mnaserhttps://usercontent.irccloud-cdn.com/file/7KXNAyrh/Screen%20Shot%202018-05-15%20at%2010.50.19%20AM.png14:50
mnaseris there something that maybe we have misconfigured that might be leaving them in offline operating status?14:51
johnsommnaser: I have an answer, can chat in 10 mind14:53
johnsomMins14:53
mnaserjohnsom: np I have a call in 10 but will follow up14:53
*** kobis has joined #openstack-lbaas15:19
*** links has quit IRC15:21
*** sapd1 has joined #openstack-lbaas15:45
*** kobis has quit IRC16:00
*** salmankhan has quit IRC16:01
*** kobis has joined #openstack-lbaas16:05
*** bcafarel|pto is now known as bcafarel16:06
*** kobis has quit IRC16:07
*** tesseract has quit IRC16:21
*** pcaruana has quit IRC16:33
mnaserjohnsom: Small friendly ping :)16:39
johnsommnaser Hi\16:40
johnsomOk, so a couple of thoughts.  Is that just an LB or is that a full load balancer, like listeners pools etc.?16:40
xgerman_it’s probably the one generated by k8s16:41
xgerman_so listener pools, etc.16:41
johnsomAlso, does it have a health monitor?16:41
xgerman_they get them automaticslly16:41
xgerman_I think16:41
xgerman_https://www.irccloud.com/pastebin/fUi8Rzn3/16:45
xgerman_^^ this is how the k8s ones look on my ened16:45
johnsomHmm, then my guess is it just hasn't refreshed the screen yet, which is this patch: https://review.openstack.org/#/c/561458/16:46
xgerman_yeah, never use the GUI16:46
johnsomWhich I have not tried yet, but could fast track testing it.16:47
johnsomWithout that patch you have to refresh the web page to get the status updates.  Horizon had some bugs with dynamic updating fields that Jacky had to work around16:47
*** sshank has joined #openstack-lbaas17:11
*** AlexeyAbashkin has quit IRC17:25
*** Swami has joined #openstack-lbaas17:32
*** links has joined #openstack-lbaas18:01
*** salmankhan has joined #openstack-lbaas18:02
*** sapd1 has quit IRC18:22
mnaserjohnsom, xgerman_: sorry, been afk, i think i tried refreshing a few times and it was still offline18:33
mnaserlet me see if its still the casee18:33
xgerman_mnaser: make sure to compare with the CLI - I hardly ever use the GUI…18:33
mnaserit's still offline, okay ill compare now18:33
johnsommnaser I have a dashboard setup now, when the LB is online if I refresh it updates correctly.  With Jacky's patch it auto updates, but has a 60 second delay. When I modify his patch down to 5 or 10 seconds it works pretty well.18:34
johnsommnaser Also, which day's keynote?18:35
mnaserjohnsom: #1 but nothing publicly announced yet :)18:35
johnsomOk, NP. Just wanted to be there.18:35
johnsomI can show you what value to change if you want to use Jacky's patch, otherwise it will be an overnight cycle to change the patch and get it reviewed. It of course would only be on master branch18:37
mnaserinteresitng18:38
mnaserit shows offline even in cli18:38
johnsomYeah, I don't think there is a dashboard bug, I think it's actually offline18:39
xgerman_mmh, that’s not good — can you go through pools, etc.18:39
*** yamamoto_ has quit IRC18:46
*** yamamoto has joined #openstack-lbaas19:06
*** yamamoto has quit IRC19:12
*** KeithMnemonic has joined #openstack-lbaas19:14
*** KeithMnemonic1 has joined #openstack-lbaas19:14
*** KeithMnemonic1 has quit IRC19:15
mnaserxgerman_: i can see everything19:15
* mnaser shrugs19:15
xgerman_yeah, if it works…19:16
*** yamamoto has joined #openstack-lbaas19:17
*** sshank has quit IRC19:17
*** links has quit IRC19:20
johnsommnaser Did you figure out what is up with your LB?19:21
mnaserjohnsom, xgerman_ just got off a call.. hav eanother one in 10 but19:21
mnaserhttp://162.253.55.204/19:21
mnaserits def working.19:21
mnasermaybe something is wrong with my health manager deployment?19:21
xgerman_it should not if it’s offline19:21
johnsomYeah, maybe. Maybe it's not getting it's health heartbeats?19:22
mnaserlet me look at healthmanager logs19:22
*** yamamoto has quit IRC19:22
johnsomIt doesn't report the packets received unless it's in debug mode19:23
mnaserhmm, nothing in logs19:23
mnaseryeah let me restart in debug i guess19:23
mnaserok how does the amphorae know where the hms are19:23
mnasercontroller_ip_port_list19:24
johnsom[health_manager]19:24
johnsomcontroller_ip_port_list = 192.168.0.8:555519:24
mnaserok, the ip there isn't pingable, that explains it19:24
mnaserwould restarting octavia be enough to notify about the ip changing19:25
mnaseror is that thing configured once when the amphora gets init'd19:25
johnsomYeah, it's at boot time. We don't have the update feature in yet19:25
johnsomWith HM in debug you should see something like: May 15 12:25:49 devstackpy27-2 octavia-health-manager[83352]: DEBUG octavia.amphorae.drivers.health.heartbeat_udp [-] Received packet from ('192.168.0.6', 16496) {{(pid=83362) dorecv /opt/stack/octavia/octavia/amphorae/drivers/health/heartbeat_udp.py:186}}19:26
mnaseryeah i just tried pinging the ip and nothing came back so19:26
johnsomPing might just be security groups depending on how you setup your lb-mgmt net19:26
mnaseroh yeah you're right19:27
mnaserhow often does heartbeat send msgs19:27
mnaseraka if i tcpdump -eni any 'port 5555' ... how long should i wait19:27
johnsomAlso, depending on how you deployed, the devstack systemctl service for the HM doesn't shut down all of the processes, so watch for that, you might have to kill them by hand19:27
johnsomdefault is 10 seconds19:28
*** yamamoto has joined #openstack-lbaas19:39
*** salmankhan has quit IRC19:39
*** yamamoto has quit IRC19:44
mnaserok 10s will verify19:49
mnaserare hm pings sent to all controllers19:57
mnaserinteresting, tcpdump shows stuff coming in19:58
*** yamamoto has joined #openstack-lbaas19:59
johnsomIt rotates through the list, it is an HA strategy20:02
rm_workmnaser: also remember it's UDP20:03
rm_workso make sure UDP is allowed not just TCP20:03
*** yamamoto has quit IRC20:04
*** yboaron has quit IRC20:13
*** aojea has joined #openstack-lbaas20:18
*** yamamoto has joined #openstack-lbaas20:22
*** yamamoto has quit IRC20:26
*** AlexStaf has joined #openstack-lbaas20:37
*** kobis has joined #openstack-lbaas20:38
mnaserrm_work, johnsom: i see the udp traffic coming in the interface20:41
xgerman_sweet20:41
mnaserno iptables rules20:41
mnaserbut nothing appearing in the log20:41
mnaser2018-05-15 19:59:42.219 34685 INFO octavia.amphorae.drivers.health.heartbeat_udp [-] attempting to listen on 0.0.0.0 port 555520:41
mnaserwonder if listening to 0.0.0.0 is messing it up?20:41
johnsommnaser try this, just because I wonder if something isn't strange with your startup script. Do a systemctl stop octavia-health (or whatever it is called there), ps -ef | grep health20:42
johnsomSee if there are still processes, if so kill them (normal kill please, no -9)20:42
mnaserjohnsom: deployed via OSA, i used to see that bug in centos/rdo but not seeing it here20:42
johnsomThen start up health again with systemctl20:42
mnaseri restarted to switch to debug and i see it being the only new process since the restar20:42
mnaserudp    UNCONN     0      0         *:5555                  *:*                   users:(("octavia-health-",pid=34685,fd=5))20:43
mnaserseems to be listening properly too20:43
*** yamamoto has joined #openstack-lbaas20:43
johnsomOk, just checking. I have seen those other sub processes hang around and eat packets20:43
johnsomstack@devstackpy27-2:~/horizon$ sudo netstat -apn | grep 555520:45
johnsomudp        0      0 192.168.0.8:5555        0.0.0.0:*                           83362/python20:45
mnaserjohnsom: ss -anlp | grep 5555 ?20:45
johnsomAnd you see the UDP packets inside the container?  hmmm20:45
* mnaser doesn't have netstat20:45
mnaserjohnsom: yes! :\20:46
johnsomYeah, I'm old school and haven't switched yet20:46
mnasercentos dropped ifconfig and netstat20:46
mnaserso it forced me to20:46
mnaser:P20:46
mnaser(i just wanna compare ss outputs)20:46
johnsomudp    UNCONN     0      0      192.168.0.8:5555                  *:*                   users:(("octavia-health-",pid=83370,fd=4),("octavia-health-",pid=83368,fd=4),("octavia-health-",pid=83367,fd=4),("octavia-health-",pid=83366,fd=4),("octavia-health-",pid=83362,fd=4))20:46
mnaserok so you're listening on the specific ip20:46
mnaseri wonder if that has to do with it20:47
xgerman_OSA listens on all ips…20:47
*** yamamoto has quit IRC20:47
xgerman_0.0.0.0 - that shouldn’t affect anything20:47
johnsomWhat version do you have? I see all of the processes I expect20:47
mnaser %prog 2.0.2.dev3/openstack/venvs/octavia-17.0.3/bin/octavia-health-manager --version =>20:47
mnasererr20:47
mnaser /openstack/venvs/octavia-17.0.3/bin/octavia-health-manager --version =>  %prog 2.0.2.dev320:48
mnaseri see 2 hm processes, yet you have 520:48
mnaserand i have only 1 listening vs your 5 on the port20:48
johnsomqueens20:48
mnaseryup20:48
johnsomOk, so you probably have a pre-threads to process version, which is ok for small deployments20:49
johnsomWe switch from threadpool to procpool because we were hitting huge latency with the threads20:50
mnaserstrace the root proc shows => wait4(34685,20:50
mnaserstrace that process shows => recvfrom(5,20:50
mnaserand then lsof shows fd 5 is20:51
mnaseroctavia-h 34685 octavia    5u  IPv4         1812475951      0t0        UDP *:personal-agent20:51
*** kobis has quit IRC20:51
* mnaser flips table20:51
johnsomYeah, one is sleeping, this is the DB health check, the other is the receiver20:51
mnaseroh man20:52
mnaseri wonder if this rp_filter20:52
mnaserpacket comes in via br-mgmt from that vm20:52
mnaserbut the reverse path is not from the same interface, it has to do back from the default interface20:53
mnaserbecause the default route is the "host" for the container20:53
johnsomgetting martians?20:54
mnasergah20:54
mnaserthat was it20:54
mnasersysctl -w net.ipv4.conf.all.rp_filter=0 fixed it.20:54
johnsomhmmm20:55
mnaseri'll have to invest sometime at some point at redoing our entire lbaas networking setup20:56
mnaserthe whole migration has kinda left some cruft for us20:56
mnaser(migration to OSA that is)20:56
*** AlexStaf has quit IRC20:56
johnsomAh, ok. I was scratching my head as I didn't think we had asymmetric in OSA20:57
mnaserno its because we don't have br-lbaas or what have you20:57
mnaserthere, it's online now20:58
johnsomWell, glad it's fixed for the demo20:58
mnaser++20:58
mnaseri mean it was working anyways but "online" looks way better than "offline" :p20:59
johnsomRight20:59
johnsomNo F5's up our sleaves20:59
mnasermay the demo gods be in our favour20:59
mnaseri'll setup a second backup env20:59
johnsom+121:00
rm_workummm21:02
rm_workmnaser: soooo that means you NEVER actually had health-management working21:02
mnasershhhh21:02
rm_workso just FYI21:02
mnaserno one knows21:03
mnaser:p21:03
rm_workbe on the lookout for anything weird21:03
rm_workthat is a huge piece21:03
mnaseryeah you know it's interesting21:03
mnaseri remember once deleting an amphora or turning it off21:03
rm_workgoing from disabled to enabled HMs means that you may encounter new ... fun things21:03
mnaserand no failover happened21:03
rm_workyeah lol21:03
mnaserdont think i got time to end up digging into it but i'll keep an eye out lol21:03
rm_workso pay attention to make sure you don't get failovers when you shouldn't ;)21:03
rm_workor that health messages aren't being delayed21:04
*** yamamoto has joined #openstack-lbaas21:04
mnaserheh will do21:05
mnaseralright, gotta go run pick up someone from the airport21:05
mnaserrm_work, johnsom: thanks as usual and sorry for taking up cycles on (once again) our misconfigs ;(21:05
rm_workno worries21:05
johnsomNo worries!21:05
*** yamamoto has quit IRC21:08
rm_workjohnsom: if you respond and/or fix the rest of that chain based on my comments, I can +2 all the way up prolly21:20
johnsomOk, cool. In plan for today. I was just hitting a few dashboard reviews while I had it setup21:20
rm_workk21:20
johnsomLooking at backup members now21:20
openstackgerritAdam Harwell proposed openstack/octavia-tempest-plugin master: Create api+scenario tests for healthmonitors  https://review.openstack.org/56768821:22
rm_workwhoops, pep821:23
*** aojea has quit IRC21:24
*** yamamoto has joined #openstack-lbaas21:24
*** yamamoto has quit IRC21:29
*** yamamoto has joined #openstack-lbaas21:45
*** yamamoto has quit IRC21:50
openstackgerritMichael Johnson proposed openstack/octavia-dashboard master: Replace noop tests with registration test  https://review.openstack.org/55072121:51
*** sshank has joined #openstack-lbaas21:53
*** rcernin has joined #openstack-lbaas22:00
openstackgerritMichael Johnson proposed openstack/octavia-dashboard master: Fix sphinx-docs job for sphinx >1.7  https://review.openstack.org/56870822:03
johnsom^^^ Same docs gate issue as octavia had.  Cores, please give it a glance...22:04
*** yamamoto has joined #openstack-lbaas22:06
openstackgerritMichael Johnson proposed openstack/octavia-dashboard master: Replace noop tests with registration test  https://review.openstack.org/55072122:09
*** yamamoto has quit IRC22:10
*** yamamoto has joined #openstack-lbaas22:27
openstackgerritAdam Harwell proposed openstack/octavia master: Let healthmanager process shutdown cleanly (again)  https://review.openstack.org/56871122:27
rm_workjohnsom: got it ;)22:27
johnsomAwesome!22:27
rm_workeasy easy22:27
rm_work(harlowja helped)22:28
johnsomHa, tell him Hi and thanks22:28
rm_workso yeah the issue was that it'll shutdown/restart fine UNTIL it has received a health message, at which point it has run a process via the executor22:29
rm_workonce the executor has spun up, it needs to be allowed to shut down properly22:29
rm_workwe were terminating the parent before it had a chance22:29
rm_workso it orphaned the children22:29
rm_work(which wasn't a problem with threads)22:29
rm_workso this will need a backport22:30
*** yamamoto has quit IRC22:31
johnsomummm, so, it's just hanging now22:31
rm_workin my devstack it does not...22:32
rm_workand i don't have anything special....22:32
johnsomI just shutdown my HM, killed the processes, installed your patch, started then stopped22:33
johnsomMay 15 15:30:09 devstackpy27-2 systemd[1]: Stopping Devstack devstack@o-hm.service...22:33
johnsomMay 15 15:30:09 devstackpy27-2 octavia-health-manager[71502]: INFO octavia.cmd.health_manager [-] Health Manager exiting due to signal22:33
rm_workhmm22:33
johnsomJust sitting there22:33
rm_workyou don't get the rest?22:33
rm_worksec22:33
rm_workstart it, and do a ps22:33
rm_workand tell me how many procs you see22:34
johnsomRight now I have:22:34
johnsomstack     71502      1  0 15:29 ?        00:00:01 /usr/bin/python /usr/local/bin/octavia-health-manager --config-file /etc/octavia/octavia.conf22:34
johnsomstack     71512  71502  0 15:29 ?        00:00:00 /usr/bin/python /usr/local/bin/octavia-health-manager --config-file /etc/octavia/octavia.conf22:34
johnsomLet me kill this out and start again22:34
rm_workhttp://paste.openstack.org/show/721048/22:34
rm_workit should go to 7 or so :322:35
rm_worklike, MINIMUM is 322:35
rm_workif you don't get 3, something is f'd22:35
rm_workthen it should be 3+num_cores22:35
rm_workonce a message or two have come in22:35
johnsomOk, fresh start: stack     71924      1 15 15:35 ?        00:00:01 /usr/bin/python /usr/local/bin/octavia-health-manager --config-file /etc/octavia/octavia.conf22:36
johnsomstack     71936  71924  0 15:35 ?        00:00:00 /usr/bin/python /usr/local/bin/octavia-health-manager --config-file /etc/octavia/octavia.conf22:36
johnsomstack     71937  71924  0 15:35 ?        00:00:00 /usr/bin/python /usr/local/bin/octavia-health-manager --config-file /etc/octavia/octavia.conf22:36
rm_workhttp://paste.openstack.org/show/721049/22:36
rm_workcan you pastebin, with more context22:36
rm_worklike what i did22:36
johnsomhttps://www.irccloud.com/pastebin/kjSFrsgu/22:36
rm_work3 means it hasn't gotten any packets yet22:37
rm_workactually i need to test with that, one sec22:37
johnsomYeah, there are no amps yet22:37
rm_workk one moment, deleting my LB22:37
rm_workhmmmmmmmmmmmmmmmmmmm22:38
rm_workyeah i think it's hanging on the recv maybe22:38
johnsomYeah, it just hangs until systemd gives up and kills it22:38
rm_workT_T22:38
*** AlexStaf has joined #openstack-lbaas22:45
rm_workjohnsom: got it, one sec, testing22:45
*** yamamoto has joined #openstack-lbaas22:47
*** JudeC has quit IRC22:51
rm_workjohnsom: try that22:51
rm_workerr22:51
openstackgerritAdam Harwell proposed openstack/octavia master: Let healthmanager process shutdown cleanly (again)  https://review.openstack.org/56871122:51
johnsomlol22:51
rm_workthat ^^22:51
*** JudeC has joined #openstack-lbaas22:52
*** yamamoto has quit IRC22:52
johnsomBummer, you are right, cert parser is handing me back a decrypted private key at that point. This will be a bit of work to fix22:54
rm_workwe need to dump that entire file22:55
rm_workhonestly22:55
johnsomLooks good so far22:58
rm_workjohnsom: so... if you want to sit down at the summit and just DELETE cert_parser.py23:02
rm_workand the whole folder its in, i think....23:02
rm_workand then make everything work again...23:02
rm_worki will do that23:02
rm_workwith you23:02
johnsomOnly if we get these driver patches landed, then sure, if it need to go we can do that23:02
rm_workk23:03
johnsomMaybe wednesday23:03
*** yamamoto has joined #openstack-lbaas23:08
*** yamamoto has quit IRC23:12
openstackgerritMichael Johnson proposed openstack/octavia master: Implement provider drivers - Listener  https://review.openstack.org/56637923:19
johnsomSo, yeah, when we get to cleanup, we need to decide if we want to use 50x or not23:21
rm_workI do not like it23:21
johnsomI kind of agree I don't really want to return that like ever23:21
rm_workbut I don't know what we SHOULD send instead :323:21
johnsomBut, it's technically accurate if the driver blows chunks23:21
johnsomhttps://review.openstack.org/#/c/563795/12/octavia/common/exceptions.py23:22
johnsomLooking at this list...23:23
johnsomWe could change all but driverError to 400 as it could be considered bad input.23:24
johnsomI mean provider not found would be a bit unfair as it would be listed in the providers list the user can see23:24
*** sshank has quit IRC23:24
rm_work412?23:25
rm_workor 50123:25
johnsomWell, it's 501 now23:26
rm_workoh err23:26
rm_worki thought i was seeing 50023:26
rm_workwith a traceback23:26
rm_worki am pretty sure i was...23:26
rm_workmaybe i didn't look in the cleanup?23:26
rm_workdid you fix/change it?23:26
johnsomno, it's all at that link I pasted23:26
rm_workhmmmm k23:27
rm_workerr but, hold on23:27
rm_workwhich review did i comment about that on23:28
johnsomlol we could 502 them "Bad Gateway".  I think that would lead to proxy confusion though23:28
johnsomhttps://review.openstack.org/#/c/566698/3/octavia/tests/functional/api/v2/test_pool.py23:29
johnsomThat is the one I was looking at23:29
johnsomIt's a DriverError test23:29
rm_workok yeah so ...23:30
rm_workdo you see that looking for 500?23:30
rm_workthat seems to say 500 not 50123:30
*** yamamoto has joined #openstack-lbaas23:30
johnsomRight, it's the driver error, the others are 50123:32
rm_workyeah, ok23:32
johnsomAlso I disabled the stack trace for 5xx23:32
rm_workso yes, 50123:32
rm_workI would think23:32
rm_workwhere do you use ProviderNotFound23:34
johnsomThat is when it is enabled in the config but stevedore can't load it23:34
rm_workah also, is it a setting whether to do traces or not?23:34
johnsomdrivererror is like when the driver raises some random exception, not really not implemented, but broken23:34
rm_workright23:35
rm_workso you don't think 501 for that?23:35
johnsomhttps://review.openstack.org/#/c/563795/12/octavia/api/config.py23:35
rm_workit's like, we know kinda what's broken, we didn't just randomly explode, we should kinda bubblewrap the drivers for user returns23:35
johnsom501 is not implemented, not your dumb provider just went out to lunch23:35
*** yamamoto has quit IRC23:35
rm_worklol23:36
rm_workyeah but that's something an operator should know/care about23:36
rm_worknot something the user should see IMO23:36
johnsomYeah, the whole point of this class I linked is to bubble wrap the drivers23:36
rm_workas far as the user is concerned, the two things are the same23:36
rm_workyeah, so i am not sure the other one should be a 4xx either23:36
rm_workthat should probably also be a 5xx23:36
rm_workbecause again, it's a deployer issue23:37
johnsomI am super temped to make the ProviderNotImplementedError and ProviderUnsupportedOptionError 40023:37
rm_workerr23:37
rm_workwait23:37
rm_worksorry i was looking at something backwards23:37
johnsomNo ProviderNotEnabled is clearly the user put in the wrong provider name23:37
rm_workyes23:38
rm_workyeah ok nm i figured it out23:38
rm_workbut yeah .... i still feel like the rest are operator concerns23:38
johnsomThat is a provider that is not even enabled in the config, so not returned via the provider list api23:38
rm_workand the user should see something that's less "SOMETHING UNEXPECTED HAPPENED!!!" and more "well, we tried to deal with the driver, but they were shit, so we can't do it"23:38
rm_work500 is very "EXPLODE!"23:39
johnsomI need to run an errand and beet 5pm traffic. I will be back in a little while23:39
rm_work501 seems more graceful23:39
rm_workmaybe just me23:39
rm_workkk23:39
johnsomYeah, that is why I created these special exceptions.  CLEARLY call out the driver23:39
johnsomAlways23:39
johnsomIt's my subtle "your driver is 'poor'"23:40
rm_workyeah but half the time people are just going to see "500" and think "stupid service exploded"23:40
rm_workat least 501 usually causes reading to happen23:40
johnsomAlright, back in a few.  Noodle, let me know what you think23:40
johnsomWe could 503 them too23:40
rm_workmaybe this is territory for "ask at the summit"23:41
* rm_work waves23:41
*** Swami has quit IRC23:51
*** yamamoto has joined #openstack-lbaas23:52
*** yamamoto has quit IRC23:56
*** samccann has quit IRC23:58

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