14:00:18 <slaweq> #startmeeting networking
14:00:19 <openstack> Meeting started Tue Dec 17 14:00:18 2019 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'networking'
14:00:22 <slaweq> welcome :)
14:00:27 <njohnston> o/
14:00:31 <bcafarel> o/
14:00:38 <haleyb> \o
14:00:42 <cmurphy> o/
14:00:58 <ralonsoh> hi
14:01:15 <slaweq> ok, lets start the meeting
14:01:24 <slaweq> #topic Announcements
14:01:48 <slaweq> Reminder that we are still looking for "new daddies" for neutron-vpnaas and neutron-fwaas
14:01:58 <slaweq> I will send also reminder message to the ML this week
14:02:19 <slaweq> next one
14:02:46 <slaweq> Ussuri-1 was last week: https://releases.openstack.org/ussuri/schedule.html
14:03:07 <slaweq> now we are going to Ussuri-2 milestone which will be in February
14:03:34 <slaweq> and last announcement for today from me:
14:04:11 <slaweq> It's our last meeting in 2019 - for next weekes I will be on PTO and I think that this will be similar to many others also
14:05:03 <slaweq> so we will probably resume our meetings on 6th or 13th January
14:05:22 <bcafarel> yes attendance next 2 weeks would probably be low
14:05:26 <slaweq> I will send email about it also
14:05:26 <njohnston> +1
14:06:04 <slaweq> and that's all from me for announcements
14:06:06 <rubasov_> o/
14:06:16 <slaweq> anything else You want to share with the team?
14:07:26 <slaweq> ok, so lets move on
14:07:28 <slaweq> #topic Blueprints
14:07:41 <slaweq> list updated for Ussuri-2 is here https://launchpad.net/neutron/+milestone/ussuri-2
14:08:01 <slaweq> I think we should now focus on implementation of them :)
14:08:39 <slaweq> for 3 of them we recently released neutron-lib with needed api definitions so I hope that neutron's side will be also done soon
14:09:12 <slaweq> I would like ask all of You to review once again spec for https://blueprints.launchpad.net/neutron/+spec/metadata-over-ipv6
14:09:32 <slaweq> it's on https://review.opendev.org/#/c/315604/
14:09:46 <slaweq> I know haleyb reviewed it - thx haleyb :)
14:10:00 <haleyb> :)
14:10:27 <slaweq> haleyb: but I'm not sure if we really need to somehow "reserve" this link-local IPv6 address
14:10:46 <slaweq> as it's link-local class, isn't it safe to use it?
14:11:00 <slaweq> 169.254/16 is also link-local class in IPv4 world
14:11:46 <rubasov> I think it's as safe as 169.254/16 in ipv4
14:11:48 <amotoki> perhaps we will have similar questions when we try to support it in cloud-init.
14:11:53 <rubasov> do we need more than that?
14:12:16 <haleyb> slaweq: that's just the IETF part of my brain saying that, technically we shouldn't, but we are giving it a special meaning
14:12:32 <slaweq> rubasov: that's exactly my understanding
14:12:47 <slaweq> haleyb: do You have any contacts there, which You can ask?
14:13:04 <slaweq> or should I try to find someone?
14:14:00 <haleyb> not any more, there is a ML for IPv6, i'll find it offline
14:14:36 <slaweq> haleyb: ok, thx
14:14:50 <rubasov> and I'll cleanup our spec
14:15:03 <slaweq> any other updates about blueprints?
14:15:15 <slaweq> thx rubasov :)
14:15:40 <rubasov> slaweq: unless slaweq already did it :-)
14:15:46 <rubasov> slaweq: sorry I'm a bit behind
14:16:03 <slaweq> rubasov: no problem, I just addressed some haleyb's comments there
14:16:12 <slaweq> but You can take care of it now if You want
14:16:20 <slaweq> I just want to move forward with this :)
14:16:28 <rubasov> slaweq: you're right
14:18:09 <slaweq> if there is no any other updates about BPs, lets move on
14:18:17 <slaweq> #topic Community goals
14:18:58 <slaweq> according to Support IPv6-Only Deployments I recently revived slowly work gmann's on neutron-tempest-plugin job for stadium projects
14:19:09 <slaweq> and I found out that bagpipe isn't ready for IPv6 yet
14:19:26 <slaweq> so we have to do this job without bagpipe for now
14:19:50 <slaweq> and we have some connectivity issues in this job which I will need to figure out how to fix now
14:20:04 <slaweq> njohnston: any updates about dropping py27 support?
14:20:31 <njohnston> etherpad: https://etherpad.openstack.org/p/neutron-train-zuulv3-py27drop
14:20:59 <njohnston> not really, I think things are slow as noone wants to risk introducing a breaking change right before so many people go on PTO
14:21:04 <njohnston> I think things will resume in January
14:22:08 <bcafarel> there are few stadium changes https://review.opendev.org/#/q/status:open+topic:drop-py27-support (thanks amotoki for the reviews)
14:22:30 <njohnston> important to note that we are now in stage 2
14:22:42 <njohnston> so all projects are enabled to drop their py27 testing
14:23:03 <bcafarel> finally :)
14:23:25 <amotoki> neutron already dropped py27 support, so py27 testing in stadium projects has less value
14:23:30 <njohnston> merging code that is incompatible with py27 is still to be done carefully and with an eye to cross-project ripple effects, and IMHO not to be done gratuitously
14:23:52 <njohnston> at least until stage 3
14:23:57 <slaweq> njohnston: yes, I agree with that
14:24:15 <slaweq> especially for things like neutron-lib we shouldn't drop all compatibility code yet
14:24:21 <njohnston> +100
14:24:52 <slaweq> thx for update njohnston
14:25:05 <slaweq> I hope it will start moving faster in January :)
14:25:11 <njohnston> I am sure of it
14:25:15 <slaweq> :)
14:26:22 <slaweq> ok, lets move on
14:26:26 <slaweq> #topic Bugs
14:26:35 <slaweq> yamamoto was on bug deputy last week
14:26:47 <slaweq> his report is here: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011587.html
14:27:04 <slaweq> fortunatelly almost all of the bugs are at least in progress
14:27:20 <slaweq> we only need volunteer for https://bugs.launchpad.net/neutron/+bug/1855912
14:27:20 <openstack> Launchpad bug 1855912 in neutron "MariaDB 10.1 fails during alembic migration" [High,Confirmed]
14:27:38 <slaweq> we should switch our CI job to use MariaDB 10.3 at least
14:27:42 <ralonsoh> yes there is patch
14:27:43 <slaweq> and update documentation
14:28:00 <ralonsoh> #link https://review.opendev.org/#/c/698980/
14:28:02 <slaweq> ralonsoh: really? I didn't saw any :)
14:28:10 <ralonsoh> if ubuntu bionic and mariadb
14:28:12 <slaweq> ralonsoh: thx
14:28:23 <ralonsoh> then I try to use the newer repos in Ubuntu
14:28:34 <ralonsoh> 10.4 is working, manually tested
14:29:09 <slaweq> ralonsoh: thx
14:29:13 <ralonsoh> yw
14:29:16 <slaweq> so we will only need docs update
14:29:20 <ralonsoh> yes
14:29:29 <slaweq> can You update this LP with link to this patch also?
14:29:33 <ralonsoh> sure
14:29:40 <slaweq> thx
14:30:01 <slaweq> that's all about bugs from last week from me
14:30:08 <slaweq> any other bugs You want to talk about?
14:31:02 <njohnston> not a bug, but the version bump for hacking caused some issues that haleyb has a fix out for: https://review.opendev.org/699021
14:31:37 <slaweq> yeah, we really need this patch :)
14:31:38 <haleyb> hopefully that merges soon, recheck, recheck
14:31:42 <bcafarel> yeah :/
14:31:49 <bcafarel> it had been some times since I saw so many +2
14:31:54 <bcafarel> (and rechecks)
14:31:58 <njohnston> part of that is pinning the hacking version to an older range; I figure that in January we can revisit what it will take to get the newer version working
14:32:08 <amotoki> how about stable branches?
14:33:03 <bcafarel> change is not too large so I was thinking of backporting it by itself when it finally merges
14:33:10 <bcafarel> (we had similar strategy on a previous breakage)
14:33:29 <haleyb> we should pin if we see it, just don't know if they're affected do we?
14:33:31 <amotoki> yeah. we can also avoid pep8 failures by capping hacking<2. we don't usually cap python modules in stable branches but hacking is in blacklist in g-r.
14:33:58 <slaweq> I think we will need it in Train at least
14:33:59 <bcafarel> haleyb: train and stein are for sure
14:34:02 <slaweq> and maybe Stein
14:34:10 <slaweq> bcafarel++ thx for confirmation :)
14:34:44 <amotoki> hacking is not in u-c, so bakcport or capping is required for old branches (stein/train at least, I am not sure for rocky)
14:35:24 <haleyb> bcafarel: we might just want to pin hacking, the other part shouldn't matter, but it's pretty minor stuff
14:35:49 <haleyb> looks like it's going to fail again in master :(
14:36:15 <bcafarel> yes :(
14:36:20 <njohnston> ugh
14:36:27 <slaweq> :/
14:37:25 <slaweq> ok, lets continue
14:37:32 <slaweq> our bug deputy this week is rubasov
14:37:43 <rubasov> ack
14:37:48 <slaweq> rubasov: thx
14:37:55 <slaweq> and next week we are starting new round
14:38:13 <slaweq> we will start with mlavalle who switched with bcafarel
14:38:47 * bcafarel will remember to pay him a $beverage next time for that
14:38:50 <slaweq> :)
14:38:55 <slaweq> ok, next topic
14:38:59 <slaweq> #topic Networking OVN and ML2+OVS+DVR Convergence
14:39:18 <slaweq> ralonsoh: haleyb: any updates?
14:39:26 <slaweq> what is the progress of it?
14:39:26 <ralonsoh> a but stuck, mainly because of the CI
14:39:35 <ralonsoh> last patch was merged on friday
14:39:44 <ralonsoh> and still waiting for the CI to be fixed
14:39:58 <ralonsoh> maybe in a couple of days we'll be able to make a better update
14:40:03 <ralonsoh> FTs are working
14:40:32 <haleyb> yes, some patches waiting for CI, the octavia driver is pending
14:40:33 <ralonsoh> and we are still testing the deployment of OVN with Neutron only, without the subproject networking-ovn
14:41:01 <slaweq> ok, are those all missing patches https://review.opendev.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/neutron-ovn-merge or we will need anything else too?
14:41:05 <haleyb> https://review.opendev.org/#/c/697095/ - i asked about just dropping the stable policy flag if that's an issue in merging it
14:42:17 <ralonsoh> slaweq, hmm I don't see the FTs there
14:42:20 <ralonsoh> I'll check that
14:42:33 <ralonsoh> sorry yes https://review.opendev.org/#/c/697440/
14:42:42 <njohnston> haleyb: About that, are you planning on pulling the rocky, stein, train, versions of the plugin into the repo?
14:43:20 <njohnston> haleyb: Or are you going to say "old releases use networking-ovn" so there is no need to hold the old stable branches?
14:43:22 <slaweq> njohnston: I think that for stable branches this driver will still be in networking-ovn repo, in same way like it's with mech driver
14:43:31 <haleyb> njohnston: i hadn't thought about doing that, as the other OVN stable branches will live on
14:44:01 <njohnston> haleyb: If you aren't pulling in the old stable branches into the new repo then I think that nullifies mugsie
14:44:04 <njohnston> 's objection
14:44:40 <mugsie> njohnston: it does
14:44:52 <haleyb> \o/
14:45:05 <njohnston> mugsie: thanks!
14:45:13 <slaweq> mugsie: thx
14:45:17 <njohnston> haleyb: so I would suggest clarifying that and then things can proceed
14:45:25 <haleyb> njohnston: ack, thanks!
14:45:54 <slaweq> ok, lets move on
14:45:58 <slaweq> next topic
14:46:00 <slaweq> #topic neutron-lib
14:46:11 <slaweq> I just wanted to mention that we released 1.30 last week
14:46:37 <ralonsoh> is it too soon to ask for 1.31.1??
14:47:15 <slaweq> ralonsoh: You need it to have some new api-def released, right?
14:47:20 <ralonsoh> yes
14:47:33 <ralonsoh> but low priority
14:48:23 <slaweq> for me it would be ok, but I would like also https://review.opendev.org/#/c/695205/ to be merged
14:48:40 <ralonsoh> yes
14:48:49 <ralonsoh> this patch should be a must for next version
14:49:09 <ralonsoh> (and the dependant one https://review.opendev.org/#/c/698261/)
14:49:28 <slaweq> this one is for neutron
14:49:30 <slaweq> :)
14:49:33 <ralonsoh> I know
14:49:42 <ralonsoh> but it's important: once we have a new n-lib version
14:49:48 <slaweq> yes, I know
14:49:49 <ralonsoh> we need to merge the neutron patch
14:49:50 <slaweq> :)
14:50:11 <slaweq> ok, I will check this patch and when it will be merged, I will propose new version of neutron-lib again
14:50:19 <ralonsoh> +1
14:50:53 <slaweq> amotoki: will You be ok with this plan?
14:51:00 <amotoki> sounds fine
14:51:04 <slaweq> thx
14:51:25 <slaweq> ok, so we should be good with this one I hope
14:51:31 <slaweq> lets move to the last topic for today
14:51:33 <slaweq> #topic On Demand Agenda
14:51:38 <slaweq> cmurphy: Your turn :)
14:52:32 <cmurphy> hi o/
14:52:49 <cmurphy> i wanted to stop by to check in before the holidays now that the policy popup team is official
14:53:03 <cmurphy> #link https://governance.openstack.org/tc/reference/popup-teams.html#secure-default-policies
14:53:25 <cmurphy> i mostly wanted to discuss how this team would like to organize and track the work for this effort
14:53:35 <cmurphy> #link https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team
14:54:07 <cmurphy> we have a "progress" section in that wiki page that i'm hoping will link to each project's tracking
14:54:17 <cmurphy> could be lp bugs, storyboard stories, an etherpad...
14:55:22 <slaweq> cmurphy: I don't think mlavalle started any work on this already
14:55:30 <slaweq> cmurphy: but I will talk with him about this
14:55:53 <slaweq> and will ask him to update this progress section as soon as he will have anything created
14:56:02 <cmurphy> sure, it's still very early :)
14:56:25 <cmurphy> thanks :) and also if you have design documents like a spec or blueprint or a wiki page like the barbican team has, please update that section as well
14:56:37 <slaweq> I can also talk with him if he want to have item on agenda of our meetings to track progress here too weekly
14:56:48 <slaweq> cmurphy: sure
14:56:52 <cmurphy> ++
14:57:19 <cmurphy> let me know if you have any questions, i'll be lurking in your channel or you can ping me in #openstack-dev
14:57:34 <slaweq> ok, thx a lot
14:57:39 <cmurphy> np
14:58:17 <cmurphy> that's all i had on that
14:58:43 <slaweq> thx for comming to our meeting and for update
14:58:50 <slaweq> ok, I think we are done now
14:59:17 <slaweq> so as last thing I want to wish all of You great holidays and see You all in 2020 :)
14:59:19 <slaweq> o/
14:59:20 <bcafarel> enjoy the time off for all that take some
14:59:24 <slaweq> #endmeeting