20:00:02 #startmeeting Octavia 20:00:04 Meeting started Wed Oct 3 20:00:02 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:07 The meeting name has been set to 'octavia' 20:00:25 Well, we can work around it. It's just annoying. 20:00:27 o/ 20:00:31 Hi folks 20:00:32 yep 20:00:45 hi 20:01:04 #topic Announcements 20:01:11 We have new TC members 20:01:16 #link https://governance.openstack.org/election/results/stein/tc.html 20:01:26 yep, evrajdip made it ;-) 20:01:53 These are year terms, so only half of the TC is new. 20:01:57 o/ 20:02:03 Also in good news: 20:02:07 (Sorry to be late, connection problems) 20:02:12 Octavia has completed the Python 3 by default community goal! 20:02:21 #link https://storyboard.openstack.org/#!/board/104 20:02:22 yeah!! 20:02:41 We are the first service project to finish. 20:02:59 * xgerman_ victory lap 20:03:33 Thank you to everyone that reviewed the patches, did py3 work, etc. 20:03:43 Any other announcements today? 20:04:02 oh, that would be me 20:04:31 I have to focus more on our k8s business and so have to reduce my OpenStack inbolvement 20:04:47 * johnsom is sad 20:04:49 :'( 20:04:52 noooo! 20:05:12 :-( 20:05:16 thanks for all the work recently seen you submitting a lot i feel like 20:05:39 I managed to avoid a hard break but will be here a bit less in the future 20:05:40 xgerman_ was part of the founding team for the project. 20:06:38 yeah, techncially only johnsom is left 100% on the project 20:06:48 So I understand you will still be around and may do some reviews every once in a while. 20:07:06 Well, I think 100% might be a bit generous, but it is a core part of my job. 20:07:07 yeah, I hope to spend a couple of hours a week here 20:07:15 xgerman_, thank YOU! we all hope to see you still around and contribute with your ideas 20:07:31 Ok, we appreciate it and of course all that you have contributed over the years. 20:07:32 yeah, for sure :-) 20:08:17 Any other announcements today? 20:08:41 #topic Brief progress reports / bugs needing review 20:08:41 Please announce only if you have good news.. 20:08:50 ^^ yeah, that too 20:09:41 I have been beating my head against the zuul/ansible/devstack wall with a few gate jobs. Sorry for the noise while I fight with those. 20:10:22 I have a patch up for diskimage-builder that fixes building ubuntu-minimal images on bionic nodepool instances. 20:10:41 A change in APT in bionic causes trouble 20:12:04 Other than that I have been working on the IPv6 VIP issue. I have a solution to the DAD failure, but ran into a keepalived segfault issue, which I just identified today. (nice to run gdb again...) 20:12:14 So some progress on that front as well. 20:14:09 do you know if the keepalived patch is backportable? 20:15:03 * nmagnezi reconnected again O_O 20:15:29 That I do not know. I saw that it is only in 1.3.0 and newer, but I don't know why it's not in older versions. 20:15:48 We would have to convince the distros to backport it. 20:16:12 I think my workaround can be (needs to be tried) on our side, but it will require a new image be built. 20:16:24 "Don't segfault if unable to load ip_vs module" 20:16:30 this one? 20:16:49 #link https://github.com/acassen/keepalived/issues/457 20:16:57 #link https://github.com/acassen/keepalived/commit/d52fa0068affc3c6176ba5b5256904d6979fd308 20:17:04 "Don't segfault if modules ip_tables or ip6_tables not loaded" 20:17:26 just load the module? 20:17:40 Oh, I did get the octavia-lib repo created too. Just haven't started preparing it yet. 20:17:56 Yeah, I think that will be the workaround. I haven't tested that yet though 20:19:10 centos7 has keepalived 1.3.5 which should include that patch 20:19:37 Moving forward, I plan to finish up the IPv6 fix, finish the HM backport to queens, and start work on the octavia-lib repo 20:19:48 also this one: https://git.centos.org/raw/rpms/keepalived.git/00db1460fb2e62a5a8cda42012ee6f19a36d7947/SOURCES!bz1508435-no-segfault-ip_vs-load.patch 20:19:58 cgoncalves Ah, nice. Win for centos 7.... 20:20:37 a first… 20:21:06 Bionic has 1.3.9 and should also be fixed. 20:21:43 Any other progress reports? 20:22:18 https://review.openstack.org/#/c/604226/ is ready as well 20:22:45 nmagnezi BTW, I do plan to grab https://review.openstack.org/#/c/589292/ as the base for the IPv6 fix. If that is still ok with you. 20:22:48 Merged openstack/python-octaviaclient master: Use templates for cover and lower-constraints https://review.openstack.org/604549 20:23:09 johnsom, yup, np. 20:23:21 the zombie hunter patch is ready and received approval, although it is failing on functional. it passes locally. thoughts? 20:23:22 also I am trying to refactor the AAP driver: https://review.openstack.org/#/c/604479/ — hope to finish/babysit that as well 20:23:24 https://review.openstack.org/#/c/587505/ 20:23:40 yeah, not sure… keep rebasing until it works? 20:23:47 I also added the API version to the api-ref here: https://review.openstack.org/604911 20:23:49 #link https://review.openstack.org/604911 20:24:13 xgerman_, looks like a related test is failing http://logs.openstack.org/05/587505/22/check/openstack-tox-py27/18ad0e2/testr_results.html.gz 20:24:32 mmh… 20:24:47 Hmm, yep 20:25:03 yeah, cgoncalves one of us needs to debug then 20:25:27 heads (doing the coin flip for you) 20:25:37 lol 20:25:44 lol 20:25:58 ok, if no one has ideas I'll keep looking 20:26:20 Or use https://justflipacoin.com/ 20:26:21 :D 20:26:41 k - heads was cgoncalves 20:26:45 You can't say the PTL is good for nothing.... 20:27:17 I will take a quick look to. Could be the test is reaching out to the host or being impacted by ordering. 20:28:07 Any other updates? 20:28:39 #topic Talk about VIP security groups 20:28:51 Last week we came down to two options: 20:28:57 1. Add ACL to the Octavia API to allow source IP restrictions 20:29:04 2. Move the VIP base port security group ownership to the tenant 20:29:13 Anymore thoughts or comments on this topic? 20:30:19 One person at a time please..... grin 20:30:23 I'm in favor of option 1, but I understand folks needing option 2 (+ configurable in .conf) 20:30:32 same 20:31:15 we can do both, can’t we? 20:31:16 Yeah, I lean towards 1 as well giving the pain I have seen from having the VIP even visible in the tenant. 20:31:33 if option 2, I'd argue to have SG owned by Octavia as default and a config opt to allow specific tenants to have SG owned by them 20:31:57 Or maybe a flavor option.... 20:31:58 well, we could maybe get that with policy 20:32:01 we are integrating tightly with magnum here and the idea of being able to transact with the api for security group needs on VIPs is attractive, fwiw 20:32:06 plus while introduce that config opt, deprecated it at the same time as we don't want to carry it for that long 20:32:56 *deprecate 20:32:59 colin-: magnum is free to run as the same tenant as octavia or have admin rights there 20:33:22 in some of my installs I use the service tenant for ovtavia… 20:34:42 Ok, so what I am hearing is the following: 20:34:59 We would like to implement option 1. 20:35:36 ltomasbo, this discussion could be of interest to your team... 20:35:37 We would like to make available, via config and/or flavor that the VIP base port (vrrp port) be owned by the tenant. 20:35:52 Is that correct? 20:35:59 If so I will update the story 20:36:49 config so that it could be potentially backportable (reason: security hardening) 20:37:31 #link https://review.openstack.org/#/c/602564/ 20:37:49 Yeah, I am fine with a config up front, then moving it to a flavor later. 20:37:57 #link https://storyboard.openstack.org/#!/story/2003686 20:38:08 I think ltomasbo would be able to continue ^ and add the config opt 20:38:38 johnsom, why flavor? why not add ACL (option 1)? 20:38:57 we can do both 20:39:16 ok 20:39:23 Right, I was expecting both. flavor gives the operator more flexibility over an all-or-none config setting 20:40:21 Ok, I will write it up on the story. 20:41:06 #topic Open Discussion 20:41:13 Any other topics for today? 20:41:47 do you think it could make to be backported to stable releases? 20:42:01 *made 20:42:18 Not likely given it would be a new config setting or API change 20:42:43 +1 20:42:57 we can’t just play fast and loose with API/Config changes 20:43:59 I was asking specifically of option 2 with new config. potential reason for backport would be security hardening. we've recently backported a patch to stable releases that added a new config with a good default 20:44:17 * johnsom thinks the stable maintenance role is going to cgoncalves head... backport it all! grin 20:44:29 I understand if it cannot. I just wanted to clarify so that everyone is aware and understands 20:44:37 Yeah, and they kind of didn't like it 20:44:52 I remember that ;-) 20:45:57 I think if someone can make a strong case for it being needed for security reasons, we could try it. But I would want that really called out in the story as the driver for the change. 20:47:24 Any other topics today? 20:47:58 where is rm_Work? 20:48:15 somewhere 20:48:19 lol 20:48:54 awesome job on the python3 stuff 20:49:21 Yeah, happy to have that done and that we are on top of being able to run on python3 20:50:00 Ok, well, if there aren't other topics today, have a great week folks! I'm back to playing with keepalived 20:50:12 #endmeeting