Thursday, 2020-01-30

« Wednesday, 2020-01-29 Index Friday, 2020-01-31 »
*** luksky has quit IRC01:04
*** armax has quit IRC01:24
*** mithilarun has quit IRC01:27
*** goldyfruit_ has quit IRC01:43
*** armax has joined #openstack-lbaas02:04
*** armax has quit IRC02:49
*** sapd1 has joined #openstack-lbaas03:20
*** psachin has joined #openstack-lbaas03:35
*** sapd1 has quit IRC04:46
*** sapd1 has joined #openstack-lbaas04:59
*** ramishra has joined #openstack-lbaas05:10
*** sapd1 has quit IRC05:24
rm_worksorrison: found an icky bug T_T05:46
rm_worksorrison: https://github.com/openstack/octavia/blob/master/octavia/compute/drivers/nova_driver.py#L253-L26305:47
rm_workif you have a *default* AZ set up (so, in config you specify an availability_zone and amp_boot_network_list for the management net) and you also set up another AZ with the azprofile+az, and try to create a LB in it... this code won't find the right management interface and you'll end up with no lb_network_ip05:49
rm_workbut there's not an easy way here to actually tie this to an LB or AZ05:50
rm_workit's a few layers deep away from actually knowing/caring about anything besides the compute id05:50
rm_workwould need to change compute_base :/05:51
*** mithilarun has joined #openstack-lbaas06:10
*** mithilarun has joined #openstack-lbaas06:11
*** mithilar_ has joined #openstack-lbaas06:37
*** mithilarun has quit IRC06:40
*** mithilar_ has quit IRC06:40
*** mithilarun has joined #openstack-lbaas06:41
openstackgerritAdam Harwell proposed openstack/octavia master: Select the right lb_network_ip interface using AZ  https://review.opendev.org/70492706:51
rm_worksorrison: ^^ FYI06:51
*** luksky has joined #openstack-lbaas07:14
*** mithilar_ has joined #openstack-lbaas07:26
*** mithilarun has quit IRC07:29
*** mithilar_ has quit IRC07:30
*** AlexStaf has joined #openstack-lbaas07:32
*** gcheresh_ has joined #openstack-lbaas07:46
*** tesseract has joined #openstack-lbaas07:47
*** maciejjozefczyk has joined #openstack-lbaas07:53
*** gcheresh_ has quit IRC08:09
*** gcheresh_ has joined #openstack-lbaas08:13
*** rpittau|afk is now known as rpittau08:14
*** tkajinam has quit IRC08:15
*** gcheresh_ has quit IRC08:47
*** gcheresh_ has joined #openstack-lbaas08:50
*** luksky has quit IRC08:58
*** gcheresh_ has quit IRC09:15
*** ivve has joined #openstack-lbaas09:19
*** gcheresh_ has joined #openstack-lbaas09:22
*** luksky has joined #openstack-lbaas09:35
*** gcheresh_ has quit IRC09:36
*** gcheresh_ has joined #openstack-lbaas09:41
*** salmankhan has joined #openstack-lbaas10:09
*** spatel has joined #openstack-lbaas10:29
*** spatel has quit IRC10:34
*** pcaruana has quit IRC10:46
*** spatel has joined #openstack-lbaas10:47
*** devfaz has quit IRC10:54
*** devfaz has joined #openstack-lbaas10:55
*** rpittau is now known as rpittau|bbl11:14
*** ccamposr has joined #openstack-lbaas11:17
*** ramishra has quit IRC11:47
*** pcaruana has joined #openstack-lbaas11:48
*** ramishra has joined #openstack-lbaas12:02
*** pcaruana has quit IRC12:21
*** goldyfruit_ has joined #openstack-lbaas12:59
*** AlexStaf has quit IRC13:00
*** maciejjozefczyk has quit IRC13:21
*** rpittau|bbl is now known as rpittau13:29
*** maciejjozefczyk has joined #openstack-lbaas13:30
openstackgerritCarlos Goncalves proposed openstack/neutron-lbaas-dashboard stable/stein: Fix auth url for Barbican client  https://review.opendev.org/70500813:44
openstackgerritCarlos Goncalves proposed openstack/neutron-lbaas-dashboard stable/rocky: Fix auth url for Barbican client  https://review.opendev.org/70500913:45
openstackgerritCarlos Goncalves proposed openstack/neutron-lbaas-dashboard stable/queens: Fix auth url for Barbican client  https://review.opendev.org/70501113:46
*** pcaruana has joined #openstack-lbaas14:03
*** psachin has quit IRC14:32
*** pcaruana has quit IRC14:34
*** gcheresh_ has quit IRC14:45
*** gcheresh_ has joined #openstack-lbaas14:48
*** pcaruana has joined #openstack-lbaas15:02
*** salmankhan1 has joined #openstack-lbaas15:03
*** gcheresh_ has quit IRC15:04
*** salmankhan has quit IRC15:04
*** salmankhan1 is now known as salmankhan15:04
*** trident has quit IRC15:06
*** trident has joined #openstack-lbaas15:17
*** psachin has joined #openstack-lbaas15:29
*** salmankhan1 has joined #openstack-lbaas15:35
*** salmankhan has quit IRC15:38
*** salmankhan1 is now known as salmankhan15:38
*** spatel has quit IRC15:43
*** armax has joined #openstack-lbaas15:44
*** TrevorV has joined #openstack-lbaas15:44
*** Trevor_V has joined #openstack-lbaas15:47
*** TrevorV has quit IRC15:51
*** spatel has joined #openstack-lbaas15:53
*** nmickus has joined #openstack-lbaas16:01
*** nmickus has quit IRC16:04
*** nmickus has joined #openstack-lbaas16:05
*** maciejjozefczyk has quit IRC16:06
*** nmickus has quit IRC16:06
*** ivve has quit IRC16:10
johnsomhttps://www.irccloud.com/pastebin/apVLTDQj/16:23
*** ccamposr has quit IRC17:04
*** dawzon has joined #openstack-lbaas17:08
*** tesseract has quit IRC17:08
*** stevenglasford__ has joined #openstack-lbaas17:29
rm_workjohnsom: could you glance at https://review.opendev.org/#/c/704927/ ?17:41
rm_workunrelated-ish, not sure why it got that random test failure, should be completely unrelated17:42
rm_worksince it only failed on one of the 2-4 places it ran? >_>17:42
rm_workyep, 417:43
*** salmankhan has quit IRC17:46
johnsomWas dealing with storyboard. Looking.17:46
rm_workanyway recheck should take care of that i assume17:50
rm_workbut the main issue is... an issue17:50
rm_workjust want eyes on it because i'm about 10 minutes from merging it internally and deploying to prod :D17:51
johnsomI really don't like that "get_amphora" needs a management_network_id parameter......17:51
johnsomThe compute driver *should not care*17:52
johnsomrm_work Yeah, don't like it17:58
rm_workwell look what it does17:58
rm_workit obviously cares17:59
rm_workit already loads the management networks17:59
rm_workit just loads them statically from config17:59
rm_workif it didn't care, i wouldn't need to make this modification17:59
johnsomI think you are missing my point. There is no reason I should need to pass that into get_amphora in the compute driver. The compute driver should not care about the lb-mgmt-net.18:01
rm_workok, then ignoring my patch, we need to rewrite that function18:01
rm_workdo you agree with that?18:01
rm_workthe function is already bad18:01
johnsomSince the underlying code seems to care and blurs that line, we should hide this AZ issue too or simply remove that from the model if it's not used.18:01
johnsomYeah, we are on the same page for that18:01
rm_workok, so it should just return all of the interfaces18:02
rm_workand there should be a different function that understands the other bits, in a different place18:02
johnsomThat seems more logical for a compute driver to me18:02
rm_workand that should do the filtering18:02
rm_workk18:02
*** rpittau is now known as rpittau|afk18:02
rm_workthis is going to take me a bit to get to then18:02
rm_worki guess i'll have to run this internally until then18:02
johnsomIt's trying to shove the nova data into the Amphora data model, which, maybe isn't the right answer. Maybe there needs to be a compute data model amphora object? or leave more bits "None".18:04
rm_workmaybe? but then how do we deal with that info18:05
johnsomAnother interim is to just pull the AZ records since you have the AZ from nova, and get the mgmt net info from that. It would still hide the ugly18:05
rm_workand is it specific to the compute driver how the interfaces are plugged on compute?18:05
rm_workuhh you can't18:05
rm_worknova az != az18:05
rm_workalso there is no DB access in that part of the driver18:05
rm_worki could pass the AZ object through entirely18:05
johnsomDidn't I argue that AZ should == nova AZ?18:06
rm_workbut i opted for passing the smallest granularity18:06
rm_workyou may have? but that's a bad idea18:06
rm_workbut18:06
rm_work*so, we didn't do that18:06
johnsomAh, but there is a mapping in the az profile right.18:06
johnsomThat is what I argued for I think18:06
rm_workyeah so ... assuming there is only one AZ profile using that nova AZ (which we don't guarantee) and we had access to the DB at that layer of the driver (we do not) then yeah, we could pull it18:07
rm_workthat was the first thing i tried to do, for all of about 20 seconds :D18:07
rm_workbefore i realized it's a no-go18:07
johnsomYeah, ok, I see....18:07
johnsomWould have to go from amp record down18:08
rm_workamp record don't have it18:08
rm_workLB has it18:08
rm_workand as of yet, amp record isn't linked to LB at this stage18:08
rm_work(we have another patch up to do that tho)18:08
johnsomYeah, so, ok, back to the original plan then. See if we can nuke that lb_mgmt_ip field18:09
rm_workyeah so that requires us to not do the net filtering at that level (so, no returning the lb_network_ip)18:09
rm_workwe'd need to return more raw data? and then parse it out18:09
rm_workin ... some other place?18:09
johnsomI'm not sure it's even used at all18:09
johnsomSo, I would check that first18:10
rm_work??18:10
rm_workyes it absolutely is18:10
rm_workthat's the management IP address18:10
rm_workwhich needs to be in the amp record in literally the next action18:10
rm_work(compute wait)18:10
rm_workthat is how i found this issue18:10
johnsomBut I bet 99%+ of the code uses that from the DB record, not the return from an compute amphora get18:10
rm_workright18:10
rm_workbut this function is called in the flow that updates the DB18:10
johnsomAh, got it18:10
rm_workwe've got a very tight window18:11
johnsomAt that point in the code, that IP should be the *only* one on the nova amp.18:12
rm_worktheoretically?18:12
johnsomHmm, maybe that isn't true in all clouds18:12
rm_workright18:12
johnsomI remember someone had some other automagic IPs18:12
rm_workyes18:12
johnsomSo, we need to the get the list of possible lb-mgmt-nets down to that method18:12
rm_workyes18:12
rm_workexcept the only place it CAN be a list is in that config item18:13
rm_workwhich we really need to deprecate <_<18:13
rm_workand make a single network-id18:13
johnsomAgreed18:13
johnsomOk, so catching up.18:13
johnsomlol18:13
rm_worki considered reading the config outside of there, and passing it through at the layer above18:13
rm_workthe difference is minimal but totally doable18:14
rm_workjust cut/paste the logic up to the task layer18:14
rm_workand pass only the correct *list* (sigh)18:14
*** mithilarun has joined #openstack-lbaas18:14
johnsomIt's the union of the list of lb-mgmt-nets in the AZ profiles and the default config option. right?18:15
*** numans has joined #openstack-lbaas18:16
*** gcheresh has joined #openstack-lbaas18:19
rm_workno18:22
rm_workAZ profile overrides config option18:22
rm_workif there's one from the AZ, it uses that one only18:22
rm_workif there isn't, it uses the config one18:22
rm_work(even if that's None)18:22
johnsomrm_work Ok, you brought me around on this. I posted a few new comments with the idea of moving forward with the optional pass in.18:23
johnsomThough the more I think of it, I'm not sure it is optional.... or maybe something about the lb-mgmt-ip will be None....  ugh. This is messy18:24
*** luksky has quit IRC18:25
rm_workif it comes in as None, then we try the default config18:26
rm_workit doesn't really change the flow, it's just a higher level override18:26
johnsomYeah18:26
johnsomIt's almost a rename this method kind of thing18:26
johnsomBut I guess it's getting an "amphora" and not compute record18:27
johnsomBlah, yeah, just fix the =None and doc strings18:27
rm_workk i'll look in a moment18:30
*** armax has quit IRC18:33
*** gcheresh has quit IRC18:45
*** ivve has joined #openstack-lbaas18:47
*** stevenglasford has joined #openstack-lbaas18:54
*** stevenglasford__ has quit IRC18:55
rm_workYeah k will take care of that 👍18:56
*** gcheresh has joined #openstack-lbaas19:07
*** armax has joined #openstack-lbaas19:08
*** luksky has joined #openstack-lbaas19:14
*** luketollefson has joined #openstack-lbaas19:17
*** gcheresh has quit IRC19:28
*** psachin has quit IRC20:16
*** mithilarun has quit IRC20:34
*** andy_ has quit IRC20:35
*** andy__ has joined #openstack-lbaas20:35
*** rcernin has quit IRC20:36
*** andy__ is now known as andy_20:36
*** mithilarun has joined #openstack-lbaas20:36
*** mithilarun has quit IRC20:41
openstackgerritAdam Harwell proposed openstack/octavia master: Select the right lb_network_ip interface using AZ  https://review.opendev.org/70492720:47
rm_workshould address your concerns johnsom20:47
johnsomOk20:48
*** mithilarun has joined #openstack-lbaas20:51
*** Trevor_V has quit IRC20:55
*** mithilarun has quit IRC20:55
*** mithilarun has joined #openstack-lbaas21:11
johnsomrm_work re-reviewed, I think there is a bug21:22
rm_workok21:23
rm_workit's not a bug21:39
rm_workthough i wrote the commit message explanation wrong, i see, lol21:39
rm_worksee: octavia/controller/worker/v2/tasks/compute_tasks.py:8621:40
rm_workliterally just above this in the same file21:40
rm_worksame AZ object21:40
johnsomrm_work so.... It's not an AZ object.... <glare> At a minimum can you add the doc string line for that. Really it would be nice to rename that to be something like az_metadata_dict or such.....21:42
rm_workk21:42
*** spatel has quit IRC21:46
rm_workok done21:47
openstackgerritAdam Harwell proposed openstack/octavia master: Select the right lb_network_ip interface using AZ  https://review.opendev.org/70492721:47
rm_workso these are the four changes that most directly affect me right now:22:06
rm_workAllow AZ to override valid_vip_networks config - https://review.opendev.org/69952122:06
rm_workConf option to use VIP ip as source ip for backend - https://review.opendev.org/70253522:06
rm_workSelect the right lb_network_ip interface using AZ - https://review.opendev.org/70492722:06
rm_workUpdate the lb_id on an amp earlier if we know it - https://review.opendev.org/69808222:06
rm_workI'll be trying to keep them up to date and ready to go22:06
rm_workthree of them have +1s already22:06
rm_workat least one or two of them shouldn't be especially contentious22:06
rm_workthe vip-source-ip might be <_<22:07
*** sapd1 has joined #openstack-lbaas22:25
*** sapd1_ has quit IRC22:26
openstackgerritMerged openstack/octavia master: Fix unit test when run on CentOS 7  https://review.opendev.org/69795822:35
johnsomMichael's tip of the day: Want to use wireshark on a remote devstack to monitor an interface inside a network namespace such as the neutron qrouter?22:37
johnsomip netns exec qrouter-28ed9736-5bca-47de-acdc-22dbdc79b91b tcpdump -U -s0 -n -l -w - -i qg-8f23a725-84 "icmp6" | wireshark -k -i -22:37
johnsomtcpdump through a pipe!22:37
openstackgerritMerged openstack/octavia master: Fix house keeping graceful shutdown  https://review.opendev.org/69853622:39
*** mithilarun has quit IRC22:50
*** mithilarun has joined #openstack-lbaas22:51
*** mithilarun has quit IRC23:00
*** mithilarun has joined #openstack-lbaas23:00
*** ivve has quit IRC23:07
*** tkajinam has joined #openstack-lbaas23:10
*** rcernin has joined #openstack-lbaas23:20
*** luksky has quit IRC23:21
« Wednesday, 2020-01-29 Index Friday, 2020-01-31 »

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