Wednesday, 2018-04-25

johnsomrm_work Have second for a second opinion?00:10
rm_workI have a minute for a minute opinion00:10
johnsomEven better00:11
johnsomhttps://docs.openstack.org/octavia/latest/contributor/specs/version1.1/enable-provider-driver.html#load-balancer00:11
johnsomfor update in the spec00:11
johnsomIt's vague whether you will get a full load balancer object with fields of None or a custom object with just the update fields00:11
johnsomTrying to decide if I should add "update" objects to https://review.openstack.org/#/c/558320/4/octavia/api/drivers/data_models.py00:12
johnsomOr update the to_dict method on the existing object to optionally fish out the Nones00:13
johnsomIt seems like update objects are more explicit, but the other way *may* allow us to add update fields easier.00:13
johnsomOpinion?00:14
johnsomFrankly anyone else that is still around is welcome to join the party00:14
rm_workreading00:17
johnsomI think I answered my own question. I can't fish out the Nones as it could be updating to None. Yep, need another object I think.00:17
rm_worklolk00:17
johnsomI guess I could create an "unset" type like wsme00:18
rm_workYeah, that might be best00:18
rm_workmaybe00:18
rm_workhmm00:18
rm_worklet me noodle00:18
rm_workhave to think as if i were a provider writing a driver00:19
johnsomI know this was a pain point with the handler too00:19
rm_workIIRC most of the providers wanted us to pass them the entire fully-populated object anyway even on updates O_o00:19
johnsomNo, just one did00:19
johnsomWell, one wanted the whole LB tree on every call00:20
rm_worklol yeah00:20
johnsomOctavia will pass in a load balancer object with the fields to be updated.00:21
johnsomThat line implies partial to me00:21
rm_workyes00:21
rm_workbut we can always propose spec updates00:21
johnsomRight00:21
rm_workbut yeah, probably an "Unset" type is fine00:22
johnsomOk, I think that is good and clear.  I will make it so00:22
rm_workstill annoying that the openstack client can't filter images based on tags01:06
rm_workthe glance API can tho... right? I mean, otherwise wtf01:06
*** ianychoi has quit IRC01:11
*** ianychoi has joined #openstack-lbaas01:12
*** slaweq has joined #openstack-lbaas01:17
*** lxkong has quit IRC01:18
*** slaweq has quit IRC01:21
rm_workjohnsom: whelp01:31
openstackgerritAdam Harwell proposed openstack/octavia master: Fix amphora failover API to work with spares  https://review.openstack.org/56408201:31
rm_worki messed that one up to start :P01:31
openstackgerritAdam Harwell proposed openstack/octavia master: Experimental multi-az support  https://review.openstack.org/55896201:51
johnsomWhelp?02:06
*** fnaval_ has joined #openstack-lbaas02:28
*** fnaval has quit IRC02:28
*** lxkong has joined #openstack-lbaas03:02
*** slaweq has joined #openstack-lbaas03:18
*** slaweq has quit IRC03:22
*** yamamoto has quit IRC04:29
*** links has joined #openstack-lbaas04:29
*** ianychoi has quit IRC04:41
*** ianychoi has joined #openstack-lbaas04:44
*** Alex_Staf has joined #openstack-lbaas04:46
*** yamamoto has joined #openstack-lbaas04:50
*** ianychoi has quit IRC05:01
*** ianychoi has joined #openstack-lbaas05:03
rm_workjohnsom: was referring to Fix amphora failover API to work with spares  https://review.openstack.org/56408205:21
*** yboaron has joined #openstack-lbaas05:27
*** yboaron has quit IRC05:28
*** yboaron has joined #openstack-lbaas05:28
*** ianychoi has quit IRC05:37
*** ianychoi has joined #openstack-lbaas05:39
*** ianychoi has quit IRC05:46
*** ianychoi has joined #openstack-lbaas05:49
rm_worknmagnezi / cgoncalves: so in centos, our vip config is on eth1:0 and we drop a config into `/etc/netns/amphora-haproxy/sysconfig/network-scripts/ifcfg-eth1:0`06:13
rm_workbut on the amp i just built, the interface didn't actually come up06:13
rm_work<_<06:13
rm_worketh1 came up inside the ns, but no eth1:006:15
rm_workdid something change that means that doesn't come up automatically anymore?06:15
rm_workhmmm well actually, something else may be going on, as it looks like the vip didn't get bound right anyway06:20
rm_worki'll look at it in the morning06:20
cgoncalvesrm_work, I don't think but would be pretty cool if we'd get better performance on 1.5 xD06:43
cgoncalvesrm_work, I'd need to check that. actually the kuryr folks have reported to me that members cannot access the vip ip06:47
*** slaweq has joined #openstack-lbaas06:54
*** tesseract has joined #openstack-lbaas07:01
*** pcaruana has joined #openstack-lbaas07:06
cgoncalvesoctavia/api/drivers/amphora_driver/driver.py07:07
cgoncalves\o/07:07
*** ianychoi has quit IRC07:33
*** ianychoi has joined #openstack-lbaas07:35
*** AlexeyAbashkin has joined #openstack-lbaas07:37
*** ianychoi has quit IRC07:46
*** ianychoi has joined #openstack-lbaas07:49
*** yboaron has quit IRC08:34
*** yboaron has joined #openstack-lbaas09:22
*** amitry has joined #openstack-lbaas09:29
*** ianychoi has quit IRC09:52
*** ianychoi has joined #openstack-lbaas09:54
*** ianychoi has quit IRC10:00
*** ianychoi has joined #openstack-lbaas10:03
*** AlexeyAbashkin has quit IRC10:10
*** ianychoi has quit IRC10:12
*** ianychoi has joined #openstack-lbaas10:17
*** yamamoto has quit IRC10:40
*** yboaron_ has joined #openstack-lbaas11:01
*** yboaron has quit IRC11:04
*** yamamoto has joined #openstack-lbaas11:07
*** yboaron_ has quit IRC11:09
*** yboaron has joined #openstack-lbaas11:12
*** atoth has joined #openstack-lbaas11:18
*** AlexeyAbashkin has joined #openstack-lbaas11:20
*** wolsen has quit IRC11:30
*** wolsen has joined #openstack-lbaas11:30
*** yamamoto has quit IRC12:08
*** raginbaj- has joined #openstack-lbaas12:18
*** raginbajin has quit IRC12:23
*** atoth has quit IRC12:23
*** dayou has quit IRC12:23
*** strigazi has quit IRC12:23
*** raginbaj- is now known as raginbajin12:23
nmagnezirm_work, ping12:23
*** atoth has joined #openstack-lbaas12:26
*** dayou has joined #openstack-lbaas12:26
*** strigazi has joined #openstack-lbaas12:26
*** gans has joined #openstack-lbaas12:55
*** gans has quit IRC13:00
*** pchavva has joined #openstack-lbaas13:01
*** samccann has joined #openstack-lbaas13:01
*** yamamoto has joined #openstack-lbaas13:04
*** yamamoto has quit IRC13:10
*** Alex_Staf has quit IRC13:23
*** fnaval_ has quit IRC13:30
*** fnaval has joined #openstack-lbaas13:31
*** fnaval has quit IRC13:35
*** fnaval has joined #openstack-lbaas13:50
*** leitan has joined #openstack-lbaas13:56
*** samccann has quit IRC14:02
*** samccann has joined #openstack-lbaas14:02
*** yamamoto has joined #openstack-lbaas14:06
*** yamamoto has quit IRC14:11
johnsomcgoncalves: I did a fix for members not being able to reach the vip IP using policy based routing. I wonder if that didn’t make it into the RH tribe code.14:34
cgoncalvesjohnsom, https://review.openstack.org/#/c/501915/ ? it's in since 2.0.0 so either something slipped (e.g. patch not taking effect in RH-based) or it's a different issue14:41
cgoncalvesI haven't yet had a chance to look at the issue :/14:42
johnsomYeah, that is the patch.14:43
*** atoth has quit IRC15:01
*** dayou has quit IRC15:01
*** strigazi has quit IRC15:01
*** AlexeyAbashkin has quit IRC15:01
*** andreykurilin has quit IRC15:01
*** numans has quit IRC15:01
*** kbyrne has quit IRC15:01
*** vegarl has quit IRC15:01
*** zigo has quit IRC15:01
*** ivve has quit IRC15:01
*** JudeC has quit IRC15:01
*** devfaz has quit IRC15:01
*** numans has joined #openstack-lbaas15:01
*** kbyrne has joined #openstack-lbaas15:01
*** vegarl has joined #openstack-lbaas15:01
*** zigo has joined #openstack-lbaas15:01
*** ivve has joined #openstack-lbaas15:01
*** JudeC has joined #openstack-lbaas15:01
*** devfaz has joined #openstack-lbaas15:01
*** atoth has joined #openstack-lbaas15:03
*** dayou has joined #openstack-lbaas15:03
*** strigazi has joined #openstack-lbaas15:03
*** AlexeyAbashkin has joined #openstack-lbaas15:04
*** andreykurilin has joined #openstack-lbaas15:04
*** keithmnemonic[m] has quit IRC15:04
*** yamamoto has joined #openstack-lbaas15:08
*** yamamoto has quit IRC15:13
*** yboaron has quit IRC15:30
*** xgerman_ has quit IRC15:53
*** xgerman_ has joined #openstack-lbaas15:53
*** pcaruana has quit IRC15:57
*** pcaruana has joined #openstack-lbaas15:59
*** srihas_ has joined #openstack-lbaas16:05
*** atoth_ has joined #openstack-lbaas16:06
*** pcaruana has quit IRC16:08
*** jmccrory_ has joined #openstack-lbaas16:09
*** atoth has quit IRC16:09
*** links has quit IRC16:09
*** yamamoto has joined #openstack-lbaas16:10
*** jmccrory has quit IRC16:10
*** srihas has quit IRC16:10
*** jmccrory_ is now known as jmccrory16:11
*** yamamoto has quit IRC16:15
*** keithmnemonic[m] has joined #openstack-lbaas16:19
xgerman_https://usercontent.irccloud-cdn.com/file/XFaNpVOX/Screen%20Shot%202018-04-25%20at%209.24.39%20AM.png16:24
*** slaweq has quit IRC16:48
*** sshank has joined #openstack-lbaas16:50
*** coreycb has quit IRC16:57
*** coreycb has joined #openstack-lbaas16:58
*** slaweq has joined #openstack-lbaas16:58
*** links has joined #openstack-lbaas17:08
*** links has quit IRC17:09
*** AlexeyAbashkin has quit IRC17:11
*** yamamoto has joined #openstack-lbaas17:11
*** yamamoto has quit IRC17:16
*** pcaruana has joined #openstack-lbaas17:20
*** atoth_ has quit IRC17:46
rm_workwhelp17:55
rm_workbye bye Ihar17:55
johnsomYeah, he was good.17:56
*** atoth_ has joined #openstack-lbaas17:58
rm_workso yeah i need to poke at stuff again, something went wonky and i assumed it was because of my new image (I did one test LB with the spares that existed which worked, and the next test LB used the new image which didn't) but actually the VIP never got plugged to the second one, so probably something else is the issue17:58
rm_worki'll report back later17:58
johnsomOk17:58
rm_workbut yeah that spare amp failover bug was dumb17:59
rm_workand i feel bad17:59
johnsomI am noodling on object->dict and unset stuffs17:59
rm_work@johnsom: Munch?17:59
rm_workbrb18:00
*** sshank has quit IRC18:06
*** yamamoto has joined #openstack-lbaas18:12
*** kevinbenton has joined #openstack-lbaas18:17
*** yamamoto has quit IRC18:18
*** leitan has quit IRC18:20
*** kevinbenton_ has quit IRC18:22
*** sshank has joined #openstack-lbaas18:26
*** leitan has joined #openstack-lbaas18:39
*** leitan_ has joined #openstack-lbaas18:42
*** leitan has quit IRC18:43
*** pchavva has quit IRC18:43
*** leitan_ has quit IRC18:47
*** leitan has joined #openstack-lbaas18:47
*** velizarx has joined #openstack-lbaas18:54
*** pchavva has joined #openstack-lbaas18:57
*** leitan has quit IRC18:57
nmagnezijohnsom, storyboard meeting is now?19:00
johnsomnmagnezi Usually19:01
nmagnezilol19:01
johnsomYeah, looks like it is just starting19:01
*** atoth_ has quit IRC19:03
*** mrhillsman has joined #openstack-lbaas19:12
*** imacdonn has quit IRC19:14
*** yamamoto has joined #openstack-lbaas19:14
*** imacdonn has joined #openstack-lbaas19:14
*** sshank has quit IRC19:16
*** velizarx has quit IRC19:19
*** yamamoto has quit IRC19:20
*** velizarx has joined #openstack-lbaas19:24
*** velizarx has quit IRC19:34
*** AlexeyAbashkin has joined #openstack-lbaas19:48
*** AlexeyAbashkin has quit IRC19:52
*** cgoncalves_ has joined #openstack-lbaas19:53
*** pchavva has quit IRC19:54
*** AlexeyAbashkin has joined #openstack-lbaas19:57
*** rm_mobile has joined #openstack-lbaas19:58
johnsom#startmeeting Octavia20:00
openstackMeeting started Wed Apr 25 20:00:32 2018 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:00
*** openstack changes topic to " (Meeting topic: Octavia)"20:00
openstackThe meeting name has been set to 'octavia'20:00
cgoncalves_hi20:00
xgerman_o/20:00
johnsomHi all20:00
johnsom#topic Announcements20:01
*** openstack changes topic to "Announcements (Meeting topic: Octavia)"20:01
johnsomPTG is back in Denver Sept 10-1420:01
nmagnezio/20:01
johnsomSame hotel. In theory less train20:01
rm_mobile... how20:02
johnsomThe foundation is interested in how many folks plan to attend for room planning.20:02
johnsomI guess they fixed the crossing gate issue (or wrote it off) and the hotel installed better windows.20:02
rm_mobileLol k20:02
johnsomDoes anyone know if they are already planning to attend?20:02
xgerman_depends on funding…20:03
johnsomOk, I will take a guess and give them that based on previous attendance.20:03
johnsomYeah, I have no idea if I can make it yet either.20:03
xgerman_prob. more since we are in F5 land20:03
johnsomYeah, they might want some quality time with us to work on the driver20:04
johnsomAlso, TC elections are on. Check you inbox for you ballot email.20:04
johnsomThat is all I have for announcements. Any others?20:05
johnsom#topic Brief progress reports / bugs needing review20:05
*** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)"20:05
rm_mobileI will definitely try20:06
johnsomI have been buried in gate fixes, but have started work on the provider driver again.20:06
johnsomMaking decent progress, I have most of the LB API moved over to running through the new "octavia" driver.20:07
* johnsom Looks to see if Carlos is paying attention or not.20:07
cgoncalves_s/octavia/amphora :D20:07
johnsomI am making a few changes to the data model for drivers, just as a heads up in case someone is developing against my WIP data model patch20:08
*** rm_mobile has quit IRC20:08
johnsomI expect the provider driver work will be my focus for the rest of the week20:08
cgoncalves_johnsom: do you need help in any particular area? just reviewing?20:08
*** rm_mobile has joined #openstack-lbaas20:08
johnsomAny other progress updates?20:09
*** rm_mobile| has joined #openstack-lbaas20:09
johnsomKeeping reviews rolling on stuff is super helpful. Once I get over this data model work and get updates working I think the reset will fall together pretty quick.20:10
xgerman_famous last words “fall together quickly”20:10
*** rm_mobile has quit IRC20:10
johnsomYeah, exactly20:10
*** rm_mobile| has quit IRC20:10
cgoncalves_ok20:10
johnsomcgoncalves I will keep you in mind though, once the framework is in place I can probably hand off converting some of the other objects for parallel work.20:11
*** rm_mobile has joined #openstack-lbaas20:11
johnsom#link https://review.openstack.org/#/q/(project:openstack/octavia+OR+project:openstack/octavia-dashboard+OR+project:openstack/python-octaviaclient+OR+project:openstack/octavia-tempest-plugin)+AND+status:open+AND+NOT+label:Code-Review%253C0+AND+NOT+label:Verified%253C%253D0+AND+NOT+label:Workflow%253C020:12
cgoncalves_sure, ping me whenever you need20:12
johnsomThere are a bunch of patches open without reviews however, so that would be great too20:12
johnsomAny other progress updates?20:13
*** rm_mobile| has joined #openstack-lbaas20:13
*** rm_mobile| has quit IRC20:13
johnsom#topic Octavia deleted status vs. 40420:14
*** openstack changes topic to "Octavia deleted status vs. 404 (Meeting topic: Octavia)"20:14
*** rm_mobile| has joined #openstack-lbaas20:14
johnsom#link https://review.openstack.org/#/c/545493/20:14
johnsomLooks like the patch has a gate issue, I will look at that after the meeting.20:14
johnsomAny other updates on library support/no-support?20:15
rm_worki think the gate issue was a neutron bug20:15
*** rm_mobile has quit IRC20:15
rm_workjust needs a recheck20:15
johnsomI thought I have this handled in the new tempest plugin, but I guess I missed something20:15
rm_workjohnsom: i have a patch for that20:15
*** yamamoto has joined #openstack-lbaas20:15
rm_workhttps://review.openstack.org/#/c/563737/20:15
johnsomAh, sweet20:16
rm_workfixes all the way to the HM patch i had on top of your deleted one20:16
rm_workso hopefully we can merge all the way up there20:16
rm_workand the constraints patch (because our l-c is broken)20:16
johnsomOk, cool20:16
johnsomYeah, more good stuff needing reviews20:17
rm_workI did also get the proxy-gate passing in neutron-lbaas, where it just adds an L7 proxy for /lbaas/ direct to octavia from neutron20:17
rm_workcould use eyes and opinions on the test changes that were made to accomodate that, to make sure there's nothing too dumb (because changing tests to make them pass is normally dirty)20:18
rm_workhttps://review.openstack.org/#/c/561049/20:18
rm_workmost of them are around one bug (which is that octavia ignores tenant-id on subobjects)20:18
xgerman_and here is the other proxy: https://review.openstack.org/#/c/539350/20:19
johnsomWell, having different project-ids for different parts of a single load balancer doesn't really make any sense, so....20:20
rm_workyes20:20
rm_workthe tests were negative tests to make sure it exploded20:20
rm_workwhereas octavia just ignores them entirely20:20
rm_workso the question is, should octavia change to also reject the requests, or should the tests just expect either20:20
johnsomYeah, until the deprecation cycle is up.20:20
rm_workbecause I could make the patch to octavia to make it actually check those ids, and actually reject requests where they don't match correctly20:21
*** yamamoto has quit IRC20:21
rm_workthe question is, should we?20:21
rm_workor should we skip/fix those "bad" negative tests20:21
xgerman_my proxy handles tenant_id just fine20:21
*** velizarx has joined #openstack-lbaas20:21
xgerman_but yeah, skipping tests is fine20:22
rm_workyeah, my goal is different than yours20:22
johnsomAh, they can be removed in "S"20:22
rm_worki'm trying to prove octavia's backwards-compatibility20:22
rm_workand this proves there are some differences20:23
rm_workso, what do we do about that20:23
xgerman_backward compatible != parot every single thing n-lbaas does20:23
rm_workk20:23
rm_workthat's one20:23
rm_worki'd need another person to agree to get a merge, at least :P20:23
*** rm_mobile| has quit IRC20:24
johnsomI guess I am fine with patching octavia to slightly care about submitted project_ids on sub-objects. But on the otherhand I doubt it really matters/gets used, so skipping is ok too.20:24
*** sshank has joined #openstack-lbaas20:24
rm_workk20:24
johnsomLet's move on in the agenda and come back to proxies in open discussion20:25
cgoncalves_octavia resources are immutable on transient states. neutron-lbaas´ are not, or are so quick to flip between states that most users don´t notice it and hence further requests succeed20:25
xgerman_+120:25
johnsomneutron-lbaas resources are in fact immutable during transitions.20:26
johnsomIt is true that some drivers will flip those back to active faster than others.20:26
*** AlexeyAbashkin has quit IRC20:27
rm_workyes. though, neutron-lbaas also lies on returns for updates20:27
rm_workwhereas octavia does not20:27
rm_workbut yeah, let's move on and come back to this20:27
johnsomThe locking in neutron-lbaas is broken pretty badly and high rates of API requests can sometimes get through when it is in an immutable state.20:27
johnsomYep.20:27
johnsom#topic Muttable config for neutron-lbaas20:28
*** openstack changes topic to "Muttable config for neutron-lbaas (Meeting topic: Octavia)"20:28
johnsomSo there is a community goal to enable muttable Oslo configs in projects20:28
johnsom(we still need to do that)20:28
*** leitan has joined #openstack-lbaas20:28
johnsomneutron-lbaas proper will inherit this from neutron as it runs under the neutron context.20:28
rm_worki really think it has only one `t` ;P20:29
johnsomHowever, there are some sub-processes in neutron-lbaas20:29
rm_workdo we even have to worry about n-lbaas20:29
rm_worki say we skip it20:29
johnsomYeah, it does. Opps, copied over the typo from the agenda20:29
johnsomSo someone proposed a patch for neutron-lbaas to enable this:20:30
johnsom#link https://review.openstack.org/#/c/559412/20:30
rm_workok, so, enable it for no actual vars right?20:30
rm_workfine by me, merge that, call it done20:30
johnsomI initially -1'd it because this is a feature IMO and these are sub-processes that probably don't matter much.20:30
johnsomI see it was abandoned20:31
rm_workMy only point here is that we should not waste too much time on n-lbaas20:31
johnsomSo the question to the team is "do we care"?20:31
rm_workdoing something like this that just doesn't matter20:31
rm_workso20:31
rm_workobviously you know my answer20:31
johnsomWell, that makes two votes of "don't care". Any other comments?20:32
xgerman_I have seen people fixing bugs/making improvements on n-lbaas so if a patch show up…20:32
johnsomOk then, leaving it abandoned20:32
cgoncalves_johnsom: you made a good point, though: n-lbaas runs under the neutron context so it will inherit from it. it would be half implemented if not extending to sub-processes20:33
johnsomFixing bugs is of course still important for neutron-lbaas, but features no.20:33
cgoncalves_again, neutral vote from my side20:33
johnsomOk, I think we leave it as-is.20:33
johnsom#topic Open Discussion20:34
*** openstack changes topic to "Open Discussion (Meeting topic: Octavia)"20:34
johnsomOk, other topics?20:34
rm_work<<20:35
* johnsom taps the mic to see if it is on20:35
nmagnezijust to keep everyone posted20:35
nmagneziwe discussed the storyboard issues that were raised here a few weeks ago20:36
nmagneziwith the storyboard team20:36
nmagnezisee: http://eavesdrop.openstack.org/meetings/storyboard/2018/storyboard.2018-04-25-19.02.log.html#l-4020:36
nmagneziwe will follow up next week.20:36
*** velizarx has quit IRC20:36
nmagnezi#link http://eavesdrop.openstack.org/meetings/storyboard/2018/storyboard.2018-04-25-19.02.log.html#l-4020:37
johnsomI also see some chatter in their IRC channel20:37
johnsomThough it's "use tags" so maybe not what you are looking for.20:38
nmagneziindeed it's not..20:38
johnsomcgoncalves_ Did we answer your neutron-lbaas questions (statement) above?20:38
cgoncalves_johnsom: yes20:39
*** tesseract has quit IRC20:40
rm_worksooo.... proxy?20:40
johnsomOk, yeah, the locking in neutron-lbaas would require a complete rewrite to completely fix. Oh, wait, I have that right here.......20:41
rm_worklol yes20:41
rm_workFor the proxy thing, really the core question is: how backwards compatible do we need/want to be with neutron-lbaas?20:41
cgoncalves_the kuryr folks were expecting octavia to be fully compatible with n-lbaas, including heat support. took some time to convince them it doesnt work as they would have hoped20:41
rm_workreally the only tests that don't pass when run directly against octavia are some of the negative stuff20:41
rm_workI did find a couple of real bugs, which i have patches up for20:42
rm_workcgoncalves_: so, what i am proving is that it CAN Be20:42
johnsomcgoncalves_ Yes, it should be basically switching the endpoint. If it's not I would like to know what they ran into.20:42
rm_workcgoncalves_: did you look at the proxy gate i am testing?20:42
xgerman_there is such a big need for backwards compatibility that we have two proxies20:42
cgoncalves_rm_work: pssssst! they could be reading :P20:42
*** pcaruana has quit IRC20:42
johnsomWe are making the hard call to even pull forward some neutron bugs (IMO) to make it compat20:43
cgoncalves_rm_work: not yours, no, sorry20:43
rm_workcgoncalves_: i am literally putting haproxy in front of neutron, and L7-Redirecting calls to lbaas to the octavia API20:43
rm_workso zero code changes, no neutron-lbaas installed at all, it will work20:43
rm_work*zero code changes in end-user apps20:44
rm_workit requires us to add a compatibility layer in octavia20:44
johnsomAt least up to the level the neutron-lbaas tempest tests  are testing20:44
cgoncalves_johnsom: I quickly set up an env with neutron-lbaas+octavia driver and ran heat neutron-lbaas resources. it failed because of immutability so I hard stopped there20:44
rm_workmainly it's about the deprecated tenant-id stuff20:44
xgerman_cgoncalves_:  that won’t be fixed in any of them20:45
rm_workcgoncalves_: well, our immutability is the same as neutron-lbaas, sooooo if that was broken, then it's broken for n-lbaas too20:45
rm_workand if it works, it's only by sheer luck20:45
johnsomcgoncalves_ I'm not following. Both use the PENDING_* states20:45
xgerman_heat probably doesn’t wait20:46
johnsomWas heat just not checking them in neutron-lbaas?20:46
cgoncalves_ah, sorry. I meant to say an env with neutron-lbaas + proxy to octavia (not the octavia driver itself)20:46
rm_workif so, that's broken for either neutron-lbaas OR octavia20:46
rm_workcgoncalves_: my style of proxy or xgerman_'s?20:46
xgerman_mine20:46
johnsomlol20:46
cgoncalves_rm_work: xgerman_'s20:47
rm_workk20:47
johnsomAh, yeah, xgerman's proxy wasn't working until like this week20:47
xgerman_but as I said earlier having tow proxies is confusing for users20:47
rm_workyeah...20:47
xgerman_it was working20:47
xgerman_just not passing the tests20:47
johnsomNot that I ever saw20:47
cgoncalves_johnsom: I quickly had a look at the heat support for neutron-lbaas and there are some waiting/status polling20:47
johnsomOk, yeah, it should be "the same"20:48
rm_workxgerman_: i'd rather not get into "there can only be one"20:48
rm_workespecially since, my "proxy" isn't actually anything20:48
rm_workit's just a method20:48
rm_workno code20:48
cgoncalves_anyway, they were still using on n-lbaas because octavia doc was recommending that. I submitted a doc patch to fix that20:49
rm_workbut it is what i have been recommending and will continue to recommend20:49
johnsomYeah, that doc change merged right?20:49
cgoncalves_yes20:49
johnsomCool20:49
johnsomYeah, I don't have a problem with providing options for folks migrating.20:51
johnsomI don't think we want to "support" anything that isn't gating though. Plus I don't want to load up the octavia repo with stuff that is neutron-lbaas specific beyond having a compatible API.20:52
rm_workyeah, need to decide exactly how to progress with that20:52
rm_workthe patch i have on the neutron-lbaas side is *just* a gate20:52
xgerman_my plan is to fix the gate (obviously)20:52
rm_workand a few test fixes (a lot of which are similar to / based on the ones in xgerman_'s proxy patch)20:53
johnsomIs there something we need to decide here or just discussion of the parallel paths / options for migration?20:55
rm_workwanted to ask if we should try to make octavia 100% compatible even with the negative test stuff20:56
rm_workor if it's ok to just ignore some of those20:56
rm_workbecause no one will likely see the difference20:56
rm_workunless they were relying on neutron blocking bad calls20:56
rm_workin a very specific way20:57
xgerman_I think we should chart our own course … and only do stuff which was in the API doc and not some quirks n-lbaas had20:57
*** samccann has quit IRC20:58
johnsomThe project_id on the sub-objects was an admin only thing that doesn't make any sense. As octavia is coded, it will "do the right thing", just silently instead of slapping your wrist.20:58
xgerman_+120:58
johnsomWere there any others?20:58
rm_workk that's pretty much it20:59
johnsomOk cool.20:59
johnsomWe are about out of time anyway.20:59
johnsomThanks folks!20:59
johnsom#endmeeting20:59
*** openstack changes topic to "Discussion of OpenStack Load Balancing (Octavia) | https://etherpad.openstack.org/p/octavia-priority-reviews"20:59
openstackMeeting ended Wed Apr 25 20:59:43 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-04-25-20.00.html20:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-04-25-20.00.txt20:59
openstackLog:            http://eavesdrop.openstack.org/meetings/octavia/2018/octavia.2018-04-25-20.00.log.html20:59
cgoncalves_johnsom, xgerman_, rm_work: btw, I herein invite you to attend http://connect.trilio.io/trilio-red-hat-invite-you (hopefully they're still taking new registrations)21:00
cgoncalves_with that, I'm out for today.21:00
johnsomlol Thanks!21:00
*** cgoncalves_ has quit IRC21:00
xgerman_THANKS!!21:01
rm_work;P21:01
xgerman_Ryan would never have done that21:01
johnsomDoes this mean we have to help him with OSP 13 now?21:02
rm_workrsvp'd ;)21:02
*** sshank has quit IRC21:04
*** diablo_rojo has joined #openstack-lbaas21:06
diablo_rojonmagnezi, I am almost done going though your super helpful list: https://etherpad.openstack.org/p/storyboard-issues21:07
diablo_rojoJust wanted to give you a heads up21:07
nmagnezi diablo_rojo thank you! :)21:07
diablo_rojoThere are one or two I am looking for if stories already exist. If they don't, I will make them and add links.21:08
diablo_rojonmagnezi, we care about you and want you to be happy using storyboard :) Just having growing pains, the same as all projects/software does.21:08
rm_workoh i forgot to check if "make comments editable" is on there, lol21:16
rm_workthat would help with the bad formatting, a lot of it is just "oops, did that wrong" but no way to fix it21:17
*** yamamoto has joined #openstack-lbaas21:17
johnsomNot too late to add21:18
*** openstackgerrit has quit IRC21:20
*** leitan has quit IRC21:21
*** yamamoto has quit IRC21:23
*** slaweq has quit IRC22:17
*** threestrands has joined #openstack-lbaas22:17
*** slaweq has joined #openstack-lbaas22:18
*** yamamoto has joined #openstack-lbaas22:19
*** slaweq has quit IRC22:23
*** yamamoto has quit IRC22:24
*** rcernin has joined #openstack-lbaas22:52
*** sshank has joined #openstack-lbaas23:03
*** yamamoto has joined #openstack-lbaas23:09
*** diablo_rojo has quit IRC23:10
*** fnaval has quit IRC23:29
rm_workdoes anyone recall offhand how the keepalived check script gets put in /bin/ on the amp?23:32
rm_workis that by the agent at runtime when we do something, or does it ship?23:32
rm_workthat's my problem -- it's just... gone23:33
rm_workwhen I create an LB on the old image, it's there, but on the new one it isn't23:33
rm_workso i'm assuming it's shipped?23:33
rm_workand somehow i broke it?23:33
*** threestrands_ has joined #openstack-lbaas23:35
rm_workOHHHH23:36
rm_workjohnsom broke it23:36
rm_workit ends up in /opt/amphora-agent-venv/bin/haproxy-vrrp-check23:36
johnsomOh23:36
rm_workApr 25 23:37:02 advk98hohd0vj8p.cloud.sin2.gdg Keepalived_vrrp[1603]: /var/lib/octavia/vrrp/check_script.sh exited with status 12723:37
rm_workso i get a ton of that23:37
rm_workhmmm23:38
*** threestrands has quit IRC23:38
rm_workthough i need to see if it's because it can't find it23:38
rm_workor if it's because it is actually breaking23:38
rm_workbut it definitely broke something else of mine :P23:38
rm_workI guess I need to link it in to /bin23:38
rm_workwhen i source the venv and then run the check script23:39
rm_workI get exit code 023:39
rm_workyeah23:39
rm_workand without it sourced i get 12723:39
rm_workso yes, keepalived is failing23:39
rm_workit's not running inside the venv23:39
rm_workand it can't find the right thing23:40
rm_workjohnsom: is this purely a centos problem? did you fix this for ubuntu?23:40
rm_worki thought i saw something in the change about linking the files back to bin23:40
johnsomI did do some linking in the amp-agent element23:41
johnsomBut I don't think it fixes this23:41
rm_workah just the agent23:41
rm_workyeah so23:41
rm_workthis should be broken for master for everyone, yes?23:41
rm_workor is this a just-me problem somehow23:42
johnsomI'm not sure...23:42
johnsomSadly, we don't have an act/stdby gate23:42
rm_workpretty sure keepalived doesn't run inside the venv23:42
rm_workbecause why would it23:42
rm_workin which case, the script is not in path23:42
rm_workso... do we link out that script too?23:43
rm_workis that the fix?23:43
johnsomNo, and should not23:43
johnsomI'm confused, because that script and it's calls to it should always be in /var/lib/octavia23:44
rm_workerrr what?23:44
rm_workno23:44
rm_workin our keepalived conf23:44
rm_workwe call /var/lib/octavia/vrrp/check_script.sh23:44
rm_workand that file runs everything in /var/lib/octavia/vrrp/check_scripts/23:45
rm_workand that script doesn't provide a full path23:45
rm_workit just runs `haproxy-vrrp-check /var/lib/octavia/2ead852d-0808-41df-bdac-e30066d0c04d.sock; exit $?`23:45
*** fnaval has joined #openstack-lbaas23:45
rm_workor you know, whatever the sock23:45
*** fnaval has quit IRC23:45
rm_workso the actual `haproxy-vrrp-check` script needs to be in PATH23:46
*** fnaval has joined #openstack-lbaas23:46
johnsomOh, ok, so it's that part. This makes more sense now23:46
rm_workbecause that's `haproxy-vrrp-check = octavia.cmd.haproxy_vrrp_check:main`23:46
rm_workinstalled in the venv23:46
rm_workSO23:47
rm_workshould we link it out, along with the agent?23:47
johnsomYeah, ok23:47
rm_workand, yes, this is broken in master for everyone23:47
johnsomYes, that is what needs to happen23:47
rm_workok23:47
rm_worki'll do that23:47
johnsomOk23:47
johnsomI totally forgot all about that command23:47
*** sshank has quit IRC23:48
rm_workso23:49
*** openstackgerrit has joined #openstack-lbaas23:49
openstackgerritAdam Harwell proposed openstack/octavia master: Fix keepalived vrrp check script to be in PATH  https://review.openstack.org/56437123:49
rm_workif we can merge it like that ^^ I will be appreciative23:49
rm_workit saves me from extra patching23:49
rm_workif you're not ok with that... I can add it to my list of internal patches23:50
rm_work(I have my own haproxy-vrrp-alert script)23:50
rm_work;)23:50
johnsomThat works? a multiple link like that?23:51
rm_workyes23:52
rm_workI mean, i'm 99% sure23:52
rm_worki do stuff like that all the time IIRC23:52
rm_worklet me verify23:52
rm_workoh23:52
johnsomyes23:52
johnsomit does23:52
rm_worki mean yes, i actually did exactly that to test23:52
rm_worklol23:52
rm_worki forgot23:52
johnsomSo, I would love to -1 for a test, but I think we need to get this in23:52
rm_workand yeah normally with linking i don't bother specifying the destination filename23:52
rm_workhow do we test this :/23:53
rm_workwe have no tests for elements do we?23:53
johnsomtempest plugin23:53
rm_workah yes23:53
rm_worksoooo23:53
rm_workwe need an active/standby test23:53
rm_worklol23:53
rm_work-1 for ADD ACTIVE STANDBY GATE TO TEMPEST23:53
rm_worklol23:53
rm_workI would be sad :P23:53
rm_workbrb23:55

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