16:03:40 <cgoncalves> #startmeeting Octavia
16:03:41 <openstack> Meeting started Wed Oct  2 16:03:40 2019 UTC and is due to finish in 60 minutes.  The chair is cgoncalves. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:44 <openstack> The meeting name has been set to 'octavia'
16:03:45 <rm_work> o/
16:03:47 <cgoncalves> hi
16:04:23 <ajay33> hi
16:04:28 <cgoncalves> apologies we started the meeting a bit late
16:04:36 <cgoncalves> #topic Announcements
16:04:53 <cgoncalves> Final Train RCs due next week
16:04:58 <cgoncalves> #link https://releases.openstack.org/train/schedule.html
16:05:35 <cgoncalves> We released Octavia Train RC1 already. Please let the team know if there's a patch you would like to see it included in GA
16:05:58 <cgoncalves> Ussuri release schedule published
16:06:04 <cgoncalves> #link https://releases.openstack.org/ussuri/schedule.html
16:06:35 <cgoncalves> Ussuri release is schedule to go out mid May 2020
16:06:56 <cgoncalves> Feature freeze the week of April 6
16:07:24 <cgoncalves> this leads to last announcement I had for today:
16:07:26 <cgoncalves> Ussuri series community goal selection
16:07:31 <cgoncalves> #link https://etherpad.openstack.org/p/PVG-u-series-goals
16:08:23 <cgoncalves> at the early beginning of each development cycle, the community proposes and agrees to community goals
16:08:40 <AustinR> Requesting review of backports "loadbalancer vip-network-id IP availability" https://review.opendev.org/#/c/685447/, https://review.opendev.org/685475, https://review.opendev.org/685883
16:08:49 <cgoncalves> for example, we had PDF generation and IPv6-only support in Train
16:09:18 <cgoncalves> the community is seeking for goals for Ussuri. there are already two proposed. please see the Etherpad page
16:09:23 <cgoncalves> #link https://etherpad.openstack.org/p/PVG-u-series-goals
16:10:19 <rm_work> I like the zuulv3 goal since it's not too much work for us :D
16:10:33 <cgoncalves> I particularly like the "Switch remaining legacy jobs to Zuul v3 and drop legacy support". I think we only have one job on Zuul v2 -- the Grenade job
16:10:44 <rm_work> Jinx
16:10:59 <cgoncalves> reason being there isn't a base Zuul v3 Grenade job for us to consume
16:11:45 <cgoncalves> rm_work, so does that mean you're signing up for that goal? :D
16:12:08 <cgoncalves> this is all I had for today's announcements. anything else someone would like to add?
16:12:15 <rm_work> We'll see :D
16:12:16 <haleyb> cgoncalves: there's a grenade-py3 job in the neutron tree, don't know if it's inherited
16:13:09 <cgoncalves> haleyb, very unlikely to be a grenade Zuul v3 job. last time I checked there wasn't much progress
16:13:26 <cgoncalves> we can definitely check that in a few minutes :)
16:13:48 <cgoncalves> #topic Brief progress reports / bugs needing review
16:15:00 <cgoncalves> not much from my side to report since last week. I've been testing CentOS 8 support in diskimage-builder and built an amphora image
16:16:19 <cgoncalves> I got an issue with the 2-way auth. the amphora-agent reports it gets a bad certificate from the controller but it looks good to me. tested with an centos 7 and bionic images okay
16:17:52 <jrosser> i have been having problems with running out of space in /tmp when building bionic amphora images
16:18:38 <cgoncalves> jrosser, out of space in the build host?
16:18:41 <jrosser> like this http://paste.openstack.org/show/780558/
16:20:38 <cgoncalves> jrosser, I'm not totally sure if /var/cache/apt/archives/ refers to the build host or in the root of the amp image. what is the desired space you've requesting?
16:21:02 <cgoncalves> I mean, the value you pass to the "-s" option in diskimage-create.sh
16:21:32 <cgoncalves> 2 GB should be enough
16:21:40 <jrosser> oh well maybe that is the issue, that we don't pass that
16:22:25 <cgoncalves> in that case, for ubuntu, the default is 2GB
16:22:51 <cgoncalves> maybe we can check that after the meeting or tomorrow
16:23:05 <jrosser> ok thankyou
16:23:14 <cgoncalves> sure, no problem!
16:23:56 <cgoncalves> alright! anyone else would like to share brief progress reports or bugs needing review?
16:24:35 <cgoncalves> AustinR, we received your previous message asking to review backport patches to queens and rocky :)
16:24:54 <cgoncalves> thanks for the master patch and helping with backports!
16:25:29 <AustinR> thank you :)
16:26:30 <rm_work> Yeah in general it's good to ping people if there's patches you need looked at specifically -- I try to find time to go through and look at stuff but when you have a patch ready and are in IRC for me to talk with, I can generally prioritize :)
16:27:52 <rm_work> I've been working on some other stuff recently and trying to keep up some reviews, but I will be more focused again once Ussuri opens for features (and will be working on the multivip stuff again)
16:27:54 <cgoncalves> looks like some fine folks might have joined johnsom on his holidays :) quite calm here for the past 2 weeks :)
16:28:30 <cgoncalves> rm_work, I think master is open for Ussuri now that we branched stable/train
16:29:14 <cgoncalves> speaking of that, we might want to have this one merged: https://review.opendev.org/#/c/685905/
16:29:30 <cgoncalves> and make a Train RC2 release
16:30:17 <cgoncalves> oki, let's continue
16:30:22 <cgoncalves> #topic Open discussion
16:30:28 <colin-> on the topic of timeout values being available to set on the listener overriding websockets connections being otherwise torn down, while i acknowledge that this does have the outcome we were aiming for, it also has the unintended outcome of affecting the connection characteristics of _all_ connections going over that VIP unfortunately so it has a broader impact to the behavior of that API, which in turn has an effect on the usefulness of the resour
16:30:35 <colin-> sorry, had that teed up
16:30:45 <cgoncalves> oh, sorry!
16:32:20 <cgoncalves> colin-, not sure I follow, sorry. changing the timeout of a listener also applies the timeout to all other listeners?
16:32:46 <cgoncalves> or you want to set a different timeout to a particular listener and connection?
16:32:53 <colin-> no, to all other connections
16:33:05 <colin-> i don't want to override all connection timeouts just to accommodate a small percentage of them
16:33:14 <colin-> (not all are this long-lived websocket type conns)
16:33:57 <colin-> so it would be preferable for the values that are available today to remain at their sane defaults while offering the opportunity to accommodate these conns too
16:34:28 <cgoncalves> I see. what would you suggest? some kind of listener policy where one could define a set of rules (timeouts)?
16:35:07 <colin-> for me, it would be a natural extension of the listener create api in the same way that "timeout_member_connect" is implemented, for example
16:37:00 <cgoncalves> colin-, would you be able to open an RFE/story for this for us to better track it?
16:37:16 <colin-> will do
16:37:24 <cgoncalves> thanks!
16:38:35 <cgoncalves> if there's nothing else to discuss, we can close the meeting a few minutes early :)
16:39:11 <cgoncalves> looking forward to seeing folks at the next PTG in a month!
16:39:34 <cgoncalves> thank you having joined today's meeting
16:39:41 <cgoncalves> #endmeeting