| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 00:23 |
|---|---|---|
| *** tongl has quit IRC | 00:27 | |
| *** openstackgerrit has quit IRC | 00:33 | |
| *** openstackgerrit has joined #openstack-lbaas | 00:38 | |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Improve Neutron driver _get_resource() https://review.openstack.org/527199 | 00:38 |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 00:42 |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 00:47 |
| johnsom | Ummm, what is going on there? | 00:47 |
| dayou | Adam's patch just merged, caused a few merge conflicts | 00:58 |
| dayou | https://review.openstack.org/#/c/525790/ | 00:58 |
| johnsom | Typically that can be resolved in one rebase/merge patch.... | 00:59 |
| *** Swami has quit IRC | 01:01 | |
| johnsom | Are we sure that TaskUtils can be run as a property that way? | 01:01 |
| dayou | I am not sure, but it wouldn't cause any harm | 01:01 |
| dayou | We can do the other way also | 01:02 |
| johnsom | It moves the instantiation from startup to runtime right? | 01:03 |
| dayou | What's the difference between startup and runtime for this specific use case? | 01:04 |
| johnsom | We did that on the network driver since it connects to an outside service, which if it fails we want the flow to fail and revert. task_utils are special database methods that do not raise exceptions so that it does not cause a revert. | 01:05 |
| johnsom | rm_work Do you have an opinion? https://review.openstack.org/#/c/458308/60..63/octavia/controller/worker/tasks/network_tasks.py | 01:06 |
| dayou | It is connected to the db service, right? | 01:07 |
| dayou | Mariadb and Neutron should be considered the same as outside service | 01:08 |
| johnsom | My point is more about task_utils should never fail in the eyes of Octavia. We moved the network driver to a property so it will cause failures if neutron goes down. | 01:09 |
| dayou | What if there is a temporary database failure, some spikes caused by mariadb cluster | 01:11 |
| johnsom | task utils methods must silently fail. If they were to raise it could abort the revert flow and leave a LB in a poor state like PENDING | 01:12 |
| johnsom | Basically we are trading off and saying, if that DB update fails, it's ok, continue your cleanup | 01:12 |
| johnsom | So, going up the init stack, I don't see anything that will break with this. It's just odd | 01:15 |
| dayou | Got you | 01:15 |
| dayou | I am trying to learn the art of argument | 01:16 |
| dayou | :-D | 01:16 |
| johnsom | Ha | 01:16 |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Extend api to accept qos_policy_id https://review.openstack.org/458308 | 01:17 |
| johnsom | It's the end of a long day for me, so not the best adversary tonight. | 01:17 |
| dayou | Get some good rest, you should get refreshed tomorrow | 01:18 |
| dayou | I go out and do some morning exercise | 01:21 |
| johnsom | Enjoyh | 01:21 |
| bzhao | Oh, I think I miss something. Sorry for late. Just back. T_T | 01:40 |
| johnsom | bzhao FYI, I am working on an edit of the UDP spec. Will post here in a bit | 01:44 |
| bzhao | johnsom, Thanks, just do it. :). I will follow it and change the exist patch. | 01:48 |
| johnsom | Mostly formatting, but I think the session persistence needs to change | 01:48 |
| *** tongl has joined #openstack-lbaas | 01:50 | |
| bzhao | johnsom, sorry for that, my bad english. And thanks for your kind help. OK, nevermind , I coding from backend to front. The change must be small, I think. :) | 01:51 |
| *** tongl has quit IRC | 01:56 | |
| *** annp has joined #openstack-lbaas | 02:07 | |
| openstackgerrit | Michael Johnson proposed openstack/octavia master: Support UDP load balancing https://review.openstack.org/503606 | 02:45 |
| johnsom | bzhao ^^^ Please have a look. I need to sign off for the night. Feel free to comment on the patch, I will look in the morning | 02:46 |
| bzhao | johnsom, OK. I will check. Please hava a good rest. Thank you very much. :) Good Night | 02:48 |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Don't run fucntional jobs for docs changes https://review.openstack.org/526548 | 02:51 |
| dayou | @johnsom, fixed a typo for you, since you are busy editing bo's udp spec. | 02:52 |
| openstackgerrit | hujin proposed openstack/neutron-lbaas master: Remove key "l7_policies" in pool dict https://review.openstack.org/527287 | 02:54 |
| *** sanfern has quit IRC | 03:13 | |
| *** tongl has joined #openstack-lbaas | 03:16 | |
| *** bar_ has joined #openstack-lbaas | 03:18 | |
| bar_ | rm_work, ping | 03:23 |
| *** tongl has quit IRC | 03:41 | |
| *** armax has quit IRC | 03:57 | |
| rm_work | bar_: pong | 04:07 |
| bar_ | hey | 04:07 |
| bar_ | do you have conflicts? | 04:07 |
| bar_ | rm_work, my patch was altered https://review.openstack.org/#/c/527199/ ... | 04:08 |
| bar_ | can you +2 it? | 04:08 |
| *** fnaval has quit IRC | 04:09 | |
| *** fnaval has joined #openstack-lbaas | 04:09 | |
| bar_ | (or should i revert those changes perhaps... not sure why they're required) | 04:09 |
| rm_work | yep | 04:10 |
| rm_work | i mean it seems fine | 04:10 |
| rm_work | was trying to see what changed between the patchsets, don't see anything bad | 04:10 |
| bar_ | ok, thanks. perhaps you should rebase onto it? unless another core wants to +2 it. | 04:12 |
| rm_work | i'll get to rebasing my stuff when i need to | 04:12 |
| rm_work | for now it's fine | 04:12 |
| rm_work | we'll see what merges when | 04:12 |
| bar_ | cool | 04:13 |
| *** fnaval has quit IRC | 04:14 | |
| *** threestrands has joined #openstack-lbaas | 04:14 | |
| *** threestrands has quit IRC | 04:14 | |
| *** threestrands has joined #openstack-lbaas | 04:14 | |
| *** jappleii__ has quit IRC | 04:15 | |
| *** fnaval has joined #openstack-lbaas | 04:15 | |
| *** threestrands has quit IRC | 04:15 | |
| *** threestrands has joined #openstack-lbaas | 04:16 | |
| *** threestrands has quit IRC | 04:16 | |
| *** threestrands has joined #openstack-lbaas | 04:16 | |
| *** openstackgerrit has quit IRC | 04:18 | |
| *** links has joined #openstack-lbaas | 04:30 | |
| *** links has quit IRC | 04:32 | |
| bar_ | johnsom, ping | 04:34 |
| bar_ | bzhao, ping | 04:35 |
| *** threestrands has quit IRC | 04:36 | |
| *** threestrands has joined #openstack-lbaas | 04:43 | |
| *** threestrands has quit IRC | 04:43 | |
| *** threestrands has joined #openstack-lbaas | 04:43 | |
| *** threestrands has quit IRC | 04:44 | |
| *** threestrands has joined #openstack-lbaas | 04:44 | |
| *** threestrands has quit IRC | 04:44 | |
| *** threestrands has joined #openstack-lbaas | 04:44 | |
| *** threestrands has quit IRC | 04:45 | |
| *** threestrands has joined #openstack-lbaas | 04:46 | |
| *** threestrands has quit IRC | 04:46 | |
| *** threestrands has joined #openstack-lbaas | 04:46 | |
| *** threestrands has quit IRC | 04:47 | |
| *** threestrands has joined #openstack-lbaas | 04:47 | |
| *** threestrands has quit IRC | 04:47 | |
| *** threestrands has joined #openstack-lbaas | 04:47 | |
| *** openstackgerrit has joined #openstack-lbaas | 05:01 | |
| openstackgerrit | Bar RH proposed openstack/python-octaviaclient master: Add VIP QoS Policy client support https://review.openstack.org/526217 | 05:01 |
| *** bar_ has quit IRC | 05:02 | |
| *** tongl has joined #openstack-lbaas | 05:06 | |
| openstackgerrit | Santhosh Fernandes proposed openstack/octavia master: [WIP] ACTIVE-ACTIVE ExaBGP rest api driver https://review.openstack.org/527009 | 05:25 |
| *** AlexeyAbashkin has joined #openstack-lbaas | 05:43 | |
| *** tongl has quit IRC | 05:56 | |
| *** bbzhao has quit IRC | 05:58 | |
| *** bbzhao has joined #openstack-lbaas | 05:58 | |
| *** threestrands has quit IRC | 06:03 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/neutron-lbaas-dashboard master: Imported Translations from Zanata https://review.openstack.org/527591 | 06:19 |
| bzhao | bar_, pong | 06:20 |
| *** gcheresh has joined #openstack-lbaas | 06:23 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/neutron-lbaas master: Imported Translations from Zanata https://review.openstack.org/527600 | 06:41 |
| *** dokua has joined #openstack-lbaas | 06:49 | |
| *** AlexeyAbashkin has quit IRC | 06:57 | |
| *** rcernin has quit IRC | 07:12 | |
| nmagnezi | rm_work, o/ | 07:17 |
| nmagnezi | rm_work, we still need to discuss bar's amphora agent IP patch :) | 07:18 |
| *** Alex_Staf has joined #openstack-lbaas | 07:41 | |
| *** b_bezak has joined #openstack-lbaas | 07:58 | |
| *** rcernin has joined #openstack-lbaas | 08:13 | |
| openstackgerrit | ZhaoBo proposed openstack/octavia master: Support UDP load balancing https://review.openstack.org/503606 | 08:21 |
| *** tesseract has joined #openstack-lbaas | 08:25 | |
| *** AlexeyAbashkin has joined #openstack-lbaas | 08:27 | |
| *** AlexeyAbashkin has quit IRC | 08:32 | |
| *** AlexeyAbashkin has joined #openstack-lbaas | 08:37 | |
| *** AlexeyAbashkin has quit IRC | 08:43 | |
| *** annp has quit IRC | 08:46 | |
| *** annp has joined #openstack-lbaas | 08:46 | |
| *** yuanying has quit IRC | 08:52 | |
| *** AlexeyAbashkin has joined #openstack-lbaas | 08:57 | |
| *** links has joined #openstack-lbaas | 09:00 | |
| openstackgerrit | ZhaoBo proposed openstack/octavia master: Support UDP load balancing https://review.openstack.org/503606 | 09:19 |
| *** annp has quit IRC | 10:05 | |
| *** yamamoto has quit IRC | 10:13 | |
| *** dosaboy has quit IRC | 10:24 | |
| *** dosaboy has joined #openstack-lbaas | 10:25 | |
| *** sapd_ has quit IRC | 10:28 | |
| *** sapd has joined #openstack-lbaas | 10:30 | |
| *** dosaboy has quit IRC | 10:31 | |
| *** salmankhan has joined #openstack-lbaas | 10:35 | |
| *** dosaboy has joined #openstack-lbaas | 10:37 | |
| *** eN_Guruprasad_Rn has joined #openstack-lbaas | 10:39 | |
| *** yamamoto has joined #openstack-lbaas | 10:43 | |
| *** eN_Guruprasad_Rn has quit IRC | 10:46 | |
| openstackgerrit | Santhosh Fernandes proposed openstack/octavia master: Adding exabgp-speaker element to amphora image https://review.openstack.org/490164 | 10:46 |
| *** eN_Guruprasad_Rn has joined #openstack-lbaas | 10:47 | |
| *** eN_Guruprasad_Rn has quit IRC | 10:50 | |
| *** eN_Guruprasad_Rn has joined #openstack-lbaas | 10:51 | |
| *** salmankhan has quit IRC | 11:37 | |
| *** salmankhan has joined #openstack-lbaas | 11:51 | |
| *** bar_ has joined #openstack-lbaas | 12:11 | |
| *** sanfern has joined #openstack-lbaas | 12:14 | |
| *** sanfern has quit IRC | 12:33 | |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Adding exabgp-speaker element to amphora image https://review.openstack.org/490164 | 12:37 |
| *** dmellado has quit IRC | 12:47 | |
| *** atoth has joined #openstack-lbaas | 12:58 | |
| *** dmellado has joined #openstack-lbaas | 12:58 | |
| *** rcernin has quit IRC | 13:04 | |
| *** dmellado has quit IRC | 13:08 | |
| *** dmellado has joined #openstack-lbaas | 13:09 | |
| *** tesseract has quit IRC | 13:51 | |
| openstackgerrit | Bar RH proposed openstack/octavia master: Specify management IP addresses per amphora https://review.openstack.org/505158 | 13:52 |
| *** links has quit IRC | 13:58 | |
| *** links has joined #openstack-lbaas | 14:00 | |
| *** bar_ has quit IRC | 14:00 | |
| *** links has quit IRC | 14:05 | |
| *** fnaval has quit IRC | 14:13 | |
| *** openstackstatus has quit IRC | 14:36 | |
| *** openstackstatus_ has joined #openstack-lbaas | 14:37 | |
| *** openstackstatus_ has quit IRC | 14:37 | |
| *** openstackstatus has joined #openstack-lbaas | 14:38 | |
| *** openstack has quit IRC | 14:39 | |
| *** openstack has joined #openstack-lbaas | 14:43 | |
| *** ChanServ sets mode: +o openstack | 14:43 | |
| *** openstack has quit IRC | 14:43 | |
| *** openstack has joined #openstack-lbaas | 14:48 | |
| *** ChanServ sets mode: +o openstack | 14:48 | |
| *** armax has joined #openstack-lbaas | 14:57 | |
| *** fnaval has joined #openstack-lbaas | 14:59 | |
| *** ianychoi has quit IRC | 15:04 | |
| *** salmankhan has quit IRC | 15:14 | |
| *** tongl has joined #openstack-lbaas | 15:17 | |
| *** links has joined #openstack-lbaas | 15:19 | |
| *** eN_Guruprasad_Rn has quit IRC | 15:23 | |
| *** eN_Guruprasad_Rn has joined #openstack-lbaas | 15:24 | |
| *** dokua has quit IRC | 15:25 | |
| *** dosaboy has quit IRC | 15:28 | |
| *** dosaboy has joined #openstack-lbaas | 15:28 | |
| openstackgerrit | German Eichberger proposed openstack/octavia master: ACTIVE-ACTIVE with LVS - DIB https://review.openstack.org/499807 | 15:34 |
| *** salmankhan has joined #openstack-lbaas | 15:47 | |
| *** armax has quit IRC | 15:47 | |
| *** gcheresh has quit IRC | 15:47 | |
| *** b_bezak has quit IRC | 15:53 | |
| *** Alex_Staf has quit IRC | 16:01 | |
| *** ianychoi has joined #openstack-lbaas | 16:06 | |
| *** longstaff has joined #openstack-lbaas | 16:07 | |
| *** ssmith has joined #openstack-lbaas | 16:09 | |
| *** armax has joined #openstack-lbaas | 16:18 | |
| *** armax has quit IRC | 16:21 | |
| *** eN_Guruprasad_Rn has quit IRC | 16:42 | |
| johnsom | I love coming into the office in the morning finding uwsgi out to lunch with 100% cpu usage for the devstack services.... Ugh | 16:44 |
| *** AlexeyAbashkin has quit IRC | 16:47 | |
| xgerman_ | fun times | 16:47 |
| *** tongl has quit IRC | 16:49 | |
| johnsom | If the thing is going to go into cryptocurrency mode to fund the dev it might as well be efficient about it and use the GPU.... | 16:50 |
| xgerman_ | we should add some cryprocurrency code to Octavia to fund an Octavia party in Dublin | 16:56 |
| johnsom | We wouldn't get far with uwsgi stealing all of the cycles. | 16:59 |
| johnsom | Interesting tidbit of the morning: TCP bandwidth through an amp is the same with HAproxy or just a simple socat tunnel. Both of which are about 10gbps slower than a direct connection. (this is on devstack inside vmware on a desktop). | 17:06 |
| johnsom | If I go from amp to member it is ~6gbps slower than host to member. | 17:08 |
| johnsom | It doesn't appear to be CPU in the amp, but qemu certainly spikes on the host. | 17:10 |
| xgerman_ | I saw some cilium stuff in my twitter feed and they manages to do that kernel network proxying without decoding TCP… | 17:11 |
| johnsom | Yeah, I'm not decoding or inspecting either, it's bits in bits out. Pretty happy that haproxy is pretty close to the same performance as that | 17:12 |
| *** sanfern has joined #openstack-lbaas | 17:13 | |
| johnsom | Just wishing the infrastructure around us was a bit faster. | 17:13 |
| xgerman_ | yeah, they probably do decoding/encoding or at least copying things around | 17:13 |
| xgerman_ | in OVS, linux Bridge | 17:13 |
| johnsom | Yeah, don't see CPU spikes there though, it's really qemu that seems questionable. | 17:14 |
| xgerman_ | mmh | 17:14 |
| sanfern | o/ | 17:15 |
| johnsom | I kind of expected to see OVS up but it wasn't the clear CPU hog | 17:15 |
| xgerman_ | yeah, I would have fingered them, too | 17:17 |
| sanfern | Johnsom., I tested exabgp element patch and figured out the issue. Basically I had to add my review id in amphora-agent element | 17:19 |
| *** tongl has joined #openstack-lbaas | 17:19 | |
| sanfern | by default exabgp will not start - http://paste.openstack.org/show/CVH8BVALOyLXdfjnhs2A/ | 17:20 |
| johnsom | Hmm, it's not picking up the patch version... We should fix that. Probably a zuul change issue. | 17:20 |
| sanfern | ok | 17:20 |
| sanfern | one more query - https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt this shows exabgp version 4.0.2 | 17:21 |
| sanfern | but when we update requirements.txt to exabgp>=4.0.2 it fails | 17:22 |
| johnsom | You must copy the line exactly from https://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n57 | 17:22 |
| *** eN_Guruprasad_Rn has joined #openstack-lbaas | 17:23 | |
| *** bar_ has quit IRC | 17:26 | |
| *** armax has joined #openstack-lbaas | 17:30 | |
| sanfern | There is a mismatch in upper-constraints.txt and global-requirements.txt file :( | 17:30 |
| johnsom | Yes, they are two different config files | 17:31 |
| sanfern | ok thanks | 17:33 |
| sanfern | https://review.openstack.org/#/c/524722/13 - this patch is not running through gates | 17:33 |
| sanfern | I want your help to solve those repo tests are failing :( | 17:34 |
| johnsom | Ok, I will have a look once that zuul run finishes | 17:34 |
| *** links has quit IRC | 17:40 | |
| sanfern | Thank you johnsom | 17:50 |
| *** eN_Guruprasad_Rn has quit IRC | 17:51 | |
| *** bar_ has joined #openstack-lbaas | 17:54 | |
| *** bar_ has quit IRC | 17:57 | |
| openstackgerrit | Merged openstack/octavia-dashboard master: Imported Translations from Zanata https://review.openstack.org/525908 | 18:08 |
| *** Swami has joined #openstack-lbaas | 18:11 | |
| *** AlexeyAbashkin has joined #openstack-lbaas | 18:17 | |
| *** AlexeyAbashkin has quit IRC | 18:21 | |
| *** gcheresh has joined #openstack-lbaas | 18:27 | |
| *** gcheresh has quit IRC | 18:38 | |
| *** yamamoto has quit IRC | 18:45 | |
| *** gcheresh has joined #openstack-lbaas | 18:50 | |
| *** yamamoto has joined #openstack-lbaas | 19:01 | |
| *** atoth has quit IRC | 19:03 | |
| *** sshank has joined #openstack-lbaas | 19:04 | |
| *** yamamoto has quit IRC | 19:06 | |
| *** salmankhan has quit IRC | 19:14 | |
| *** openstackstatus has quit IRC | 19:27 | |
| *** jniesz has joined #openstack-lbaas | 19:37 | |
| sanfern | johnsom, http://paste.openstack.org/show/8If6iLYePrSRS3ohEjxL/ - help | 19:45 |
| sanfern | http://paste.openstack.org/show/3LiJtFfIuVzbpwYbX9YY/ | 19:47 |
| johnsom | Ok, updated the very full agenda: https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda | 19:52 |
| johnsom | I re-ordered some stuff to try to give a fair timeslot | 19:53 |
| johnsom | #startmeeting Octavia | 20:00 |
| openstack | Meeting started Wed Dec 13 20:00:02 2017 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:00 |
| *** openstack changes topic to " (Meeting topic: Octavia)" | 20:00 | |
| openstack | The meeting name has been set to 'octavia' | 20:00 |
| johnsom | Hi folks! | 20:00 |
| xgerman_ | o/ | 20:00 |
| johnsom | Another fine week in OpenStack land | 20:00 |
| nmagnezi | o/ | 20:00 |
| longstaff | hi | 20:00 |
| *** rm_mobile has joined #openstack-lbaas | 20:00 | |
| cgoncalves | hey | 20:00 |
| johnsom | (well, ok, zuul had it's issues...) | 20:00 |
| johnsom | #topic Announcements | 20:00 |
| *** openstack changes topic to "Announcements (Meeting topic: Octavia)" | 20:01 | |
| rm_mobile | o/ | 20:01 |
| johnsom | I have two items | 20:01 |
| johnsom | One, queens MS2 did finally release | 20:01 |
| johnsom | I also released a new python-octaviaclient | 20:01 |
| johnsom | So, good stuff there. | 20:01 |
| johnsom | Also I wanted to make you aware of a lively discussion on the mailing list about changing the release cycle of OpenStack to once per year. | 20:02 |
| johnsom | #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html | 20:02 |
| xgerman_ | guess we are maturing… | 20:02 |
| johnsom | If you have any feeling about the PTG meetings or release timing, feel free to jump into the conversation | 20:02 |
| nmagnezi | johnsom, what do you think about this? | 20:02 |
| johnsom | I have mixed feelings. | 20:03 |
| johnsom | I think overall it will slow innovation on the project. I worry about trying to do stable branch bug backports from master that has up to a year of feature work. I do think we are a bit of a treadmill with the PTGs and PTL elections, etc. Finally, the goals do hurt the projects with the six month cycles since some require a lot of work. | 20:04 |
| johnsom | I think it may mean that the PTL needs to take on more management work to keep the project on track. Maybe more defined sprints or team milestones. | 20:05 |
| johnsom | Just some top of head thoughts. | 20:05 |
| rm_mobile | Yeah... Some of the stuff is too fast, but... Longer cycles means bigger releases which does not help with upgrades | 20:05 |
| johnsom | Any other comments? | 20:05 |
| nmagnezi | yeah. i wonder how we exactly shift to 1 year planning - feature-wise | 20:05 |
| johnsom | Yep | 20:06 |
| xgerman_ | one PTG per year clearly makes attanding the summits more imrportant | 20:06 |
| johnsom | Yeah, my last read of the list the proposal was one PTG, still two summits | 20:06 |
| johnsom | Ok, any other announcements? | 20:06 |
| nmagnezi | xgerman_, so virtual PTGs? :) | 20:06 |
| xgerman_ | midcycles? | 20:07 |
| johnsom | nmagnezi I thought about that | 20:07 |
| nmagnezi | could be tricky, timezone-wise | 20:07 |
| nmagnezi | but I'll be in favor of that. | 20:07 |
| johnsom | #topic Brief progress reports / bugs needing review | 20:07 |
| *** openstack changes topic to "Brief progress reports / bugs needing review (Meeting topic: Octavia)" | 20:07 | |
| johnsom | Ok, moving along to try to give time for other topics | 20:08 |
| rm_mobile | Do we need to pick up anything from last week? | 20:08 |
| johnsom | I have been focused on getting reviews done and updates to the specs in flight. | 20:08 |
| johnsom | rm_mobile Yes, I have a long list | 20:08 |
| rm_mobile | Lol k | 20:08 |
| johnsom | 5 topics including the carry over | 20:08 |
| *** Kowsalya has joined #openstack-lbaas | 20:08 | |
| johnsom | I hope we can merge QoS this week. | 20:09 |
| *** yamamoto has joined #openstack-lbaas | 20:09 | |
| johnsom | Provider driver spec is looking good, but we really would like feedback on some topics. Specifically on my mind is should the Octavia API create the VIP port and pass to the driver or should the driver be responsible for creating the VIP port. | 20:10 |
| johnsom | Please comment on that topic if you have a driver in your future. | 20:10 |
| *** sshank has quit IRC | 20:10 | |
| johnsom | The UDP spec is also coming along nicely. Feedback welcome. | 20:10 |
| johnsom | #link https://review.openstack.org/509957 | 20:10 |
| nmagnezi | I commented about that (VIP port create). would be happy to elaborate more if needed | 20:11 |
| johnsom | #link https://review.openstack.org/503606 | 20:11 |
| johnsom | Any other progress updates? | 20:11 |
| johnsom | #topic (rm_work / dayou) Element Flag for Disabling DHCP | 20:11 |
| *** openstack changes topic to "(rm_work / dayou) Element Flag for Disabling DHCP (Meeting topic: Octavia)" | 20:12 | |
| johnsom | #link https://review.openstack.org/#/c/520590/ | 20:12 |
| johnsom | We didn't get to this last week, so I put it at the top this week | 20:12 |
| rm_mobile | Getting to a real keyboard for this lol | 20:12 |
| johnsom | My understanding on it was the issue dayou was having was/can be resolved without this. | 20:12 |
| rm_work | o/ | 20:12 |
| rm_work | hmmm can it? | 20:12 |
| rm_work | I mean, the DHCP issue is one that I have as well (just use an internal patch to fix it) | 20:13 |
| johnsom | My biggest concern with the patch is issues with cloud-init overriding those changes. | 20:13 |
| jniesz | i think the problem with cloud init it doesn't support slaac | 20:13 |
| jniesz | expects dhcp or static | 20:13 |
| johnsom | jniesz No, it uses slaac. That is all I have in my lab | 20:14 |
| rm_work | my issue is that our cloud HAS NO DHCP (i believe we're not alone in this either), and images stall on the dhcp step for ipv4 even | 20:14 |
| rm_work | maybe there is a better way to fix this that I'm missing? | 20:14 |
| jniesz | johnsom it wasn't in the source code, i didn't see anything for it to write out inet6 auto lie | 20:14 |
| xgerman_ | but then the coud-init shoudl set it as static? | 20:14 |
| rm_work | but, it seems that it stalls on dhcp even before cloud-init runs to change it | 20:14 |
| rm_work | because cloud-init DOES have a static config to send it | 20:14 |
| jniesz | static != slaac | 20:15 |
| johnsom | rm_work That is a different issue | 20:15 |
| rm_work | right | 20:15 |
| rm_work | but this patch was designed to fix both | 20:15 |
| jniesz | yea | 20:15 |
| rm_work | i guess if it's just my issue, I can just stick to my current internal patch that ... well, does exactly this (which works) | 20:16 |
| johnsom | It's been a while since I booted a v6 enabled amp, so I'm not sure how cloud init handles it. I know we have code in for the v6 auto case | 20:16 |
| jniesz | johnsom: is that dhcpv6 though? | 20:16 |
| johnsom | No, I don't have dhcpv6 | 20:16 |
| nmagnezi | johnsom, IIRC the jinja templates handle a static ipv6 as well. but I didn't test it | 20:16 |
| rm_work | this is what I apply internally: http://paste.openstack.org/show/628898/ | 20:17 |
| xgerman_ | so rm_work says it comes up eventually after dhcp gives up | 20:17 |
| rm_work | yes, like 5 minutes >_> | 20:17 |
| rm_work | which is way outside the timeout for my cloud | 20:17 |
| johnsom | So, I think we should break this into two stories. 1. for the dhcp delay 2. for booting v6 only amps. | 20:17 |
| xgerman_ | +1 | 20:17 |
| rm_work | k, just figured it was a workable solution for both, but yeah if his issue needs to be solved in a different way, then this would just be for me | 20:18 |
| rm_work | i just pushed this because at the time he was duplicating my work for dhcp disabling | 20:18 |
| *** yamamoto has quit IRC | 20:18 | |
| jniesz | yea this would work for booth | 20:18 |
| johnsom | The concern is hacking on the network scripts that cloud-init manages/overwrites is worrisome, especially if we don't explicitly tell cloud-init that we are managing those. | 20:19 |
| johnsom | Like, that paste, doesn't a reboot overwrite that? | 20:19 |
| xgerman_ | +1 | 20:19 |
| rm_work | johnsom: it doesn't seem to <_< though a reboot causes a failover and recycle for me | 20:19 |
| rm_work | so it's hard to tell | 20:19 |
| rm_work | but i mean, it doesn't seem to be overwritten by cloudinit | 20:19 |
| jniesz | cloud-init assumes wrong things : ) | 20:19 |
| rm_work | looking at existing amps | 20:19 |
| johnsom | I'm also not as familar with cloud-init under CentOS as I am ubuntu | 20:20 |
| xgerman_ | nmagnezi? | 20:20 |
| nmagnezi | would have to check | 20:20 |
| johnsom | cloud-init does what neutron and nova tells it. That was the solution we came up with for your case jniesz | 20:20 |
| jniesz | yea, but it doesn't work | 20:21 |
| jniesz | for slaac | 20:21 |
| jniesz | cloud init needs to be enhanced to add that | 20:21 |
| jniesz | and then would have to wait for distros to add new cloud init | 20:21 |
| johnsom | jniesz Something doesn't jive with that. All I have is slaac here and I had working IPv6, so ... | 20:21 |
| jniesz | it looks for dhcp | 20:22 |
| jniesz | otherwise assumes static | 20:22 |
| johnsom | The other part I didn't like with the script is it is specific to the distros, where cloud init handles the translations for us. | 20:22 |
| jniesz | in the network metadat | 20:22 |
| rm_work | oh actually yes, looked again, it IS overwritten by cloud-init :( but cloud-init does this AFTER the boot step that tries to DHCP an address | 20:23 |
| rm_work | so yeah probably on reboot it would have issues :( | 20:23 |
| johnsom | So, my ask, let's open stories that characterize the use cases, then we bind patches to those and work from there. | 20:23 |
| *** dokua has joined #openstack-lbaas | 20:23 | |
| rm_work | is there some way for me to send these options during cloud-init boot? | 20:23 |
| johnsom | rm_work See, I'm not totally crazy... grin | 20:23 |
| rm_work | but ... | 20:23 |
| rm_work | see this is a problem still | 20:24 |
| rm_work | i still need my patch | 20:24 |
| johnsom | Yes, there are much better ways. | 20:24 |
| rm_work | just ALSO need to update cloud-init | 20:24 |
| rm_work | because again, cloud-init hasn't replaced it by the time it causes a problem | 20:24 |
| rm_work | it replaces it AFTER | 20:24 |
| rm_work | so i need both fixes | 20:24 |
| johnsom | So, let's open stories and work on solutions for those use cases | 20:24 |
| rm_work | k | 20:24 |
| johnsom | #topic (rm_work / BAR_RH) Specify management IP addresses per amphora | 20:25 |
| *** openstack changes topic to "(rm_work / BAR_RH) Specify management IP addresses per amphora (Meeting topic: Octavia)" | 20:25 | |
| johnsom | #link https://review.openstack.org/#/c/505158/ | 20:25 |
| johnsom | So we discussed this last week. I think there was concern about the approach. We talked about the update config API extension that we have wanted for a while. | 20:26 |
| johnsom | Where did we leave this? | 20:26 |
| rm_work | Was this the one where nmagnezi and I needed to talk after? | 20:26 |
| nmagnezi | yes. and we didn't catch each other here in the past week | 20:27 |
| *** Kowsalya has quit IRC | 20:27 | |
| rm_work | T_T | 20:27 |
| johnsom | lol | 20:27 |
| *** dokua has quit IRC | 20:27 | |
| johnsom | So should we table this another week? | 20:27 |
| rm_work | Summary I think was: Instead of futzing with the flows, we just need to leave the binding as-is on boot, and then on first connect we update the config to point to the single management address | 20:27 |
| *** openstackstatus has joined #openstack-lbaas | 20:27 | |
| nmagnezi | I must admit that the agent restart per-api call sounds a bit like a hack to me. so I wanted to discuss this a bit more | 20:27 |
| *** ChanServ sets mode: +v openstackstatus | 20:27 | |
| rm_work | nmagnezi: not every API call... just the update-agent-config call | 20:28 |
| rm_work | which we wanted for a while anyway | 20:28 |
| rm_work | for things like updating the HM list | 20:28 |
| nmagnezi | why did we want it to begin with? | 20:28 |
| johnsom | We can use the oslo reload stuff too, no need for a full restart | 20:28 |
| xgerman_ | +1 | 20:28 |
| johnsom | The HM IP:Port list is my #1 | 20:29 |
| rm_work | same | 20:29 |
| nmagnezi | well, I'm open for discussion about this. if there's a nice way to achieve this I'm all ears | 20:29 |
| johnsom | nmagnezi Why did we want the IP fixed? It's a very old bug before we added the namespace | 20:29 |
| xgerman_ | if you ever hack the system you can then sink the whole fleet by sending bogus configs | 20:30 |
| *** Kousalya has joined #openstack-lbaas | 20:30 | |
| rm_work | ? | 20:30 |
| rm_work | how | 20:30 |
| nmagnezi | johnsom, because it might be risky to bind to * | 20:30 |
| rm_work | nmagnezi: thats how it CURRENTLY works | 20:30 |
| nmagnezi | johnsom, the agent runs on the root namespace | 20:30 |
| johnsom | nmagnezi Correct | 20:30 |
| rm_work | nmagnezi: and what i'm saying is, on the *initial* call, we move it to the correct IP | 20:31 |
| johnsom | xgerman_ ??? what? no | 20:31 |
| johnsom | It uses the same two way SSL all of our config work happens over | 20:31 |
| rm_work | nmagnezi: and if the initial call fails (someone somehow beat us to it???) we fail to finish amp creation and we trash it anyway | 20:31 |
| xgerman_ | if we allow configs being changed that is a theoretical possibility | 20:31 |
| johnsom | So, if you get that far you are game over anyway | 20:31 |
| johnsom | xgerman_ We are talking about the amphora-agent config file inside the amp, not controllers | 20:32 |
| nmagnezi | rm_work, let's discuss this further. I'm open for discussion about this, as I said. | 20:32 |
| nmagnezi | :) | 20:32 |
| rm_work | lolk | 20:33 |
| johnsom | Ok | 20:33 |
| rm_work | so, next year? :P | 20:33 |
| johnsom | #topic (sanfern / rm_work) Changes to DB schema for VRRP ports | 20:33 |
| *** openstack changes topic to "(sanfern / rm_work) Changes to DB schema for VRRP ports (Meeting topic: Octavia)" | 20:33 | |
| nmagnezi | rm_mobile, ¯\_(ツ)_/¯ | 20:33 |
| johnsom | #link https://review.openstack.org/#/c/521138/ | 20:33 |
| *** rm_mobile has quit IRC | 20:33 | |
| johnsom | So next up was the rename patch. | 20:33 |
| rm_work | I guess all I wanted to know was, is everyone else OK with us changing field names in a DB schema | 20:33 |
| johnsom | I think some work as occurred over the last week to resolve some of the backwards compatibility issues. | 20:34 |
| rm_work | as an upgrade it is scary to me, since it absolutely kills zero-downtime | 20:34 |
| rm_work | hmm | 20:34 |
| jniesz | it doesn't bring the amps down, just the control plane | 20:34 |
| rm_work | yes | 20:34 |
| jniesz | I know sanfran added fix for amp agents | 20:34 |
| rm_work | just a control-plane outage | 20:34 |
| jniesz | so they wouldn't all have to be upgraded | 20:34 |
| rm_work | yeah that's good :P | 20:34 |
| rm_work | i hadn't even noticed that part yet, that would have been bad | 20:35 |
| johnsom | Right, my stance has been we have not asserted any of the upgrade support tags yet. (nor do we have a gate) | 20:35 |
| rm_work | i just saw the migration and immediately stopped | 20:35 |
| rm_work | so as i keep saying, if everyone else is OK with this, then I am fine | 20:35 |
| xgerman_ | yeah, I think we can do a rename/update — I also think we are still in the window to change the /octavia/amphora endpoint | 20:36 |
| rm_work | yes | 20:36 |
| johnsom | Yeah, I agree on that | 20:36 |
| nmagnezi | I have to abstain once more. since we yet to ship Octavia that does affect us in any way | 20:36 |
| nmagnezi | so.. If it's in I'm fine with it. | 20:37 |
| rm_work | so I just wanted a vote on "Can we change field names in our existing DB schema" | 20:37 |
| rm_work | I'm concerned about my deployment, but also others | 20:37 |
| * johnsom gives nmagnezi a glare of shame.... grin | 20:37 | |
| nmagnezi | johnsom, lol, why? :-) | 20:37 |
| johnsom | You haven't shipped | 20:37 |
| cgoncalves | :) | 20:37 |
| rm_work | as one of the things we get yelled at during project update sessions every summit is that our upgrades are not clean (though usually it's around the APIs) | 20:37 |
| nmagnezi | johnsom, tripleO.. soon enough! | 20:37 |
| johnsom | rm_work I hear you. We should be working towards clean upgrades. My question to you is if all of the glue code required to do a smooth transition to reasonably sane names is worth it. | 20:38 |
| johnsom | I mean really it's a migration that adds the new column, copies the data, and maintains both for some deprecation cycle. | 20:39 |
| rm_work | i absolutely would love to have these column names fixed to be less dumb | 20:40 |
| johnsom | Long term I would hate to have one set of terms in the models and a different in the DB | 20:40 |
| rm_work | i am just concerned about whether we're supposed to be doing this kind of change | 20:40 |
| rm_work | yeah | 20:40 |
| johnsom | Well, from an OpenStack perspective, if we have not asserted the upgrade tags (we have not), a downtime upgrade is fair game | 20:41 |
| johnsom | As long as we don't require the amps to go down, I think I'm ok with it. (pending reviewing the full patch again) | 20:41 |
| rm_work | kk | 20:42 |
| nmagnezi | #link https://review.openstack.org/#/c/521138/ | 20:42 |
| rm_work | yeah that's why i asked we vote not on the patch but on the core concept | 20:42 |
| rm_work | "Can we change field names in our existing DB schema" | 20:42 |
| rm_work | seems like everyone is thinking "yes" | 20:42 |
| johnsom | But you, jniesz and mnaser have this running in some form of production, so your voices matter here | 20:42 |
| rm_work | for me it matters a lot, since this upgrade will happen for me just about the moment it merges | 20:43 |
| jniesz | when we upgrade openstack regions we have to schedule control plane downtime anyways | 20:43 |
| rm_work | since I run master, deployed weekly <_< | 20:43 |
| nmagnezi | rm_work, master? really? | 20:43 |
| rm_work | yes | 20:43 |
| nmagnezi | man.. | 20:43 |
| *** amotoki has quit IRC | 20:43 | |
| *** logan- has quit IRC | 20:43 | |
| johnsom | Yes, see nmagnezi you should ship... grin | 20:43 |
| nmagnezi | lol. | 20:43 |
| johnsom | grin | 20:43 |
| *** logan- has joined #openstack-lbaas | 20:43 | |
| * rm_work laughs maniacally | 20:43 | |
| *** amotoki has joined #openstack-lbaas | 20:44 | |
| jniesz | yea, I would like to get us to the point where we are deploying master | 20:44 |
| rm_work | jniesz: it isn't that hard actually IME | 20:44 |
| rm_work | just switch what tag you pull :P | 20:44 |
| rm_work | hopefully existing CI+tests takes care of issues | 20:44 |
| jniesz | yea, I think something we will look at after the pike upgrades | 20:44 |
| johnsom | Ok, so I hear an operator wanting an upgrade path. We should try to support them. | 20:45 |
| rm_work | yeah since Octavia is cloud-version-agnostic | 20:45 |
| johnsom | rm_work are you willing to help with the coding for the patch? | 20:45 |
| rm_work | the coding for this patch? | 20:45 |
| johnsom | Yep | 20:45 |
| rm_work | I mean... how do we even do this | 20:45 |
| mnaser | thanks for highlighting me | 20:45 |
| rm_work | i thought it was basically "rename or don't" | 20:45 |
| mnaser | my comment is: control plane downtime is acceptable, because that sort of thing can be scheduled | 20:46 |
| johnsom | mnaser Are you caught up? Do you have an opinion here? | 20:46 |
| rm_work | yeah I am leaning towards that as well honestly | 20:46 |
| mnaser | also, api downtime in this case doesn't really cause that much issues, its not as critically hit as a service like nova for example | 20:46 |
| rm_work | but I was literally not sure if this was a smart idea politically | 20:46 |
| *** kpalan1 has joined #openstack-lbaas | 20:46 | |
| rm_work | but johnsom asserts we have not tagged ourselves with anything that would cause a problem | 20:46 |
| rm_work | so | 20:46 |
| mnaser | to be honest, it is very rare that you can get downtime-less upgrades, even with big projects | 20:46 |
| johnsom | I think we would have to do the migration to have both columns in parallel so the models can continue using the old until upgraded. | 20:46 |
| rm_work | ah yes. | 20:47 |
| rm_work | well | 20:47 |
| mnaser | johnsom: brings a good point, unless you make it very clear that the old services must be shut down when starting a new one | 20:47 |
| rm_work | honestly -- i think if we don't have any big political issues with this -- we just do it, and make a big flashy release node | 20:47 |
| rm_work | *release note | 20:47 |
| johnsom | Right, this would have rich release notes for upgrade.... | 20:47 |
| jniesz | +1 | 20:47 |
| mnaser | we run 3 replicas of octavia but our upgrade procedure usually is, turn off all replicas except one, upgrade this single replica, when everything is back up and working properly ,start up the rest | 20:47 |
| mnaser | perhaps add some sort of failsafe to prevent it from starting up with a newer database and failing unpredictabely? | 20:48 |
| johnsom | mnaser This would be a "shutdown control plane", "run DB migration", "upgrade control plane", "start control plane" type of release | 20:48 |
| xgerman_ | you forgot backup DB | 20:49 |
| mnaser | perhaps if db_migration_version > release_migration_version: refuse_to_start() | 20:49 |
| johnsom | As it is written now. | 20:49 |
| johnsom | mnaser Hmm, we don't have that today | 20:49 |
| xgerman_ | yeah, we need that to not corrupt the DB willingly | 20:50 |
| johnsom | Currently our upgrade is "db migration", then update control plane | 20:50 |
| johnsom | This is the first patch that would not work that way | 20:50 |
| *** Kousalya has quit IRC | 20:50 | |
| johnsom | So, let me ask again, Are there folks willing to help on this patch to make it a smooth upgarde? | 20:51 |
| mnaser | im unable to commit any effort into that so for our side, it will likely be: turn off all replicas, upgrade packages of 1 replica, sync db, start 1 replica, check if all ok, start up other replicas after upgrading | 20:52 |
| mnaser | as an operator im perfectly content with that procedure (its what we used for many others) | 20:52 |
| rm_work | i'm pretty much booked for this week and then i'm out essentially until January | 20:52 |
| rm_work | so | 20:52 |
| rm_work | .... | 20:52 |
| rm_work | and i'm ok with this upgrade procedure | 20:52 |
| rm_work | personally | 20:53 |
| rm_work | my concern was that it's the ... like, 4 of us that deploy AND are active enough in the project to be talking in the weekly meetings | 20:53 |
| johnsom | Ok, so I think I hear all three stack holders that are present saying they are ok with this upgrade procedure. Correct? | 20:53 |
| rm_work | that are saying it's ok | 20:53 |
| rm_work | people who aren't this active but are deploying octavia ... those are who I worry about | 20:53 |
| johnsom | Understand. | 20:54 |
| rm_work | and i wonder about what kind of support load this will cause | 20:54 |
| johnsom | I guess the last option is to sit on this until someone can work on it | 20:54 |
| rm_work | but ... i also don't have a lot of time to devote to this patch, so | 20:54 |
| rm_work | we COULD patch just the amphora API | 20:54 |
| rm_work | so we get it before it releases | 20:54 |
| johnsom | I don't think that is a good option given it's scope | 20:54 |
| rm_work | and then fix the actual DB later | 20:55 |
| rm_work | the only place it's exposed is that API | 20:55 |
| nmagnezi | rm_work, that's a valid point. they way I see it is the best option to ensure we don't break existing deployments is with alembic migrations\ | 20:55 |
| rm_work | so if we're looking like it won't make it to Queens, it's simple to update just those fields | 20:55 |
| johnsom | It's the internals that are important for L3 Act/Act work | 20:55 |
| rm_work | yeah ... | 20:55 |
| rm_work | alright, maybe the best approach IS to "add columns" | 20:55 |
| rm_work | and duplicate the writes? | 20:56 |
| *** alex_staf_1 has joined #openstack-lbaas | 20:56 | |
| rm_work | these columns aren't large | 20:56 |
| rm_work | so it's extra data but not tooo much | 20:56 |
| rm_work | right? | 20:56 |
| johnsom | Yeah, that is the work I described. | 20:56 |
| jniesz | I think that would be acceptable | 20:56 |
| johnsom | Then at some later point drop the duplicates | 20:56 |
| rm_work | yeah | 20:56 |
| rm_work | when is the last day we could do this | 20:57 |
| johnsom | We have four minutes. I would like to close on this | 20:57 |
| rm_work | Q-3? | 20:57 |
| johnsom | Yes | 20:57 |
| rm_work | is it a "feature"? | 20:57 |
| rm_work | k and that's ... mid-Jan? | 20:57 |
| johnsom | Yes. | 20:57 |
| rm_work | k... I just won't have time until January | 20:57 |
| rm_work | but THEN maybe I could look at it ... MAYBE. | 20:57 |
| rm_work | if it's not done yet | 20:57 |
| johnsom | Ok, so decided to make it upgrade compat. We can figure out how/when it gets done later. | 20:57 |
| rm_work | k | 20:58 |
| rm_work | what DIDN'T we get to | 20:58 |
| johnsom | Interface driver support and Members API Improvements Proposal | 20:58 |
| nmagnezi | bar is not around | 20:58 |
| nmagnezi | and.. we have like a min for it.. | 20:59 |
| cgoncalves | yeah... | 20:59 |
| rm_work | yeah i was mostly just curious | 20:59 |
| johnsom | Right. | 20:59 |
| johnsom | Ok, thanks for a lively meeting today. We got through some of it. | 20:59 |
| johnsom | cgoncalves If you can hang around for a minute we can talk about your topic | 20:59 |
| rm_work | yeah i'm good for a few min too | 21:00 |
| johnsom | #endmeeting | 21:00 |
| *** ssmith has quit IRC | 21:00 | |
| *** openstack changes topic to "Welcome to LBaaS / Octavia - Queens development is now open." | 21:00 | |
| openstack | Meeting ended Wed Dec 13 21:00:06 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-13-20.00.html | 21:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-13-20.00.txt | 21:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/octavia/2017/octavia.2017-12-13-20.00.log.html | 21:00 |
| cgoncalves | I'm okay with that, not sure about other folks | 21:00 |
| johnsom | This is just an informal chat about the topic, it's a good topic for the weekly meeting oto | 21:00 |
| johnsom | too | 21:00 |
| *** kpalan1 has left #openstack-lbaas | 21:00 | |
| xgerman_ | k | 21:00 |
| johnsom | So, the middle story, https://storyboard.openstack.org/#!/story/1685223 | 21:01 |
| johnsom | I am tempted to close as a duplicate to "we need an install guide" | 21:01 |
| cgoncalves | ok. not sure it has got your (cores) attention yet to those storyboards/launchpad bugs | 21:01 |
| cgoncalves | there are 2 main problems with the current approach | 21:01 |
| johnsom | Yeah, we have had some isssues with storyboard not notifying | 21:01 |
| cgoncalves | 1) subnet collision because o-hm0 is on root namespace | 21:02 |
| johnsom | Well, it is super clear you can't use the devstack solution in production, that was never intended | 21:02 |
| cgoncalves | 2) dependency on the deployment tool to create o-hm0 | 21:02 |
| openstackgerrit | Santhosh Fernandes proposed openstack/octavia master: [WIP] ACTIVE-ACTIVE create distributoe flow https://review.openstack.org/527784 | 21:02 |
| johnsom | #1 how so? | 21:02 |
| cgoncalves | johnsom: o-hm0 is on root namespace, agree? it has an IP address so... | 21:03 |
| johnsom | o-hm0 is just a port for devstack. It should not be used necessarily in production | 21:03 |
| cgoncalves | thus an ip route entry also gets added to the route table | 21:03 |
| nmagnezi | johnsom, yeah but it translates to a NIC, which adds entry in the routing table | 21:04 |
| johnsom | Right, so don't do that | 21:04 |
| nmagnezi | so.. how do you do it? | 21:04 |
| cgoncalves | yes, but if the ip address assigned is e.g. 192.168.0.100 which might collide with existing subnets | 21:04 |
| cgoncalves | or am I getting it wrong? | 21:04 |
| johnsom | Do what works for your deployment. Those calls all route, if routing works better for your deployment, do that. | 21:04 |
| cgoncalves | yes, right | 21:05 |
| johnsom | If you want to setup a NIC, create a namespace, the network config files, and run it in a namespace | 21:05 |
| rm_work | what existing subnets? | 21:05 |
| cgoncalves | the idea now would be to find a way to not be dependent on the deployment tool | 21:05 |
| johnsom | I think OpenStack Ansible puts it all in a container. | 21:05 |
| rm_work | ah wait, this is for HM | 21:06 |
| xgerman_ | yep | 21:06 |
| rm_work | i forget what this one even is >_< | 21:06 |
| rm_work | we don't use this | 21:06 |
| johnsom | rm_work yeah, how control plane talks to amps | 21:06 |
| xgerman_ | anibsle puts all services in the same container | 21:06 |
| xgerman_ | 9for now) | 21:06 |
| cgoncalves | yes yes :) | 21:06 |
| rm_work | oh | 21:06 |
| rm_work | you mean mgmt-net? | 21:06 |
| rm_work | not hm | 21:06 |
| cgoncalves | o-hm0 = octavia health manager :) | 21:06 |
| johnsom | Right, it's really about the lb-mgmt-net | 21:06 |
| xgerman_ | most deployments have different network setup so it’s hard for us to prescrive a solution | 21:07 |
| rm_work | isn't that the ONLY thing plugged in the root namespace? | 21:07 |
| johnsom | xgerman_ +1 | 21:07 |
| johnsom | rm_work That is up to the deployer | 21:07 |
| xgerman_ | all we need is connectivity between the amps and the hm-port | 21:08 |
| cgoncalves | rm_work: it is, I believe | 21:08 |
| nmagnezi | xgerman_, and the worker as well, right? | 21:08 |
| xgerman_ | it doesn’t necessarily need to be a subnet — could also be some routable thing | 21:08 |
| xgerman_ | nmagnezi the worker needs outbound connectivity and hm inbound | 21:09 |
| cgoncalves | the suggested approach in LF/storyboard is to put o-hm0 in a seperate namespace and find another way (not relying on the deplpoyment tool) to create it | 21:09 |
| johnsom | Right, this is fully routable, so it does not need to be L2 at all | 21:09 |
| xgerman_ | should have been ore precise | 21:09 |
| xgerman_ | more | 21:09 |
| cgoncalves | so, perhaps os-vif could be something we could explore | 21:09 |
| johnsom | cgoncalves Tell me more? | 21:10 |
| xgerman_ | yes - but you also need to run it inot a neuwron network | 21:10 |
| xgerman_ | so unless you have flat there a vif won’t solve all your problems | 21:10 |
| johnsom | I can think of at least five options for how to implement this network. | 21:11 |
| xgerman_ | yep | 21:11 |
| cgoncalves | johnsom: long story short: os-vif could handle port creation on the host plus being vendor-agnostic | 21:11 |
| johnsom | All of which need to go into an install guide whenever we get time to write it. | 21:12 |
| xgerman_ | and the network the hm connects to and the one the vm connect to are separate problems (and you cna bridge them together if needed) | 21:12 |
| cgoncalves | the deployer selects the network driver (same as the one setup in ml2, for instance) and os-vif would handle it | 21:12 |
| johnsom | cgoncalves Can you go into detail on how that would work? | 21:12 |
| cgoncalves | I'm still quite in early phase exploring it, so be easy on me :) | 21:12 |
| cgoncalves | johnsom: os-vif user API consists only on 2 funcs: plug and unplug | 21:13 |
| nmagnezi | johnsom, from what I know, Nova uses os-vif for plugging stuff as well | 21:13 |
| cgoncalves | nmagnezi: yes | 21:13 |
| xgerman_ | nut you can also do a neutron net-create —provider flat:oct or so | 21:13 |
| johnsom | Right for nova instance, but this is not necessarily a nova instance, or even a host with neutron on it | 21:14 |
| xgerman_ | yep, we need a real network - not. aneutron one | 21:14 |
| cgoncalves | right, even though os-vif docs mention instance as being a nova instance I couldn't find any strict relationship with nova | 21:14 |
| cgoncalves | so could be literally any resource you want | 21:14 |
| cgoncalves | https://docs.openstack.org/os-vif/latest/user/usage.html | 21:15 |
| cgoncalves | https://docs.openstack.org/os-vif/latest/user/vif-types.html | 21:15 |
| johnsom | Basically our devstack plugin is simulating the controller having a physical nic plugged into a switch that has a VLAN for the lb-mgmt-net. It's just a simple setup for devstack. | 21:16 |
| xgerman_ | mmh, so you would do hm->vif->ovs->amp | 21:16 |
| cgoncalves | one thing missing in os-vif is namespace aware | 21:16 |
| xgerman_ | and then you hope ovs will tunnel that to the other hosts? | 21:17 |
| xgerman_ | cgoncalves: you can always add another bridge | 21:17 |
| *** threestrands has joined #openstack-lbaas | 21:18 | |
| *** threestrands has quit IRC | 21:18 | |
| *** threestrands has joined #openstack-lbaas | 21:18 | |
| cgoncalves | if you create a neutron port and then feed the details to os-vif it should configure the vif to be on the same net | 21:18 |
| *** sshank has joined #openstack-lbaas | 21:18 | |
| cgoncalves | I just wanted to bring this topic to your attention at this point and get your thoughts about the current approach vs next-gen if agreed it's the way to move forward | 21:19 |
| xgerman_ | it’s now what I am using but it sounds feasible… so yeah, let us kn ow if it works ;-) | 21:19 |
| cgoncalves | will do! | 21:20 |
| nmagnezi | cgoncalves, tripleO will eventually deploy each Octavia service in it's own container. so maybe the fact that os-vif is not network namespace aware is not that of an issue | 21:20 |
| xgerman_ | I am quite happy with vlan or whatever topology the DC has | 21:20 |
| cgoncalves | nmagnezi: true, though is still deployment tool constraint | 21:20 |
| xgerman_ | yeah, os_vif might let you bypass the need for an extra VLan | 21:20 |
| johnsom | I just don't understand what os-vif brings. It's essentially just a library doing the same thing our plugin script is doing. The downside is it expects OVS and the neutron network to exist on all of the control plane hosts/containers. | 21:20 |
| cgoncalves | if one deploys with devstack he would get the same problem, no? | 21:21 |
| xgerman_ | johnsom: my understanding is you could save the extra vlan by plugging straight i ti ovs and let it do the tunneling | 21:21 |
| xgerman_ | cgoncalves: in my AIO deploys I simulate a provide rnet with an extra (linux) bridge | 21:22 |
| johnsom | No | 21:22 |
| johnsom | os_vif doesn't do any magic tunneling | 21:23 |
| johnsom | OVN can do things like that, but this is purely creating a bridge into an OVS or linux bridge. | 21:23 |
| nmagnezi | it doesn't. but it allows you to interact with an interface driver that does | 21:23 |
| nmagnezi | such as ovs | 21:23 |
| cgoncalves | it can handle bridging and tunneling. at least there are parameters for those | 21:23 |
| cgoncalves | nmagnezi: right | 21:23 |
| johnsom | From what I have seen of it, it is exactly the same as our plugin.sh script, just abstracted and pythony | 21:24 |
| nmagnezi | johnsom, and not hard coded to ovs. which is important.. | 21:24 |
| cgoncalves | right, which is good because of a) abstraction and b) deployment tool agnostic | 21:25 |
| johnsom | Oh, as requires a nove instance, but that isn't clear I guess | 21:25 |
| cgoncalves | johnsom: it does not require nova instance | 21:25 |
| johnsom | Well, our plugin.sh isn't hard coded to OVS either, it supports linux bridge | 21:25 |
| cgoncalves | johnsom: the instance object contains: uuid, name, project_id. even though doc mentions nova instances, there's no real constraint on nova | 21:26 |
| johnsom | cgoncalves So what do you put in for vif_objects.InstanceInfo.uuid then? | 21:26 |
| nmagnezi | yup. that's actually true (forgot about that). but we'll also gain the option to support 3rd party interface drivers | 21:26 |
| nmagnezi | which neutron do allow | 21:26 |
| cgoncalves | johnsom: whatever you want? :) o-hm id? :) | 21:26 |
| *** gcheresh has quit IRC | 21:26 | |
| johnsom | I think you need to spend some more time with that code. All of my interactions say that will fail, but I have also not spent time with it. | 21:29 |
| cgoncalves | sure. I need to put more time on it | 21:29 |
| johnsom | I mean if you want no vlans setup a vxlan neutron network and tunnel it into your controllers. | 21:30 |
| cgoncalves | again, wanted initially to get an ack from devs about the mentioned issues | 21:30 |
| johnsom | Is what you are trying to solve that you install the control plane package and it automatically connects out to the lb-mgmt-net? | 21:30 |
| cgoncalves | yes | 21:31 |
| johnsom | We have to configs in place for devstack, neither of which are right for a deployment or production. Everyone does it differently, some setup provider nets, some install on neutron nodes and bridge, some setup vxlan tunnels, some just do routing, etc. | 21:32 |
| cgoncalves | the health manager service would init os-vif and request the plugging | 21:32 |
| johnsom | Some run IPv4, some IPv6 | 21:33 |
| johnsom | So, the first step towards your goal would be figuring out the discovery part. Where is the lb-mgmt-net and how is it accessible. VPN, vxlan, vlan, routing, local bridge to neutron/ovs/ovn, etc. | 21:34 |
| cgoncalves | allow me to explore a bit more and present my findings a little bit clear | 21:34 |
| johnsom | Ok | 21:34 |
| nmagnezi | it's almost midnight here. calling it a day :) | 21:34 |
| johnsom | o/ | 21:34 |
| nmagnezi | cgoncalves, we'll sync tomorrow | 21:34 |
| cgoncalves | nmagnezi: alright | 21:34 |
| cgoncalves | thanks everyone! | 21:34 |
| nmagnezi | johnsom, thank you for taking the time. I'll catch up on this. | 21:34 |
| johnsom | Sorry, I'm not trying to be argumentative, I just think there are details missing here. so trying to find answers | 21:35 |
| nmagnezi | no! don't stop because of me :D | 21:35 |
| cgoncalves | I also need to actually xD | 21:35 |
| nmagnezi | hah | 21:35 |
| openstackgerrit | Hengqing Hu proposed openstack/octavia master: Add element and flag to disable DHCP on amp images https://review.openstack.org/520590 | 21:35 |
| nmagnezi | johnsom, would a spec make sense here? | 21:35 |
| nmagnezi | or are we even before that stage in this point | 21:36 |
| cgoncalves | nmagnezi: I would think so, but first would like to present something less "formal" | 21:36 |
| johnsom | Might be early for that, but a detailed spec could help | 21:36 |
| xgerman_ | +1 | 21:37 |
| *** longstaff has quit IRC | 21:50 | |
| *** longstaff has joined #openstack-lbaas | 21:53 | |
| *** AlexeyAbashkin has joined #openstack-lbaas | 21:54 | |
| *** AlexeyAbashkin has quit IRC | 21:58 | |
| *** rcernin has joined #openstack-lbaas | 22:00 | |
| *** alex_staf_1 has quit IRC | 22:14 | |
| *** bar_ has joined #openstack-lbaas | 22:15 | |
| *** sshank has quit IRC | 22:23 | |
| *** sshank has joined #openstack-lbaas | 22:23 | |
| *** ssmith has joined #openstack-lbaas | 22:24 | |
| rm_work | augh another rebase time | 22:44 |
| rm_work | i think... | 22:45 |
| rm_work | hmmm | 22:45 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: WIP: Floating IP Network Driver (spans L3s) https://review.openstack.org/435612 | 22:46 |
| rm_work | maybe not but this makes very little sense to me | 22:46 |
| *** harlowja has quit IRC | 22:54 | |
| *** longstaff has quit IRC | 22:59 | |
| *** alex_staf_1 has joined #openstack-lbaas | 23:16 | |
| *** sshank has quit IRC | 23:17 | |
| *** yuanying has joined #openstack-lbaas | 23:18 | |
| *** alex_staf_1 has quit IRC | 23:20 | |
| rm_work | ahhhhhhhhhhh lame | 23:27 |
| rm_work | someone did not do a copy right | 23:27 |
| rm_work | damnit blogan | 23:28 |
| bar_ | rm_work, what's wrong? | 23:28 |
| rm_work | was wondering how i got a random failure | 23:28 |
| *** sshank has joined #openstack-lbaas | 23:28 | |
| rm_work | one test is altering the test constants | 23:28 |
| rm_work | so other tests that use them break | 23:28 |
| bar_ | rm_work, can you please share a link? | 23:29 |
| rm_work | let me see... | 23:29 |
| bar_ | I wonder whether that patch has got into one of my patches | 23:30 |
| bar_ | *that test got into | 23:30 |
| rm_work | https://github.com/openstack/octavia/blob/master/octavia/tests/unit/network/drivers/neutron/test_allowed_address_pairs.py#L408-L411 | 23:30 |
| rm_work | it's been in there for a long time | 23:30 |
| rm_work | but we weren't using those fields until recently | 23:30 |
| rm_work | now that we check for them... this is a problem | 23:31 |
| rm_work | it should be copy.deepcopy | 23:31 |
| rm_work | because it's just a wrapper dict... so just a "copy" | 23:31 |
| rm_work | doesn't do much | 23:31 |
| rm_work | basically nothing in fact :P | 23:31 |
| bar_ | yeah, I got exactly the same error (here: https://review.openstack.org/#/c/505158/), but only with py27, not py35. any thoughts of why? | 23:32 |
| bar_ | rm_work, Do you want me to patch it? | 23:35 |
| rm_work | it has to do with run order | 23:35 |
| rm_work | it's random | 23:35 |
| rm_work | so not consistent | 23:35 |
| rm_work | i patched it in my patch | 23:35 |
| rm_work | you're welcome to patch it in yours too | 23:35 |
| rm_work | one of them will land | 23:35 |
| rm_work | and it's a pretty straightforward rebase :P | 23:35 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: Add unit tests for neutron utils, add model/util for floating_ip https://review.openstack.org/525353 | 23:36 |
| openstackgerrit | Adam Harwell proposed openstack/octavia master: WIP: Floating IP Network Driver (spans L3s) https://review.openstack.org/435612 | 23:36 |
| *** tongl has quit IRC | 23:39 | |
| *** tongl has joined #openstack-lbaas | 23:40 | |
| *** harlowja has joined #openstack-lbaas | 23:42 | |
| *** armax has quit IRC | 23:44 | |
| openstackgerrit | Bar RH proposed openstack/octavia master: Improve Neutron driver _get_resource() https://review.openstack.org/527199 | 23:46 |
| rm_work | i'm still +2 | 23:50 |
| bar_ | rm_work, thx! | 23:50 |
| rm_work | still would appreciate reviews on https://review.openstack.org/#/c/525778/ | 23:50 |
| rm_work | would ideally like to get that merged | 23:50 |
| rm_work | although actually might tweak it a tiny bit <_< | 23:51 |
| *** tongl has quit IRC | 23:53 | |
| *** longstaff has joined #openstack-lbaas | 23:56 | |
| *** fnaval has quit IRC | 23:57 | |
| bar_ | rm_work, I've been eyeing it for a while. The relate patch, Floating IP Network Driver, seems quite big. Did you think of dividing it to even more patches? | 23:58 |
| rm_work | i don't intend that to merge even close to now | 23:58 |
| rm_work | that's Work In Progress | 23:58 |
| rm_work | and it's what we use downstream | 23:58 |
| rm_work | you can safely ignore that patch | 23:58 |
| bar_ | ah | 23:58 |
| rm_work | I just put it up in case anyone wants to look | 23:59 |
| *** tongl has joined #openstack-lbaas | 23:59 | |
| rm_work | and it makes my process easier | 23:59 |
| rm_work | that's the driver we run internally right now | 23:59 |
| rm_work | it *works*, but only in our specific cloud | 23:59 |
| bar_ | right | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!