Thursday, 2020-03-05

*** yamamoto has joined #openstack-lbaas00:02
*** abaindur has quit IRC00:13
*** abaindur has joined #openstack-lbaas00:13
openstackgerritTatsuma Matsuki proposed openstack/octavia master: WIP: Failover stop threshold  https://review.opendev.org/65681100:32
*** happyhemant has quit IRC00:55
*** sapd1 has joined #openstack-lbaas01:16
*** tkajinam has quit IRC01:49
*** tkajinam has joined #openstack-lbaas01:50
openstackgerritDawson Coleman proposed openstack/octavia master: Add option for default ciphers in octavia.conf  https://review.opendev.org/71137602:15
*** psachin has joined #openstack-lbaas02:50
*** spatel has joined #openstack-lbaas03:04
*** nicolasbock has joined #openstack-lbaas03:12
*** abaindur has quit IRC03:51
*** spatel has quit IRC04:05
*** spatel has joined #openstack-lbaas04:06
*** gcheresh_ has joined #openstack-lbaas04:07
openstackgerritTatsuma Matsuki proposed openstack/octavia master: WIP: Failover stop threshold  https://review.opendev.org/65681104:16
*** nicolasbock has quit IRC04:30
*** gcheresh_ has quit IRC04:55
*** sapd1 has quit IRC05:12
*** abaindur has joined #openstack-lbaas05:22
*** spatel has quit IRC06:07
*** sapd1 has joined #openstack-lbaas06:09
*** threestrands has quit IRC06:48
*** abaindur has quit IRC06:55
*** abaindur has joined #openstack-lbaas06:55
*** ccamposr has joined #openstack-lbaas07:02
*** gcheresh has joined #openstack-lbaas07:30
*** haleyb|away has quit IRC07:39
*** gcheresh has quit IRC07:45
*** gcheresh has joined #openstack-lbaas07:46
*** happyhemant has joined #openstack-lbaas07:50
*** tesseract has joined #openstack-lbaas07:52
*** maciejjozefczyk has joined #openstack-lbaas07:59
*** tkajinam has quit IRC08:16
*** abaindur has quit IRC08:21
*** abaindur has joined #openstack-lbaas08:22
*** abaindur has quit IRC08:23
*** abaindur has joined #openstack-lbaas08:23
*** rpittau|afk is now known as rpittau08:46
*** yamamoto has quit IRC08:47
*** elenalindq has joined #openstack-lbaas08:50
*** elenalindq has quit IRC08:55
*** elenalindq has joined #openstack-lbaas08:56
*** yamamoto has joined #openstack-lbaas09:03
*** yamamoto has quit IRC09:04
*** yamamoto has joined #openstack-lbaas09:04
*** dayou has quit IRC09:07
*** andy_ has quit IRC09:08
*** dayou has joined #openstack-lbaas09:43
*** andy_ has joined #openstack-lbaas09:43
*** openstackstatus has quit IRC09:45
*** abaindur has quit IRC09:59
*** psachin has quit IRC10:23
*** spatel has joined #openstack-lbaas10:28
*** spatel has quit IRC10:33
openstackgerritAnn Taraday proposed openstack/octavia master: Add option to set default ssl ciphers in haproxy  https://review.opendev.org/68533710:56
*** maciejjozefczyk is now known as mjozefcz|lunch11:15
*** elenalindq has quit IRC11:26
*** rpittau is now known as rpittau|bbl11:27
*** elenalindq has joined #openstack-lbaas11:27
*** elenalindq has left #openstack-lbaas11:33
*** tesseract-RH has joined #openstack-lbaas11:40
*** tesseract has quit IRC11:43
*** nicolasbock has joined #openstack-lbaas11:47
*** mjozefcz|lunch is now known as maciejjozefczyk12:10
openstackgerritCarlos Goncalves proposed openstack/octavia-tempest-plugin master: WIP: fix test_amphora.py  https://review.opendev.org/71131612:19
cgoncalvesrm_work, hey. this ^ change conflicts with https://review.opendev.org/#/c/607382. I'd like to check with you what you think of ^ as it, hopefully, works on busier environments than what is considered in your patch12:22
cgoncalvesone think my patch doesn't do is limiting the results to 15 as you proposed in yours12:23
cgoncalvesFWIW, context for the proposed code: https://bugzilla.redhat.com/show_bug.cgi?id=180377912:24
openstackbugzilla.redhat.com bug 1803779 in python-octavia-tests-tempest "Random failures in test_amphora_list_and_show" [Low,Assigned] - Assigned to cgoncalves12:24
openstackgerritMaciej Józefczyk proposed openstack/octavia-tempest-plugin master: Fix scenario tests for OVN LB  https://review.opendev.org/71125512:37
rm_workcgoncalves: sure prolly fine, I'm not married to the other one :D12:52
rm_workALSO I don't run tempest locally anymore so I never run into this12:53
rm_workT_T12:53
*** yamamoto has quit IRC13:03
*** gthiemonge has quit IRC13:13
*** sapd1 has quit IRC13:17
*** takamatsu has joined #openstack-lbaas13:22
*** yamamoto has joined #openstack-lbaas13:40
*** cgoncalves has quit IRC13:41
*** sapd1 has joined #openstack-lbaas13:44
*** cgoncalves has joined #openstack-lbaas13:45
*** rpittau|bbl is now known as rpittau13:45
*** yamamoto has quit IRC13:55
*** yamamoto has joined #openstack-lbaas13:57
*** yamamoto has quit IRC14:05
*** yamamoto has joined #openstack-lbaas14:05
*** yamamoto has quit IRC14:05
*** spatel has joined #openstack-lbaas14:21
*** spatel has quit IRC14:26
*** TrevorV has joined #openstack-lbaas14:32
*** haleyb has joined #openstack-lbaas14:35
*** cgoncalves has quit IRC14:39
*** cgoncalves has joined #openstack-lbaas14:40
*** haleyb is now known as haleyb|away14:50
*** spatel has joined #openstack-lbaas14:54
*** gcheresh has quit IRC15:15
*** ramishra has quit IRC15:21
rm_workjohnsom: LOL, i hadn't even considered that people could be using the octavia client to talk with n-lbaas O_o15:22
rm_workI guess that compatibility works both ways XD15:22
rm_workwe accidentally replaced the old neutron client15:22
rm_workhilarious15:23
*** ramishra has joined #openstack-lbaas15:23
johnsomWell.... It's "octavia client" so.....15:23
rm_workyeah i mean, I don't know that we should be making changes to help it work better with n-lbaas (since it's dead), but15:24
rm_worki find it humorous that it works :D15:24
johnsomWhere did you see that? In that stats bug?15:24
rm_worknot something I'd ever thought about trying15:24
rm_workhis response15:24
rm_workhttps://review.opendev.org/#/c/711270/315:24
rm_worki guess we did too good a job with backwards compat XD15:25
rm_workthough your comment about those statistics ALSO not existing in n-lbaas still has me a little confused15:26
johnsomYeah, well, that was kind of our intent. The client however.....  I was just reading the deprecation guide:15:26
johnsomhttps://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation#What_is_the_Command_Line_Interface_.28CLI.29_for_Octavia.3F15:26
rm_workmaybe 3rd-party in n-lb returned more stats somehow?15:26
johnsomWe didn't explicitly call that out.15:26
johnsomIt would be a hack as nlbaas also used the DB stats.15:27
rm_workhmm15:27
rm_workjust funny that it works15:27
rm_workand makes sense i guess that at least a limited subset of stuff will just function properly15:27
rm_worki'm sure it's possible to construct commands that don't work because of newer features, but...15:28
johnsomRight15:28
rm_worktechnically if you're careful, you can totally make it work15:28
johnsomOur un-official (evidently) was to continue using python-neutronclient for nlbaas15:28
johnsomThat there will be *no* OSC for nlbaas15:28
johnsomI know I stated that at some summits15:29
rm_workyes that was our position15:29
rm_worksince it was deprecated there was no reason to spend more work on a new thing, let them deprecate together15:29
rm_workit's cool that this is an option though15:30
johnsomRight, that was the plan. Both deprecated together, though python-neutronclient is supposed to live longer than nlbaas15:30
rm_workyes15:30
rm_workbut our new client is much nicer as it's part of OSC :D15:30
rm_workso I can see wanting to switch15:30
johnsomI just don't want to say "yes, use it" as I bet there are other bugs there that I don't want to fix just for nlbaas15:31
johnsomIt isn't tested at all15:31
rm_workright same15:31
*** sapd1 has quit IRC15:31
*** ramishra has quit IRC15:48
*** sapd1 has joined #openstack-lbaas15:48
rm_workthis is weird: https://storyboard.openstack.org/#!/story/200737015:52
*** spatel has quit IRC15:52
rm_workper my comment, that's a stumper, unless the DB is non-atomic15:52
*** spatel has joined #openstack-lbaas15:54
rm_workjohnsom: but also, i remembered why we didn't backport, I think -- it had a depends-on for a change in octavia-lib15:55
rm_workand i don't know that we're allowed to backport there15:55
*** spatel has quit IRC15:59
*** Trevor_V has joined #openstack-lbaas16:01
*** TrevorV has quit IRC16:05
*** KeithMnemonic1 has joined #openstack-lbaas16:19
*** KeithMnemonic has quit IRC16:23
*** ramishra has joined #openstack-lbaas16:33
*** Trevor_V has quit IRC16:47
*** TrevorV has joined #openstack-lbaas16:50
*** rcernin has quit IRC16:55
*** ccamposr has quit IRC16:57
*** tesseract-RH has quit IRC17:01
*** rpittau is now known as rpittau|afk17:25
nicolasbockHi. I just realized that I can ping an amphora from a VM on the VIP network using the amphora's IP on the lb-mgmt-net.17:37
nicolasbockThis was surprising to me. But I think I kind of see now why it's possible.17:38
nicolasbockIs that not a security issue?17:38
rm_workthat ... shouldn't be possible, but would have to be due to your cloud's specific network config17:56
rm_worknormally this shouldn't be allowed17:56
rm_workfor multiple reasons17:56
rm_work(vlans at the switch level; security groups at the neutron level)17:56
rm_workbut even with connectivity to the management IP, I would not be worried, the only thing listening there is our agent HTTP server, and it does secure two-way cert auth17:57
rm_worksome people deploy with what we call "management-on-vip-net" and that is fine17:57
nicolasbockThe traffic exiting the VM hits the VM's subnet bridge17:58
nicolasbockAnd the amphora is connected to that bridge as well17:58
nicolasbockThe forwarding iptables rules allow ingress to the amphora using the 172.30... IP17:59
rm_workI would think the switch would not allow that traffic to cross subnets, to me that still sounds like a vlan isolation issue17:59
nicolasbockI might be misunderstanding the flow though :)17:59
nicolasbockI agree, I wouldn't have expected this to be possible18:00
rm_workjohnsom is the one who actually knows how networks work tho, so will wait for him to respond, i say words and sometimes they mean things and sometimes they are random collections of network-jargon :D18:00
nicolasbock:) Sounds like me then ;)18:00
johnsomSorry, '18:01
johnsomI have been in video calls all morning18:01
johnsomreading scroll back18:02
nicolasbockThanks johnsom !18:02
*** gyee has joined #openstack-lbaas18:02
johnsomSo you can ping from the lb-mgmt-net to the amphora VIP? Is that the scenario?18:03
nicolasbockI have a tenant network, a VM on that network, and a loadbalancer with VIP on tenant network18:04
nicolasbockI can ping VM -> amphora using the amphora's lb-mgmt-net IP18:04
johnsomSo you are spoofing the source IP for the ping?18:05
nicolasbockNo18:05
nicolasbockping 172.30.1.1818:05
johnsomOk, so tenant network to lb-mgmt-net IP18:05
nicolasbockWhere my IP is 192.168.1.1818:06
nicolasbockYes18:06
nicolasbockBut the amphora's interface is connected to the tenant network's bridge on the compute host18:06
johnsomYeah, so dictated by how the cloud was deployed. Typically the lb-mgmt-net is a private network with no gateway address, so not routable.18:07
nicolasbockTo make sure I understand, the network's "shared" attribute should be False18:08
nicolasbockAnd the gateway of the subnet should not be set18:08
johnsomThe default security group for the amphora interface on the lb-mgmt-net does allow ICMP ping, SSH, and port 9443.  All of which are "fine" to be public, but typical cloud deployments don't have routes to the lb-mgmt-net from other networks.18:08
nicolasbockDid I understand that correctly?18:08
johnsomThose settings are up to you and your cloud.18:09
nicolasbock:)18:09
johnsomTypically, it would not be shared and would not have a gateway/route18:09
nicolasbockI meant in reference to your statement regarding how one typically deploys such a network18:09
johnsomBut you can..... lol18:09
nicolasbockOk thanks18:09
nicolasbock:)18:09
nicolasbockI have set a gateway IP on the management network18:10
johnsomThere have been some large clouds that have "public" shared networks that they also use for the lb-mgmt-net. It is fine.18:10
nicolasbockOk18:10
nicolasbockThanks for the infor!18:10
johnsomAs rm_work mentioned. The Amphora API is two-way TLS authenticated, so it is a "secure" port.18:10
nicolasbockRight. Maybe I am overly paranoid, but to me this looked like security issue18:11
rm_workyeah, there's no NEED for it to be routed, so you could lock that down18:11
nicolasbockBut then again, I shouldn't have set the gateway on the management network :)18:11
johnsomIf you disable that gateway, note that you will have to be in a neutron namespace or on the network to ssh into the amphora, but typically you don't need to. Many disable ssh access to the amphora18:11
nicolasbockHow would I allow the service processes access then though?18:12
nicolasbockStart them in the netns?18:12
rm_workthe service hosts should be attached to the management network18:12
johnsomWell, that again comes down to how the cloud is deployed. Many have the control plane processes on the lb-mgmt-net directly. If you are using the routed option, then yes, you need to have a gateway18:13
rm_workor that, yes (in the case of like, devstack)18:13
nicolasbockWe currently have the lb-mgmt-net implemented as a provider network on top of physnet118:13
nicolasbockSitting on a separate VLAN ID18:13
johnsomYou can also add security groups to the router port, or use FWaaS to put rules on who can access the lb-mgmt-net.18:14
johnsomMany options really18:14
nicolasbockTrue, it's like shopping the cereal aisle ;)18:14
nicolasbockSo you are not concerned in terms of security that the amphorae are accessible in that way?18:15
johnsomI am not, no.18:16
nicolasbockNo18:16
nicolasbockOk18:16
nicolasbockOk I meant18:16
johnsomTypically, end users won't even know they are there as the amphora details have RBAC rules limiting the visibility to admins only18:16
nicolasbockOk18:16
nicolasbockLike I say, this is potentially an overly paranoid position18:17
nicolasbockBut you could run a port scan from the VM :)18:17
johnsomIf you don't have a controller certificate and key, you can't do anything with the amphora API other than get the version information.18:17
johnsomYes, you could18:17
nicolasbockOk, I'll check with my team to see how paranoid we should be18:18
nicolasbockThanks again for the info!18:18
johnsom"Only the paranoid survive" as the late Andy Grove said....  Feel free to put additional controls in place.18:18
nicolasbockThanks!18:18
rm_workit's not paranoia if they're really out to get you18:18
rm_workso I'm not really sure if it's *possible* to truly be paranoid when you work in tech, just realistic18:19
nicolasbock:)18:22
nicolasbockParanoia and realism is a sliding scale. It all depends :)18:23
johnsomrm_work you have been tagged in an e-mail chain from Monty19:41
johnsomFunny really19:42
rm_worklol19:42
johnsomhttps://review.opendev.org/#/q/owner:self+project:openstack/openstacksdk19:42
johnsomhttps://review.opendev.org/#/q/owner:flux+project:openstack/openstacksdk19:42
rm_workthanks for the heads up, i never read email19:42
johnsomGuess I'm on mordred bad side, lol19:43
rm_worklol19:43
rm_workI can tell him I'm delegating :D19:43
johnsomNope, I think you are *it*19:44
rm_workI think it's just cause we were literally just talking like yesterday about this and i rebased some patches for them, lol19:44
rm_workso fresh in mind19:44
rm_workobviously you're the better candidate for SDK work :D19:44
rm_workthe PTL thread is fun too :D19:50
*** maciejjozefczyk has quit IRC19:53
johnsomYeah, PTL, OSC, throw it all away for k8s. All fun things recently in the world of OpenStack19:57
*** gcheresh has joined #openstack-lbaas19:58
johnsomrm_work This is back too: https://storyboard.openstack.org/#!/story/200737020:04
johnsomOh, you saw it already and my e-mail page had not updated. nevermind20:05
johnsomAs for the backport on that. It's implemented as a breaking change, but if it was *always* broken it probably should be backported.20:08
*** vishalmanchanda has quit IRC20:31
*** abaindur has joined #openstack-lbaas20:32
*** trident has quit IRC20:37
*** TrevorV has quit IRC20:44
*** trident has joined #openstack-lbaas20:47
*** rcernin has joined #openstack-lbaas20:53
*** cgoncalves has quit IRC20:53
*** gcheresh has quit IRC20:55
*** cgoncalves has joined #openstack-lbaas20:56
*** nicolasbock has quit IRC21:05
*** cgoncalves has quit IRC21:10
*** cgoncalves has joined #openstack-lbaas21:11
*** rcernin has quit IRC21:18
*** gcheresh has joined #openstack-lbaas21:38
*** gcheresh has quit IRC22:09
*** abaindur has quit IRC22:14
*** abaindur has joined #openstack-lbaas22:15
*** tkajinam has joined #openstack-lbaas22:45
*** spatel has joined #openstack-lbaas23:30
*** vishalmanchanda has joined #openstack-lbaas23:34
*** spatel has quit IRC23:35

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