Thursday, 2017-06-01

*** cpuga has joined #openstack-lbaas00:01
*** armax has quit IRC00:02
*** links has joined #openstack-lbaas00:06
*** sshank has quit IRC00:07
*** cpuga has quit IRC00:15
*** cpuga has joined #openstack-lbaas00:16
*** cpuga has quit IRC00:21
*** cpuga_ has joined #openstack-lbaas00:23
*** cpuga_ has quit IRC00:23
*** JudeC has quit IRC00:31
johnsomOk, OSC tomorrow00:35
*** cpuga has joined #openstack-lbaas00:40
rm_work:)00:47
*** cpuga_ has joined #openstack-lbaas00:56
*** cpuga has quit IRC00:57
*** JudeC has joined #openstack-lbaas01:01
*** cpuga_ has quit IRC01:03
*** cpuga_ has joined #openstack-lbaas01:06
*** cpuga_ has quit IRC01:08
*** links has quit IRC01:14
*** cpuga has joined #openstack-lbaas01:14
rm_workjohnsom: wait what actually marks me as an octavia *admin* in keystone?01:21
*** kbyrne has quit IRC01:39
rm_workweird, i can't get a GET on /loadbalancers to list other projects, but i can delete, so i must be admin01:41
*** kbyrne has joined #openstack-lbaas01:42
*** fnaval has joined #openstack-lbaas01:50
*** cpuga has quit IRC01:57
*** cpuga has joined #openstack-lbaas02:02
*** cpuga_ has joined #openstack-lbaas02:04
*** cpuga has quit IRC02:04
*** cpuga has joined #openstack-lbaas02:06
*** cpuga_ has quit IRC02:06
*** cpuga has quit IRC02:09
*** cpuga has joined #openstack-lbaas02:09
*** armax has joined #openstack-lbaas02:23
*** leitan has joined #openstack-lbaas02:28
*** cpuga has quit IRC02:31
rm_workxgerman: when are you back from vacation? :P02:43
*** sanfern has joined #openstack-lbaas02:47
*** links has joined #openstack-lbaas02:53
*** yamamoto_ has joined #openstack-lbaas02:58
*** yamamoto_ has quit IRC02:58
*** yamamoto_ has joined #openstack-lbaas02:58
*** cpuga has joined #openstack-lbaas03:07
*** JudeC has quit IRC03:10
*** leitan has quit IRC03:22
*** leitan has joined #openstack-lbaas03:23
*** leitan has quit IRC03:23
*** gans has joined #openstack-lbaas03:24
*** leitan has joined #openstack-lbaas03:24
*** leitan has quit IRC03:28
*** csomerville has joined #openstack-lbaas03:31
*** csomerville has quit IRC03:35
*** cody-somerville has joined #openstack-lbaas03:36
*** cody-somerville has quit IRC03:36
*** cody-somerville has joined #openstack-lbaas03:36
*** cpuga_ has joined #openstack-lbaas03:37
*** cpuga has quit IRC03:40
*** cpuga_ has quit IRC03:41
*** gcheresh has joined #openstack-lbaas03:45
*** cody-somerville has quit IRC03:46
*** gcheresh has quit IRC03:51
*** JudeC has joined #openstack-lbaas04:03
*** aojea has joined #openstack-lbaas04:14
*** aojea has quit IRC04:19
*** JudeC has quit IRC04:33
*** cody-somerville has joined #openstack-lbaas04:33
*** cody-somerville has quit IRC04:33
*** cody-somerville has joined #openstack-lbaas04:33
*** pcaruana has joined #openstack-lbaas04:43
*** yamamoto_ has quit IRC04:48
*** csomerville has joined #openstack-lbaas05:01
*** armax has quit IRC05:02
*** cody-somerville has quit IRC05:04
*** cody-somerville has joined #openstack-lbaas05:08
*** cody-somerville has quit IRC05:08
*** cody-somerville has joined #openstack-lbaas05:08
*** gcheresh has joined #openstack-lbaas05:10
*** csomerville has quit IRC05:10
*** belharar has joined #openstack-lbaas05:17
*** JudeC has joined #openstack-lbaas05:19
*** belharar has quit IRC05:30
*** yamamoto_ has joined #openstack-lbaas05:35
*** pcaruana has quit IRC05:49
*** rcernin has joined #openstack-lbaas05:58
*** belharar has joined #openstack-lbaas06:01
*** pcaruana has joined #openstack-lbaas06:02
*** Dinesh_Bhor has quit IRC06:23
*** belharar has quit IRC06:39
*** tesseract has joined #openstack-lbaas06:51
xgermanwill be back Monday07:02
*** aojea has joined #openstack-lbaas07:22
*** aojea has quit IRC07:23
*** aojea has joined #openstack-lbaas07:23
*** belharar has joined #openstack-lbaas07:37
rm_workxgerman: augh not until next monday? T_T07:46
rm_workk07:46
rm_workwell our gates keep breaking so07:47
rm_workmaybe by then we can merge stuff anyway...07:47
rm_workah you did +A a bunch :P07:47
nmagnezirm_work, who need gates anyway.. :P07:51
rm_workanywho07:51
rm_workhttps://github.com/pypa/setuptools/pull/104307:51
rm_workas soon as setuptools fixes their shit, we're good to go again I guess with rechecks :P07:51
*** dayou has quit IRC07:52
gansso that's why my diskimage-crate was failing from this morning !!! huh08:06
*** sanfern has quit IRC08:15
*** sanfern has joined #openstack-lbaas08:15
*** sanfern has quit IRC08:21
*** sanfern has joined #openstack-lbaas08:23
*** dayou has joined #openstack-lbaas08:28
xgermanrm_work have a train ride later today... so maybe will have a look...08:42
nmagnezixgerman, you are very productive when you ride trains :-)08:43
nmagnezirm_work, still around? I have a question08:44
*** JudeC has quit IRC09:07
*** openstackstatus has quit IRC09:36
*** openstackstatus has joined #openstack-lbaas09:38
*** ChanServ sets mode: +v openstackstatus09:38
-openstackstatus- NOTICE: There is a known issue with setuptools 36.0.0 and errors about the "six" package. For current details see https://github.com/pypa/setuptools/issues/1042 and monitor #openstack-infra09:44
*** yamamoto_ has quit IRC10:47
*** sanfern has quit IRC10:52
*** gans has quit IRC11:06
*** yamamoto has joined #openstack-lbaas11:29
*** yamamoto_ has joined #openstack-lbaas11:29
*** yamamoto has quit IRC11:33
*** yamamoto_ has quit IRC11:35
*** links has quit IRC11:37
*** atoth has joined #openstack-lbaas11:49
openstackgerritNir Magnezi proposed openstack/neutron-lbaas master: Fix file mode  https://review.openstack.org/42055111:54
*** yamamoto has joined #openstack-lbaas12:09
openstackgerritBernard Cafarelli proposed openstack/octavia master: Install amphora agent from distribution package on RHEL  https://review.openstack.org/46985012:15
*** leitan has joined #openstack-lbaas12:28
*** sanfern has joined #openstack-lbaas12:37
*** sanfern has quit IRC12:47
*** sanfern has joined #openstack-lbaas12:47
*** kobis has joined #openstack-lbaas12:58
*** yamamoto has quit IRC13:02
*** gans has joined #openstack-lbaas13:15
*** yamamoto has joined #openstack-lbaas13:21
*** gans has quit IRC13:27
*** gans has joined #openstack-lbaas13:36
*** fnaval_ has joined #openstack-lbaas13:40
*** fnaval has quit IRC13:41
*** yamamoto has quit IRC13:43
*** gans has quit IRC13:44
*** yamamoto has joined #openstack-lbaas13:45
*** yamamoto has quit IRC13:45
*** cpuga has joined #openstack-lbaas13:48
*** cpuga_ has joined #openstack-lbaas13:49
*** cpuga has quit IRC13:53
*** gcheresh has quit IRC13:56
*** KeithMnemonic2 has joined #openstack-lbaas14:01
*** KeithMnemonic1 has quit IRC14:04
*** yamamoto has joined #openstack-lbaas14:07
*** cody-somerville has quit IRC14:12
*** armax has joined #openstack-lbaas14:24
-openstackstatus- NOTICE: python-setuptools 36.0.1 has been released and now making its way into jobs. Feel free to 'recheck' your failures. If you have any problems, please join #openstack-infra14:33
*** openstackgerrit has quit IRC14:34
*** cpuga_ has quit IRC14:59
*** cpuga has joined #openstack-lbaas15:00
*** cpuga_ has joined #openstack-lbaas15:04
*** cpuga has quit IRC15:08
*** gcheresh has joined #openstack-lbaas15:14
*** armax has quit IRC15:20
*** gcheresh has quit IRC15:45
*** leitan has quit IRC15:45
*** yamamoto has quit IRC15:51
*** yamamoto has joined #openstack-lbaas15:52
*** reedip_ has joined #openstack-lbaas15:53
*** gcheresh has joined #openstack-lbaas15:54
*** yamamoto has quit IRC15:58
*** catintheroof has joined #openstack-lbaas16:02
*** aojea has quit IRC16:03
*** rcernin has quit IRC16:04
*** aojea has joined #openstack-lbaas16:04
*** gans has joined #openstack-lbaas16:04
*** openstackgerrit has joined #openstack-lbaas16:05
openstackgerritJason Niesz proposed openstack/octavia master: blueprint: l3-active-active  https://review.openstack.org/45300516:05
*** aojea has quit IRC16:08
openstackgerritMichael Johnson proposed openstack/octavia master: Add v2 pool API section  https://review.openstack.org/45827216:12
*** gcheresh has quit IRC16:12
*** cody-somerville has joined #openstack-lbaas16:25
*** cody-somerville has quit IRC16:25
*** cody-somerville has joined #openstack-lbaas16:25
*** catintheroof has quit IRC16:27
*** cpuga_ has quit IRC16:28
*** cpuga has joined #openstack-lbaas16:28
*** armax has joined #openstack-lbaas16:29
*** gans has quit IRC16:42
*** kobis has quit IRC16:44
*** belharar has quit IRC16:45
*** tesseract has quit IRC16:54
*** yamamoto has joined #openstack-lbaas16:55
rm_worknmagnezi: sorry, slept16:58
rm_worknmagnezi: here now :P16:58
*** foutatoro has joined #openstack-lbaas16:58
nmagnezirm_work, :-)16:58
nmagnezirm_work, just wanted to ask about the amphora agent log path16:58
rm_workjohnsom: thanks for all the rechecks :)16:58
nmagnezirm_work,  i see it's hardcoded16:59
nmagnezirm_work, is that intentional?16:59
johnsomYeah, working through stuff.  I hope some stuff with start merging soon16:59
nmagnezirm_work, https://github.com/openstack/octavia/blob/eb644135afcc676c4d8626bceb6eddf6cea9b3eb/octavia/cmd/agent.py#L7916:59
nmagnezirm_work, usually openstack services get --log-file <path>16:59
johnsomnmagnezi I did that16:59
nmagnezijohnsom, hi :)17:00
johnsomI think17:00
rm_worki thought we did support --log-file17:00
nmagnezijohnsom, i actually pinged Adam when it was night time for you17:00
rm_workoh17:00
johnsomNo, not that one.17:00
rm_workfor the controlplane17:00
*** JudeC has joined #openstack-lbaas17:00
rm_workthis is the amp agent17:00
rm_workyeah17:00
nmagnezirm_work, i haven't tried this in the agent17:00
rm_workwe could config-ize it17:00
johnsomI mean, everything is "controlled" in the amp, so, I guess do you have a use case?17:01
johnsomAlso note, with the recent changes, that log isn't complete.  It's still split between that log and the syslog17:01
johnsomit's an issue IMO17:01
rm_workyeah we need to fix the logging story17:01
rm_workthat was another thing i was going to bring up if i had more time at the meeting17:02
rm_workthat's high on my priority list, to get the possibility to inject a custom syslogd config so the amps could for instance send off to an ELK ingress point17:02
*** yamamoto has quit IRC17:04
*** gcheresh has joined #openstack-lbaas17:04
*** gcheresh has quit IRC17:04
johnsomYeah, agreed.  Something that is filebeat compatible I think would be best17:05
nmagnezijohnsom, just asking because in the rpm I made for that agent the logging path is /var/log/octavia/amphora-agent.log (as oppose to /var/log/amphora-agent.log) so I wanted to know if that could be converted to a param. but i guess i can also modify the rpm17:06
nmagnezithat's the usecase :)17:06
*** cody-somerville has quit IRC17:06
rm_workyeah just modify the rpm imo :P17:06
johnsomWell, or just standardize it.  I'm not opposed to an octavia sub directory17:06
rm_workyeah me either17:07
*** cody-somerville has joined #openstack-lbaas17:07
*** cody-somerville has quit IRC17:07
*** cody-somerville has joined #openstack-lbaas17:07
johnsomIt probably makes a lot of sense actually17:07
nmagnezihttps://github.com/rdo-packages/octavia-distgit/blob/rpm-master/octavia-amphora-agent.service#L817:07
rm_workomg johnsom can you make cody-somerville fix his client lol17:07
johnsomrm_work I guess you are showing joins?  I turned it off a long time ago.  There was someone else just spamming the channel too17:08
rm_workheh yeah17:08
rm_worki waver back and forth about turning that off17:08
johnsomYeah, it was interesting, but too much noise over signal17:08
johnsomI just gave up17:08
johnsomPlus with irccloud and such, I don't think that status is very accurate anyway.  I have no idea what it does for me.  Probably always "here"17:09
rm_workyeah17:11
*** sshank has joined #openstack-lbaas17:16
rm_workjohnsom / JudeC can the docs changes be done in JudeC's final followup?17:18
rm_workit's just that it's a REALLY long chain, lol17:18
rm_worki mean i guess if he doesn't care17:18
JudeCI dont care :P17:18
johnsomIt is nice to have them along the way for review/updates/comments17:20
johnsomI am reviewing the load balancer commands now.  Just thought I would post that initial observation17:22
*** cpuga_ has joined #openstack-lbaas17:26
*** cpuga has quit IRC17:28
*** SumitNaiksatam has joined #openstack-lbaas17:29
openstackgerritMerged openstack/python-octaviaclient master: Optimize the link address  https://review.openstack.org/45528817:41
*** tonygunk has quit IRC17:42
*** gcheresh has joined #openstack-lbaas17:44
openstackgerritMerged openstack/octavia master: Pool name/desc needs to be "" when empty, not null  https://review.openstack.org/46778017:45
*** leitan has joined #openstack-lbaas17:56
openstackgerritMerged openstack/octavia master: Fix pool response to fill healthmonitor_id properly  https://review.openstack.org/46740717:57
*** aojea has joined #openstack-lbaas18:07
*** aojea has quit IRC18:12
*** reedip_ has quit IRC18:13
*** rcernin has joined #openstack-lbaas18:14
openstackgerritMerged openstack/octavia master: Remove lb_network_name from config (it was bogus)  https://review.openstack.org/46518318:14
*** kobis has joined #openstack-lbaas18:15
sanfernwhat is the significance of subnet in command lbaas-member-create ? can I have members and vip from difference subnets ?18:19
rm_workyes18:20
rm_workwe will plug the member subnet into the amphora18:20
rm_workso it is reachable18:20
sanfernoh ok, got it thanks rm_work18:20
openstackgerritMerged openstack/octavia master: Optional L7Policies param was marked as required  https://review.openstack.org/46779818:29
openstackgerritAdam Harwell proposed openstack/octavia master: VRRP amphora_driver functions weren't handled by noop driver  https://review.openstack.org/46518518:30
johnsomrm_work FYI, https://bugs.launchpad.net/octavia/+bug/166506918:34
openstackLaunchpad bug 1665069 in octavia "Support of haproxy log aggregation capabilites" [Wishlist,Triaged] - Assigned to Ganpat Agarwal (gans-developer)18:34
johnsomWe should coordinate on that and agree on an approach18:34
rm_workyes18:35
rm_workIMO we allow passing in a customizable syslogd template18:35
rm_workand just let operators ship logs to wherever18:35
johnsomThis is the connection tracking log, not the admin log, but we should be consistent to some degree18:35
sanfernwe try testing splunk, we need to provide IP:port and FQDN will not work18:37
rm_workyes we disable DNS on amps18:38
johnsomYeah, and HAproxy doesn't allow DNS names.  So, both  reasons that won't work18:39
sanfernoh ok reason behind18:39
rm_workjohnsom: i mean yeah, logs is logs. same method IMO18:39
rm_workcan provide a syslogd config to handle both types18:39
johnsomI think it is good to be able to separate them with either an ID or something, but similar method is good.18:39
*** sanfern has quit IRC18:41
*** sshank has quit IRC18:41
*** sanfern has joined #openstack-lbaas18:42
*** foutatoro has quit IRC18:55
*** aojea has joined #openstack-lbaas19:06
rm_workjohnsom: i mean, they ARE separate, right?19:08
rm_workyou'd provide a syslogd config for agent logs, and a syslogd config for haproxy logs19:08
rm_workno?19:08
rm_worki'm confused about what you mean when you keep saying "separate them by ID"19:09
johnsomThere are three configs really.  Agent logs, haproxy admin logs (startup/stop/errors, and haproxy connection logs (user data)19:09
johnsomYou probably don't want the HAproxy admin stuff going into the user logs19:10
rm_workright, aren't they different files?19:10
*** aojea has quit IRC19:10
johnsomDepends on how you configure HAproxy19:10
rm_workso wouldn't the syslogd config say "admin logs go to <X> and connection logs go to <Y>" ?19:10
rm_workwell, WE configure it :P19:10
rm_workand I thought we had them as separate files, but maybe not yet?19:11
johnsomRight, just saying we need to pay attention to that config.  Right now I think it all goes into one19:11
johnsomThe files are a mess19:11
johnsomeven our agent logs are split between two files now with gunicorn19:11
rm_workthat's just a quick update to our haproxy.conf template right?19:12
rm_workhmm really? will have to look at that19:12
rm_worki'm touching all the agent stuff right now anyway19:12
rm_worktho, brb lunch19:12
johnsomOk.  Yeah, some stuff goes out the the agent.log some stuff is still going into the console->syslog19:12
johnsomI should eat too19:13
leitanHi guys19:14
leitanim doing HA tests with octavia19:14
leitanshutdown the master node, traffic went to the backup flawlessly19:14
leitanbut, started the master again19:14
leitanfailed to start VRRP19:14
leitaninside the amphorae19:15
leitanrm_work xgerman johnsom , if you can take a look, will be great http://paste.openstack.org/show/611238/19:23
openstackgerritMerged openstack/octavia master: Don't leave LBs in PENDING_DELETE after refusing to cascade  https://review.openstack.org/46581319:28
leitanso basically if i shutoff the backup that asummed the mastership, i lost my balancers19:30
leitanweird19:30
leitanletme know, ill debug this from my side19:30
*** kobis has quit IRC19:31
*** sanfern has quit IRC19:31
*** leitan has quit IRC19:41
*** leitan has joined #openstack-lbaas19:45
*** sshank has joined #openstack-lbaas19:48
leitanback, so basically till i dont restart the backup node, that was the last one with the ownership of the ip address ... i dont recover the traffic19:52
*** armax has quit IRC20:00
*** cody-somerville has quit IRC20:10
johnsomleitan Are you only looking at the keepalived logs or also testing the traffic?  I have seen the logging not really reflect the accurate view.  Also, by shut off, how are you doing that?20:15
johnsomAre you just rebooting the master?  Do you have TLS offload configured?20:17
*** leitan has quit IRC20:30
*** leitan has joined #openstack-lbaas20:32
leitansorry got disconnected20:32
leitanjohnsom: testing both, traffic and seeing the logs20:32
leitanthats the behaviour20:33
leitani dont have TLS offload20:33
johnsomHmmm, I did some testing with act/stndby recently.  The failover was slower than before, but still completed.  So curious what is up.20:33
leitani rebooted the master first, the traffic migrated fine to the backup, when the master came back, keepalived doesnt started, and if i rebooted the slave, i lost all LB functionality20:33
leitanjohnsom: ill test now with a LB located on a vxlan to see if has something to do with the flat network i have attached the public LB20:34
leitanim courious why all the GARP logs20:34
johnsomHmm, I wonder why keepalived didn't come up...  Do you see anything in the journalctl for keepalived of why it didn't start.20:35
leitanjohnsom: lemme check20:35
johnsomThe GARP thing is a workaround I did for some strange neutron behavior we saw.  We had to force more periodic GARP to make sure the IP migration advertisement is picked up by neutron/OVS20:35
johnsomIt is a "beat the virtual network over the head with the fact that the IP is on a new instance now"20:36
johnsomThe GARPs are how the instance tells the network that this instance now owns the IP20:37
leitanjohnsom: yes, tought that maybe to much GARP logs means network unreacheable in some way20:39
leitanJun 01 20:37:26 amphora-02288985-f910-4c56-9253-9bcd0d0a8bc4 systemd[1]: octavia-keepalived.service: Control process exited, code=exited status=120:40
johnsomleitan Can you do "systemctl status octavia-keepalived | less" and paste the output?20:40
leitanyes20:41
johnsomI hope you have time, I'm really interested in what you are seeing.  I'm also setting up an act/stdby on my side now.20:41
leitanjohnsom: im interested that youre interested :P20:42
rm_worki am ALSO setting that up shortly20:43
rm_worklike next two weeks should be switching from SINGLE to active/passive20:43
leitanjohnsom: http://paste.openstack.org/show/611246/20:43
leitanseems kinda a race condition with the kernel namespace20:43
leitanbecause im listing it, and its there20:44
johnsomOh!, that IS a problem20:44
rm_workah it's starting too early20:44
rm_workit seems20:44
leitanjohnsom rm_work indeed --> http://paste.openstack.org/show/611247/20:44
rm_workyeah it just hasn't been set up fully yet20:44
rm_workneed to move keepalived later in the boot process20:45
johnsomHmmm, give me a minute to look at something.20:46
johnsomYeah, ok, it's a bug20:47
leitanjohnsom: i remember facing similar conditions with l3-agent and rpc_response once20:47
leitanjohnsom: want me to fill a bug report ?20:48
johnsomSure, I will probably push a fix today, so having a bug would be good.20:48
leitanright away Sir20:48
johnsomRebooting amps is a bit questionable now that the certs are on the RAM drive, but I want to keep that as functional as possible20:48
johnsomThat was my mistake in the transition to systemd.20:49
*** cody-somerville has joined #openstack-lbaas20:51
rm_workah this is a reboot thing?20:52
johnsomYes20:52
rm_workdidn't notice that's what he was doing20:52
rm_workT_T20:52
rm_worknormally we don't reboot Amps20:52
leitanim rebooting amps since i need to do a full HA test before getting this into prod, this can represent a total failure if both amps fail at different time20:54
leitanjohnsom: https://bugs.launchpad.net/octavia/+bug/169508720:54
openstackLaunchpad bug 1695087 in octavia "Race condition causes keepalived to fail, namepsace not fully configured" [Undecided,New]20:54
johnsomThanks20:54
leitansince the the octavia services has access to the amphorae, is possible to declare the amphorae as DEGRADED since vrrp or haproxy didnt start ?20:55
johnsomWell, if haproxy doesn't start the amp will be considered failed by the health manager and it will be replaced20:56
*** armax has joined #openstack-lbaas20:56
leitanjohnsom: but not for keepalived20:57
johnsomThat said, I'm not sure that keepalived failing to start would trigger the amp to be considered failed.  That might be a gap.20:57
leitanjohnsom: sure20:57
johnsomIt it failed on deploy it would get caught, but I think on reboot we have a gap20:57
johnsomProbably worth another bug20:58
leitanyeah, about to ask that20:58
leitanill fill it20:58
leitanjohnsom: https://bugs.launchpad.net/octavia/+bug/1695090 done21:03
openstackLaunchpad bug 1695090 in octavia "Keepalived not considered to declare unhealthy an amphorae" [Undecided,New]21:03
johnsomThanks.  We might have that, but I can't remember how.  With the bug we can track it down.21:07
rm_workxgerman: while you are on the train, you should review https://review.openstack.org/458272 and the rest of the chain :)21:09
*** fnaval_ has quit IRC21:12
*** fnaval has joined #openstack-lbaas21:14
*** SumitNaiksatam has quit IRC21:15
*** tonygunk has joined #openstack-lbaas21:16
*** gcheresh has quit IRC21:20
*** leitan has quit IRC21:21
johnsomUgh, this is another one of those where that dumb decision to have multiple haproxy processes is really hurting....21:33
*** cpuga_ has quit IRC21:36
*** cody-somerville has quit IRC21:49
*** cody-somerville has joined #openstack-lbaas21:55
*** cody-somerville has quit IRC21:55
*** cody-somerville has joined #openstack-lbaas21:55
*** ipsecguy_ has joined #openstack-lbaas21:56
rm_workjohnsom: can we just ... undo that :P21:59
rm_work"just"21:59
*** ipsecguy has quit IRC21:59
*** rcernin has quit IRC22:10
johnsomIt's going to be a bunch of work.  I don't want to prioritize that over our current efforts22:23
openstackgerritMichael Johnson proposed openstack/octavia master: Fix keepalived systemd race with haproxy namespace  https://review.openstack.org/47005122:45
*** leitan has joined #openstack-lbaas22:49
johnsomThat seems to work22:50
leitanjohnsom: when you guys have the keepalived patch i can test it right away on my env, let me know22:51
johnsomleitan ^^^^22:51
johnsomhttps://review.openstack.org/47005122:52
leitangot disconnected22:52
leitanill check it22:52
leitanjohnsom: currently active LBs are going to refresh the template if i reboot them ?22:53
johnsomNo, that is an agent update.  To easily test, go into /usr/lib/systemd/system and edit each haproxy-* file22:54
johnsomAdd the "Before=octavia-keepalived.service" line, then run "systemctl daemon-reload" to load the new files.  Then you can do the reboot test22:56
leitanjohnsom: roger22:56
leitanjohnsom: working like a charm23:03
johnsomCool, thanks!23:03
leitanjohnsom: to you, ill keep testing and let you guys know if i find something else23:05
leitanlet me know if i can help testing something out23:05
johnsomOk, I'm taking a look the keepalived != failed issue23:05
leitangreat, i can test the patch whenever you want23:06
johnsomWell, I need to come up with the right solution for that first....  Grin23:06
leitanjohnsom: is there any constrain to do it just like the haproxy pid monitoring ?23:11
johnsomYeah, with haproxy we are actually interrogating haproxy over a unix socket.  We don't have that opportunity with keepalived.  Plus we need to make sure this amp is actually in a act/stdby pair.23:13
*** cpuga has joined #openstack-lbaas23:13
johnsomIt's a bit more tricky23:13
johnsomNot to mention the three init systems....23:15
leitanjohnsom: right, so youre configuring keepalived as an standalone master for "SINGLE" LBs too then ?23:16
johnsomNo, we don't, it doesn't get setup at all on the standalone23:17
johnsomSo, we can't just check if it is running as the standalone topology does not have it actually running23:17
leitanunderstood, thinking here too23:18
johnsomI'm leaning towards checking the process is running via the pid file, but still thinking about it a bit.  keepalived actually uses three processes, so is that good enough....  etc.23:20
*** aojea has joined #openstack-lbaas23:21
*** aojea has quit IRC23:26
leitanjohnsom: maybe sounds silly, but what about using a tracking script that leave something like state file on some path, if the file at least is there, means that its a active_standby lb, and the the health manager can check if its actually, maybe the file can be a result of the "pidof keepalived" command, and the health can check agains those running pids23:32
leitana keepalived tracking script23:32
johnsomWell, the tracking script will  only run if the process starts.23:33
leitanif keepalived was actually in the past, is gonna be there23:33
johnsomRight.23:33
johnsomI can check for our config file to see if it should be running or not.  No config should mean standalone23:34
leitanso if the file exists, but in a reboot keepalived doesnt came up, youre going to check your last pids, on the file, returns 1 and mark as unhealthy23:34
leitanjohnsom: yes, that too, if its empty23:34
leitanbut with the other method, you can actually check the running pids, if it dies in the middle23:34
leitanis goint to mark it unhealthy on the next iteration23:35
johnsomYeah, I'm just trying to decide if checking that the process is running is good enough (as there are three).  Just doing a little research to see how far it is worth taking23:35
leitanjohnsom: ill be thinking another methods too, i saw a keepalived path to work as cisco like --vrrp-status, having that will ease the things23:37
*** sshank has quit IRC23:38
leitanjohnsom: what about starting keepalived with "-x" flag enabling snmp support and queryng the keealived MIB, like neutron tried to do here: https://bugs.launchpad.net/neutron/+bug/146011623:45
openstackLaunchpad bug 1460116 in neutron "keepalived should have snmp support enabled" [Wishlist,Expired]23:45
johnsomI am considering that23:45
johnsomAlso looking at the dbus interface23:45
leitanjohnsom: with the snmp support you can also get the states of the VRID, maybe that will too in the future be helpfull for who is the master dectection we were talking the other day23:47
johnsomYeah, that is kind of why I'm looking at options beyond checking if the process is there or not23:47
leitanjohnsom: yes, maybe in the future the vrrptable counters can help detecting if for some reason vrrp adv pkts are dropped on the hosts, to mark an amphorae as unhealthy on the server23:50
johnsomSadly the snmp support requires an snmp master agent, which we don't currently install.  It's a bit heavy weight for what I am hoping23:54
leitanthats a downside, but the RHEL image wasnt too heavy to pass through the gate ? snmp cant hurt anyone :P23:56
johnsomOh yes it can...  I have a long history with SNMP and the code bases...23:56
leitanjust kidding, /ME thinking a more lightweight elegant solution23:57

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