| *** SumitNaiksatam has quit IRC | 00:01 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 00:02 | |
| *** SumitNaiksatam has quit IRC | 00:07 | |
| abaindur | johnsom: Is there a way to test https TLS load balancer with the local_cert_manager? | 00:20 |
|---|---|---|
| abaindur | We just want to validate https it works and try some l7 policies | 00:20 |
| abaindur | Don't have Barbican setup | 00:20 |
| *** longkb has joined #openstack-lbaas | 00:36 | |
| *** hongbin has joined #openstack-lbaas | 01:04 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 01:20 | |
| *** abaindur has quit IRC | 01:21 | |
| *** ianychoi has joined #openstack-lbaas | 01:47 | |
| *** HW_Peter has quit IRC | 02:36 | |
| *** gans has joined #openstack-lbaas | 03:06 | |
| *** sapd1 has quit IRC | 03:09 | |
| johnsom | abaindur I think you just drop your certs in whatever directory is defined by CONF.certificates.storage_path and name the file whatever you use for the reference ID. | 03:13 |
| johnsom | https://github.com/openstack/octavia/blob/master/octavia/certificates/manager/local.py#L97-L102 | 03:13 |
| johnsom | By certs, I mean the one cert that driver can handle | 03:13 |
| johnsom | for testing | 03:13 |
| *** gans has quit IRC | 03:14 | |
| johnsom | Cores, this needs one more vote to fix the gates/bandit check: https://review.openstack.org/#/c/592756/ | 03:19 |
| *** abaindur has joined #openstack-lbaas | 03:33 | |
| *** abaindur has quit IRC | 03:33 | |
| *** abaindur has joined #openstack-lbaas | 03:33 | |
| *** abaindur has quit IRC | 03:33 | |
| *** abaindur has joined #openstack-lbaas | 03:34 | |
| *** abaindur has quit IRC | 03:34 | |
| *** abaindur has joined #openstack-lbaas | 03:35 | |
| *** SumitNaiksatam has quit IRC | 03:50 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 03:51 | |
| *** hongbin has quit IRC | 03:57 | |
| *** blake has joined #openstack-lbaas | 03:59 | |
| *** blake has quit IRC | 04:10 | |
| rm_work | nmagnezi: need a +A on https://review.openstack.org/#/c/592756/1 after it passes the recheck | 04:24 |
| rm_work | if you're around | 04:24 |
| *** ramishra has joined #openstack-lbaas | 04:32 | |
| *** SumitNaiksatam has quit IRC | 04:48 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 04:54 | |
| openstackgerrit | James Page proposed openstack/octavia master: Fix compat with Python >= 3.6 https://review.openstack.org/592829 | 05:33 |
| *** sapd1 has joined #openstack-lbaas | 05:44 | |
| *** velizarx has joined #openstack-lbaas | 06:53 | |
| *** pcaruana has joined #openstack-lbaas | 06:54 | |
| *** rcernin has quit IRC | 06:55 | |
| *** abaindur has quit IRC | 06:58 | |
| *** abaindur has joined #openstack-lbaas | 06:59 | |
| *** longkb has quit IRC | 07:03 | |
| *** longkb has joined #openstack-lbaas | 07:03 | |
| *** velizarx has quit IRC | 07:24 | |
| *** velizarx has joined #openstack-lbaas | 07:43 | |
| devfaz | Hi, is anybody using amphora with xenial? Currently trying to run octavia-tempest-tests against latest-amphora (xenial) and it looks like there is a problem with new net-device-naming schema. Amphora is returning an 500, because dad is running into an timeout. Took a look and dad is trying to up eth1, but there is just an ensX-device?! | 07:51 |
| *** longkb has quit IRC | 08:02 | |
| *** longkb has joined #openstack-lbaas | 08:02 | |
| *** ktibi has joined #openstack-lbaas | 08:04 | |
| *** luksky has joined #openstack-lbaas | 08:23 | |
| *** abaindur has quit IRC | 08:53 | |
| *** abaindur has joined #openstack-lbaas | 08:55 | |
| *** salmankhan has joined #openstack-lbaas | 09:37 | |
| cgoncalves | CPU load average: 794.80, 467.48, 491.34 | 09:55 |
| cgoncalves | yay health manager! https://storyboard.openstack.org/#!/story/2003479 | 09:55 |
| *** dayou has joined #openstack-lbaas | 09:56 | |
| *** sapd1 has quit IRC | 10:09 | |
| devfaz | just created a story, because adding netdev/biosdevname option to kernel fixed my issue: https://storyboard.openstack.org/#!/story/2003481 | 10:20 |
| cgoncalves | devfaz, CI jobs build and test xenial amphorae. do you know how come you're seeing that issue whereas CI is not? | 10:27 |
| devfaz | sorry, no idea. Just a stupid shell-script running the diskimage-create.sh after cloning the other repos. Do you have some info/link to the ci job - maybe I can look for the difference. | 10:29 |
| devfaz | cgoncalves: found it - will take a look | 10:40 |
| cgoncalves | devfaz, https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L186 | 10:42 |
| devfaz | cgoncalves, right - im also just running this script. Im currently trying to find out if the created amphora is also using ensX-devices or if our cloud/kvm settings may trigger this. | 10:43 |
| *** ramishra has quit IRC | 11:04 | |
| cgoncalves | devfaz, ok. let us know what you find :) | 11:07 |
| *** longkb has quit IRC | 11:07 | |
| devfaz | cgoncalves, currently I verified: yes, the job is using the created image :) | 11:07 |
| devfaz | cgoncalves, is there a way to download the image to test the binary-version directly? | 11:08 |
| *** ramishra has joined #openstack-lbaas | 11:23 | |
| cgoncalves | devfaz, what do you mean by binary-version? | 11:27 |
| devfaz | cgoncalves, the qcow2-file | 11:27 |
| devfaz | fyi: just running devstack in the hope it creates an amphora-image automatically :) | 11:28 |
| devfaz | just found the CI-Jobs are running on bionic and im using xenial on the host, too. But I would assume the tests exist longer than bionic and also were executed on xenial in the past, too? | 11:29 |
| devfaz | 1. im trying to get the image out of devstack | 11:30 |
| cgoncalves | by default all CI jobs use xenial. there's an extra job that uses bionic | 11:30 |
| devfaz | 2. im trying to update qemu/libvirt to bionic | 11:30 |
| devfaz | arg.. | 11:30 |
| devfaz | ok, so 2. is obsolete :) | 11:30 |
| cgoncalves | so, let's recap :) | 11:31 |
| cgoncalves | you can either invoke diskimage-create.sh script from octavia repo directly and specificy which distro/version you want and get the qcow | 11:31 |
| cgoncalves | or run devstack with defaults and that will build a ubuntu-minimal xenial amphora | 11:31 |
| cgoncalves | you can get the qcow. it will be in /opt/stack/octavia/diskimage-create if I'm not mistaken | 11:32 |
| cgoncalves | you can also change the default distro/version devstack builds with some flags in local.conf | 11:32 |
| cgoncalves | for example | 11:33 |
| cgoncalves | OCTAVIA_AMP_BASE_OS=centos | 11:33 |
| cgoncalves | OCTAVIA_AMP_DISTRIBUTION_RELEASE_ID=7 | 11:33 |
| cgoncalves | OCTAVIA_AMP_IMAGE_SIZE=3 | 11:33 |
| cgoncalves | would create a centos 7 amphora with a disk size of 3GB | 11:33 |
| cgoncalves | devfaz, probably you would like to get the periodically built xenial image :) | 11:34 |
| cgoncalves | https://tarballs.openstack.org/octavia/test-images/ | 11:34 |
| devfaz | cgoncalves, great! I will give it a try | 11:35 |
| devfaz | cgoncalves, just booted the image and got an ens3 device. I will start the tempest-test, but I would suggest they will fail again | 11:48 |
| cgoncalves | devfaz, very likely to fail, yes | 11:48 |
| devfaz | cgoncalves, is there a way to get the console-out of an amphora used during the ci-jobs? | 11:57 |
| cgoncalves | devfaz, openstack console log show <amphora vm id> | 11:57 |
| devfaz | cgoncalves, I know - but I dont have the credentials for the public openstack-ci-cloud ;) | 11:58 |
| cgoncalves | ah, sorry, ci jobs, missed that part | 11:58 |
| cgoncalves | well, no | 11:58 |
| devfaz | cgoncalves, nevertheless.. if octavia needs ethX-naming-scheme, this should be actively requested, isnt it? | 12:01 |
| cgoncalves | devfaz, hmmm I would say yes if we can reproduce your issue | 12:02 |
| cgoncalves | I think it is a valid one, anyway, regardless if we can reproduce or not | 12:02 |
| devfaz | ok, I assume you dont have an ubuntu-hv near you ;) | 12:02 |
| cgoncalves | centos only :) | 12:02 |
| devfaz | ;) | 12:03 |
| cgoncalves | https://docs.openstack.org/diskimage-builder/latest/elements/stable-interface-names/ | 12:03 |
| cgoncalves | hmmmm | 12:03 |
| devfaz | well, but way is ci not affected? | 12:06 |
| cgoncalves | devfaz, try appending "stable-interface-names" to AMP_element_sequence in octavia/diskimage-create/diskimage-create.sh and build new image | 12:08 |
| devfaz | cgoncalves, I think "stable-interface-names" is trying to enable the "stable" (aka. Predictable Network Interface Names) but I will give it a try | 12:09 |
| devfaz | https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 12:10 |
| cgoncalves | oh | 12:12 |
| devfaz | cgoncalves, ok - looks like biosdevnames is something similar to systemds way to reach the same goal | 12:13 |
| devfaz | http://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf | 12:13 |
| devfaz | status update: amphora is building; "old" test-image-amphora is - as assumed - failing in tempest | 12:18 |
| cgoncalves | johnsom may know this interface naming better as he uses ubuntu amps :) | 12:19 |
| *** velizarx has quit IRC | 12:31 | |
| *** velizarx has joined #openstack-lbaas | 12:41 | |
| devfaz | cgoncalves: just fyi - enabling stable-interface-names changed nothing. | 13:11 |
| devfaz | still ens3 | 13:11 |
| *** ramishra has quit IRC | 13:33 | |
| johnsom | devfaz: yeah, we use xenial. I just opened a bug about this, it is a bug when using IPv6 vip on active/standby lbs. It is not related to interface naming (the amp agent handles that for us by using mac addresses). | 13:41 |
| devfaz | johnsom, great thx! | 13:42 |
| johnsom | cgoncalves: do you need that neutron sync junk enabled? | 13:46 |
| cgoncalves | johnsom, what? where? | 13:57 |
| *** ramishra has joined #openstack-lbaas | 14:00 | |
| johnsom | cgoncalves: you HM /Rabbit issue | 14:24 |
| cgoncalves | oh, sh*t! it is enabled indeed... | 14:28 |
| cgoncalves | http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/puppet/services/octavia-health-manager.yaml#n74 | 14:29 |
| cgoncalves | bah! | 14:29 |
| *** velizarx has quit IRC | 14:47 | |
| *** SumitNaiksatam has quit IRC | 14:51 | |
| *** rpittau has quit IRC | 14:54 | |
| johnsom | Yeah, double check the provisioning sync isn't on either | 14:55 |
| cgoncalves | it's good there | 14:56 |
| cgoncalves | ./octavia.conf:# sync_provisioning_status = False | 14:56 |
| johnsom | ok | 14:56 |
| devfaz | johnsom: I will keep my workaround (old nic-naming-schema) active, because it will fix my tempest-tests. Do you see any furhter/other troubles I may introduce with it? | 14:56 |
| johnsom | devfaz The issue with the v6 tests on active/standby shouldn't be a interface naming issue, at least not how I saw it yesterday when I opened the bug. It's an issue in how we are plugging the ports and bringing up the interfaces. Do you have more information? | 14:58 |
| devfaz | johnsom, well with the old-interface-naming the tests pass and the "err"-msg changed into something like "oh, eth1 is already configured..." | 14:59 |
| johnsom | Hmm, what was your fix again? | 15:00 |
| devfaz | I think I have to do some further testing. Is there a way to introduce some active/passive-gate-testing to avoid such issues in future? | 15:00 |
| devfaz | export DIB_BOOTLOADER_DEFAULT_CMDLINE="net.ifnames=0 biosdevname=0 nofb nomodeset vga=normal" | 15:01 |
| devfaz | johnsom, | 15:01 |
| johnsom | Yes, the hold up has been the gate hosts can't handle that many VMs in the test runs. They don't have enough memory. But now the multi-node stuff for zuulv3 is fixed, we should be able to get some gates in. | 15:01 |
| johnsom | Hmmm, if I remember the code right, when the amphora agent moves the interfaces into the network namespace, it finds the right interface by MAC address and renames them to eth1, eth2, etc. | 15:03 |
| *** fnaval has joined #openstack-lbaas | 15:22 | |
| *** strigazi has quit IRC | 16:05 | |
| *** strigazi has joined #openstack-lbaas | 16:06 | |
| *** strigazi has quit IRC | 16:06 | |
| *** luksky has quit IRC | 16:06 | |
| *** strigazi has joined #openstack-lbaas | 16:07 | |
| *** ktibi has quit IRC | 16:07 | |
| *** salmankhan has quit IRC | 16:12 | |
| *** salmankhan has joined #openstack-lbaas | 16:13 | |
| *** strigazi has quit IRC | 16:13 | |
| *** strigazi has joined #openstack-lbaas | 16:14 | |
| *** ramishra has quit IRC | 16:19 | |
| openstackgerrit | Merged openstack/octavia master: "Resolve" bandit issue with sha1 hashes https://review.openstack.org/592756 | 16:26 |
| *** salmankhan has quit IRC | 16:32 | |
| *** salmankhan has joined #openstack-lbaas | 16:34 | |
| openstackgerrit | Merged openstack/octavia master: Allow blocking IPs from member addresses https://review.openstack.org/591893 | 16:39 |
| *** SumitNaiksatam has joined #openstack-lbaas | 16:47 | |
| *** hvhaugwitz has quit IRC | 16:49 | |
| *** hvhaugwitz has joined #openstack-lbaas | 16:50 | |
| *** salmankhan1 has joined #openstack-lbaas | 16:55 | |
| *** salmankhan has quit IRC | 16:55 | |
| *** salmankhan1 is now known as salmankhan | 16:55 | |
| *** salmankhan has quit IRC | 17:22 | |
| *** luksky has joined #openstack-lbaas | 17:26 | |
| *** amuller has joined #openstack-lbaas | 17:27 | |
| *** amuller has quit IRC | 17:29 | |
| openstackgerrit | Akihiro Motoki proposed openstack/octavia-dashboard master: Drop nose dependencies https://review.openstack.org/593145 | 19:10 |
| openstackgerrit | Akihiro Motoki proposed openstack/neutron-lbaas-dashboard master: Drop nose dependencies https://review.openstack.org/593147 | 19:21 |
| abaindur | johnsom: to clarify, when we create a pool member, we do not need to specify the subnet correct? If we want the amphora VM to have direct L2 connectivity to that subnet/backend pool members, we can specify the subnet | 20:32 |
| abaindur | but if we do not, we can give any arbitrary IP (assuming it is routable), such as the floating IP of the backend pool members | 20:32 |
| abaindur | instead of its fixed IP and directly attaching the subnet to amphora | 20:32 |
| johnsom | abaindur, If you do not specify the subnet for members, it will go out the VIP subnet. | 20:32 |
| abaindur | interesting. So theoretically we can have a loadbalancer for VMs that are not even part of our Openstack cloud | 20:33 |
| johnsom | Similar, as long as a member has a route out the subnet you specify, it doesn't actually have to live on the subnet you specify | 20:33 |
| abaindur | since our VIP subnet must be reachable by the worker processing running on the host, this implies its a provider network and already has external access | 20:34 |
| johnsom | Correct, you could put www.openstack.org in and we will load balance it as long as the member network has a route there | 20:34 |
| johnsom | You are using the same subnet for lb-mgmt-net and the VIPs? | 20:34 |
| abaindur | yea, our VIP subnet is a provider network routed by physical router w/ external access and to other data centers | 20:34 |
| abaindur | yes, same subnet ID we specify when creating the loadbalancer | 20:35 |
| johnsom | Octavia worker does not need access to the VIP network, normally. | 20:35 |
| johnsom | Ok | 20:35 |
| abaindur | oh so we can specify a 3rd subnet for the VIP too? | 20:36 |
| abaindur | ok, i was assuming it was on the lb mgmt net | 20:36 |
| johnsom | No, VIP does not live on lb-mgmt-net unless you tell it to. There are the following: | 20:36 |
| johnsom | 1. lb-mgmt-net: Just for controller processes and amphora-agent. Network namespace isolated from the VIP and member networks. Typically a private neutron network. Does not need external/internet access. | 20:37 |
| johnsom | 2. VIP network: User specifies this at load balancer creation time. Used for tenant traffic and IP the user connects to the LB on. If the users does not specify a subnet for a member, it is also the member network (This is a one-armed load balancer). | 20:38 |
| johnsom | 3. Member network(s): One or more networks the user specifies at member creation time. If none specified, the VIP network is used, otherwise if the network is not already attached to the amphora, we hot plug that network into the isolated network namespace for the tenant traffic. | 20:39 |
| abaindur | but lb-mgmt-net needs external access right? How else will our octavia-worker process, which runs directly on the host - not a VM - communicate with it? Here the worker is talking out the host's networking, not via OVS or any neutron network | 20:40 |
| johnsom | lb-mgmt-net does not need external access. | 20:40 |
| johnsom | Just the controller processes and the amphora-agents talk on that network. You can make it external if you want, but that is up to how you deploy your Octavia. | 20:41 |
| abaindur | so if our lg-mbmt-net is an isolated tenant network, 192.168.1.0/24, How does the controller process on host talk to it? | 20:42 |
| abaindur | the controller's traffic would leave directly from the host - no OVS | 20:42 |
| abaindur | hence we had to tag that subnet 192.168.1.0/24 and its vlan in our physical router | 20:43 |
| johnsom | Well, you can add a port on the host that connects to OVS like we do in devstack, you can add the host to a neutron vxlan, you can use private provider nets, etc. Many different ways to do it. | 20:44 |
| *** KeithMnemonic has quit IRC | 21:11 | |
| *** fnaval has quit IRC | 22:40 | |
| *** SumitNaiksatam has quit IRC | 22:46 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 22:47 | |
| *** SumitNaiksatam has quit IRC | 23:21 | |
| *** SumitNaiksatam has joined #openstack-lbaas | 23:22 | |
| *** luksky has quit IRC | 23:25 | |
| *** SumitNaiksatam has quit IRC | 23:30 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!