Friday, 2020-07-31

*** armax has quit IRC00:02
*** yasufum has joined #openstack-meeting00:29
*** rfolco has quit IRC00:29
*** hyunsikyang__ has joined #openstack-meeting01:08
*** hyunsikyang has quit IRC01:12
*** yaawang has quit IRC01:26
*** armax has joined #openstack-meeting01:28
*** yaawang has joined #openstack-meeting01:28
*** gyee has quit IRC01:44
*** yaawang has quit IRC01:53
*** yaawang has joined #openstack-meeting01:53
*** manuvakery has joined #openstack-meeting02:31
*** diurnalist has quit IRC02:33
*** yaawang has quit IRC02:36
*** yaawang has joined #openstack-meeting02:37
*** armax has quit IRC02:51
*** tetsuro has quit IRC03:13
*** whoami-rajat has joined #openstack-meeting03:15
*** yasufum has quit IRC03:20
*** yaawang has quit IRC03:25
*** yaawang has joined #openstack-meeting03:26
*** rcernin has quit IRC03:29
*** rcernin has joined #openstack-meeting03:41
*** rh-jelabarre has quit IRC03:52
*** rcernin has quit IRC03:58
*** yasufum has joined #openstack-meeting03:59
*** rcernin has joined #openstack-meeting04:15
*** diurnalist has joined #openstack-meeting04:21
*** psahoo has joined #openstack-meeting04:30
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-meeting04:33
*** manuvakery has quit IRC04:40
*** vishalmanchanda has joined #openstack-meeting04:40
*** redrobot has quit IRC05:17
*** markvoelker has joined #openstack-meeting05:19
*** markvoelker has quit IRC05:23
*** markvoelker has joined #openstack-meeting05:26
*** markvoelker has quit IRC05:30
*** diurnalist has quit IRC05:34
*** psahoo has quit IRC05:41
*** psahoo has joined #openstack-meeting05:54
*** psahoo has quit IRC06:03
*** lpetrut has joined #openstack-meeting06:10
*** psahoo has joined #openstack-meeting06:17
*** maciejjozefczyk has joined #openstack-meeting06:48
*** dklyle has quit IRC06:59
*** slaweq has joined #openstack-meeting07:02
*** manpreet has joined #openstack-meeting07:04
*** tosky has joined #openstack-meeting07:19
*** ralonsoh has joined #openstack-meeting07:33
*** maciejjozefczyk has quit IRC07:35
*** ociuhandu has quit IRC07:44
*** ociuhandu has joined #openstack-meeting08:00
*** ianw has quit IRC08:01
*** ianw has joined #openstack-meeting08:02
*** ociuhandu has quit IRC08:03
*** ociuhandu has joined #openstack-meeting08:03
*** maciejjozefczyk has joined #openstack-meeting08:11
*** Lucas_Gray has joined #openstack-meeting08:43
*** e0ne has joined #openstack-meeting08:55
*** maciejjozefczyk has quit IRC09:03
*** yasufum has quit IRC10:09
*** Lucas_Gray has quit IRC10:10
*** lpetrut has quit IRC10:17
*** moguimar has joined #openstack-meeting10:20
*** Lucas_Gray has joined #openstack-meeting10:24
*** rcernin has quit IRC10:33
*** maciejjozefczyk has joined #openstack-meeting10:37
*** markvoelker has joined #openstack-meeting10:41
*** markvoelker has quit IRC10:46
*** lpetrut has joined #openstack-meeting10:51
*** zbr is now known as zbr|pto10:56
*** moguimar has quit IRC11:02
*** ociuhandu_ has joined #openstack-meeting11:03
*** jmasud has quit IRC11:04
*** masahito has joined #openstack-meeting11:07
*** ociuhandu has quit IRC11:08
*** raildo has joined #openstack-meeting11:11
*** moguimar has joined #openstack-meeting11:54
*** lbragstad_ has joined #openstack-meeting12:00
*** lbragstad has quit IRC12:03
*** Lucas_Gray has quit IRC12:12
*** rh-jelabarre has joined #openstack-meeting12:14
*** rfolco has joined #openstack-meeting12:24
*** yamamoto has joined #openstack-meeting12:24
*** ykatabam has quit IRC12:28
*** eharney has joined #openstack-meeting12:36
*** Lucas_Gray has joined #openstack-meeting12:46
*** ociuhandu_ has quit IRC13:23
*** ociuhandu has joined #openstack-meeting13:24
*** TrevorV has joined #openstack-meeting13:33
*** sluna has quit IRC13:38
*** sluna has joined #openstack-meeting13:38
*** rafaelweingartne has joined #openstack-meeting13:57
slaweq#startmeeting neutron_drivers14:00
openstackMeeting started Fri Jul 31 14:00:34 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
*** openstack changes topic to " (Meeting topic: neutron_drivers)"14:00
openstackThe meeting name has been set to 'neutron_drivers'14:00
*** ZhuXiaoYu has joined #openstack-meeting14:00
amotokihi, but I had a virtual drinking with my team, so I might be optional today. I will try my best.14:01
slaweqI know that haleyb is on PTO this week and mlavalle will probably not be here today14:02
slaweqbut we have quorum so lets start14:02
slaweq#topic RFEs14:02
*** openstack changes topic to "RFEs (Meeting topic: neutron_drivers)"14:02
slaweqfirst one:14:02
openstackLaunchpad bug 1880532 in neutron "[RFE]L3 Router should support ECMP" [Wishlist,New] - Assigned to XiaoYu Zhu (honglan0914)14:02
*** mlavalle has joined #openstack-meeting14:03
slaweqwe already talked about it few times14:03
*** ZhuJoseph has joined #openstack-meeting14:03
slaweqand reporter checked that it can be done with existing API only, using extraroutes attribute of the router14:03
slaweqhi mlavalle :)14:04
*** ZhuXiaoYu has quit IRC14:05
*** diurnalist has joined #openstack-meeting14:06
slaweqso for me this proposal looks ok now, and if we don't need to change API (or only do some very small changes, than it's fine for me)14:06
*** lpetrut has quit IRC14:06
njohnstonI feel similarly14:07
yamamotofine for me14:08
mlavalleAgree. Went thorugh it last week and came to the same conclusion14:08
amotokiGenerally looks good. I wonder whether we need to update the description of the API behavior, thought?14:10
ralonsohok for me, I still need to review the uploaded patch14:10
slaweqamotoki: yes, that's are small changes which I think will be needed14:11
slaweqthx all for votes, I will mark it as approved, and please also review proposed spec :)14:11
amotokiyeah, it is a reasonable improvement14:12
slaweqok, so next one14:12
openstackLaunchpad bug 1889431 in neutron "[RFE] Add local-ip-prefix to Neutron metering label rules" [Wishlist,In progress] - Assigned to Rafael Weingartner (rafaelweingartner)14:12
slaweqwith that one I have small problem14:13
*** ZhuJoseph has quit IRC14:13
slaweqit seems reasonable and valid change but from the other hand it will be backward incompatible14:13
slaweqof course we may add new api extension to make it discoverable14:13
rafaelweingartneto be fair, the commit cited there in [1] also broke it. And the documentation was not updated accordingly; this leads people to think that there is a bug with the current code. just when looking at the storyline, we see that it was changed on purpose.14:15
slaweqyes, that's true14:16
rafaelweingartneThat is why we proposed a migration plan for people using the current code base. I agree with you though, we would be breaking API compatibility.14:17
ralonsohbut what's the problem of adding an extension here?14:18
ralonsohto the current API14:19
slaweqralonsoh: no problem for me14:19
ralonsohah ok14:19
rafaelweingartneWhat do you guys mean by API extension?14:19
njohnstonThere certainly does seem to be a legitimate case for this, and with discoverability I am totally OK with this.14:19
slaweqjust wanted to mention that we need api extension to make it discoverable14:19
rafaelweingartneis it like microversioning in Cinder?14:20
ralonsohrafaelweingartne, something like this
patchbotpatch 740058 - neutron-lib - New api-def: port-numa-affinity-policy - 6 patch sets14:20
ralonsohwhen slaweq said "discoverable", that means you enable this extension and the API contains this new parameter14:20
ralonsohthat won't break the current code14:20
amotokirafaelweingartne: yes, neutron does not introduce microversioning and a new feature needs to be discovered by an API extension14:21
rafaelweingartnewell, that is the problem14:21
rafaelweingartnebecause we introduce a new parameter14:21
ralonsohand that's ok14:21
rafaelweingartnebut this new parameter will take the role/behavior of the old one14:21
ralonsohbut referred to a new extension14:21
ralonsohwe can discuss the technical issues in the n-lib patch14:22
amotokiwhat I am not sure so far is whether how we should interprete "lcoal" now.14:22
slaweqrafaelweingartne: this isn't a problem for sure, You will add this new parameter in new extension and that's fine14:22
rafaelweingartneI am not sure with these details in some of openstack components14:22
slaweqrafaelweingartne: if you will need help with that, we can discuss it on neutron channel :)14:22
amotokiThe problem description says that we changed the interpretation of "local"/"remote" at some time.14:23
slaweqamotoki: that's good point14:23
rafaelweingartneyes, here:
slaweqwouldn't "source" and "destination" better names?14:23
rafaelweingartnegood point :)14:23
rafaelweingartneinternally, I proposed source14:23
rafaelweingartnebut the network engineers said that it would make more sense local...14:24
rafaelweingartneI am not sure though, which one is better14:24
amotokiwhat is the real problem? what is "local"?14:25
rafaelweingartnelocal_ip_prefix would be the internal network behind the router14:25
slaweqamotoki: in fact when I'm now thinking about it, it depends on "direction" really14:25
rafaelweingartneyes and no14:25
njohnstonsource and dest are directional attributes, whereas local and remote are proximal attributes14:26
amotokiIIRC the commit clarifies the meaining of "remote" was different from other context in neutron. "remote" is external, soI  think  the commit is right.14:26
rafaelweingartnethe commit in [1] is using the remote attribute as the source/local IP of the VMs inside openstack14:27
rafaelweingartnethis creates confusions14:27
rafaelweingartnepeople were using the remote attribute as the remote (IP outside openstack)14:27
amotokisounds fair. I cannot remember the whole discussion at that time.14:29
rafaelweingartneand also, with respect to inflow and outflow, we wrote a section describind that "Neutron Metering agent changes"14:29
slaweqok, so local/remote will be from the "vm" point of view - local is vm IP address and remote is something in outside world, right?14:29
slaweqthat sounds good for me14:30
rafaelweingartneand by having these two attributes we can address the need described in [1], and many others14:30
slaweqand now it's not like that as remote_ip_prefix is in fact IP which belongs to the OpenStack vm14:30
slaweqthat's why You want to change this naming convention and not only add new parameter14:31
slaweqnow it seems clear for me14:31
ralonsohthat's perfect if this is also documented14:32
rafaelweingartneyes, it will be14:32
rafaelweingartnesame standard as I did with the granular extension for the neutron metering14:33
amotokiI agree with the confusion discussed so far. the question now looks like whether we need to change the current interpretation in addtion to a new proposed field.14:33
amotokiChanging the existing behavior will introduce another confusion, so we might be conservative.14:33
slaweqamotoki: I think so as currently "remote_ip_prefix" is in fact used as local IP (belongs to OpenStack vm)14:34
amotokislaweq: I think so too14:34
rafaelweingartneI would say so, otherwise, confusions would still be created by using something called "remote_IP" to indicate an IP inside OpenStack where these rules are applied14:34
amotokiI now wonder how we can achieve this without breaking existing users....14:36
njohnstonone way would be to create new names - let's say we use 'cloud_ip_prefix' and 'external_ip_prefix' - and deprecate remote_ip_prefix in the docs, while mapping it to cloud_ip_prefix internally14:38
*** ykatabam has joined #openstack-meeting14:39
slaweqnjohnston: good point, maybe it could also be "internal_ip_prefix" and "external_ip_prefix"14:39
slaweqbut will that be clear for people?14:39
rafaelweingartnethat would work, but the pseudo bug would still exist, the remote_ip_prefix would need proper documentation and deprecation14:39
amotokiyeah, it will be the best way when we have a wrong/confusing naming.14:39
rafaelweingartnecant this create more confusions? having external and remote attributes?14:39
rafaelweingartneat the same time14:40
amotokirafaelweingartne: doesn't the RFE propose to change the meaning of 'remote'? am I wrong?14:40
rafaelweingartneI mean, it depends on the perspective. The remote would start to fulfill its claim (being the remote IP)14:41
rafaelweingartneinstead of the internal/loca/vmIP14:41
amotokiwhat we are wonder is how we won't break existing API users when we change the API behavior. Of course we need to clarify what the new terms mean.14:42
rafaelweingartneyes, and that is a good point14:42
rafaelweingartneHow was the change introduced via [1] handled? That also changed the way API was being used and broke compatibility.14:42
amotokiI believe that was not a good example.14:42
rafaelweingartneI see14:43
njohnstonI think that remote_ip is tainted by the fact that we have to maintain API compatibility with an implementation that has the opposite meaning of the name.  I think replacing and deprecating it - and making a special note in the API ref - is the best path.14:44
*** diurnalist has quit IRC14:44
*** Lucas_Gray has quit IRC14:44
njohnstonPerhaps 'cloud_ip" for the local and "peer_ip" for the remote would work, as they don't frame the sides in terms of an assumed reference point of the user.14:44
rafaelweingartneok, so I will need to add that into my proposal then, right?14:44
amotokinjohnston: agree (but I need double check after the meeting)14:45
slaweqnjohnston: amotoki I like that proposal14:46
slaweqthat way we will not break any existing users and their applications14:46
slaweqand we will improve our API14:46
amotokirafaelweingartne: I think so. we are reverting the meaning of the field twice. It should be avoided in general, so it is better to be covered in the context.14:46
rafaelweingartneok, I will do that then14:46
slaweqso I'm ok to approve this rfe with the note that it should add new attributes, and just deprecate the existing one but not remove or change it's behaviour14:48
mlavalleseems reasonable to me14:48
slaweqare others ok too?14:48
amotokisounds good14:48
rafaelweingartneThank you guys14:48
slaweqyamamoto: any thoughts?14:49
amotokirafaelweingartne: thanks for taking care of this complicated one.14:49
yamamotoi'd like to abstain as i'm just confused :-)14:49
slaweqbut as we have most people +1 about it, I will mark it as approved14:50
slaweqrafaelweingartne: please propose spec with detailed description of the current status and proposed changes (api especially)14:51
rafaelweingartnesure, I will do14:51
slaweqthx a lot14:51
slaweqand thx for the new proposal :)14:51
slaweqok, lets move on14:51
slaweqthere is third one for today14:51
openstackLaunchpad bug 1888487 in neutron "Change the default value of "propagate_uplink_status" to True" [Wishlist,New] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)14:51
slaweqfrom ralonsoh14:51
ralonsohvery quick14:51
ralonsohthis extension, "propagate_uplink_status", allows to propagate the PF status to the VF, in SRIOV14:52
ralonsoh(that's only for SRIOV)14:52
ralonsohby default, the VF status will be set to enabled/disables14:52
ralonsohwith this extension and the paremeter to True, the link status will be auto14:52
ralonsohmy proposal: when this extension is enabled14:53
slaweq"propagate_uplink_status" is port's parameter in API, right?14:53
ralonsohset "propagate_uplink_status" to True by default --> set link status to auto14:53
ralonsohby default now is False14:53
ralonsohI want to change that14:53
slaweqand You want to basically change default value of this attribute, right?14:53
*** diurnalist has joined #openstack-meeting14:53
ralonsohI know could sound trivial, but is a change in a default parameter14:54
ralonsohreason: customers enabling this extension want to have VF link status to auto14:54
*** Lucas_Gray has joined #openstack-meeting14:55
ralonsohwith this parameter set to True, they don't need to change nothing in the port creation14:55
ralonsoh*change anything14:55
njohnstonI am +1 on this because I think it is very unusual for a user to actually desire the behavior that we currently have as the default14:56
*** rafaelweingartne has quit IRC14:56
slaweqand by default this extension isn't enabled so users who don't want to use "auto" don't have this extension loaded probably14:56
slaweqI'm ok to change that14:57
slaweqof course with "big" release note about the change :)14:57
amotokisounds reasonable to me too so far.14:57
ralonsohthank you all14:58
*** lbragstad_ is now known as lbragstad14:58
amotokido we introduce a new extension?14:58
slaweqok, sounds like we can approve it :)14:58
slaweqamotoki: I'm not sure if we need that in this case TBH14:59
*** dklyle has joined #openstack-meeting14:59
*** masahito has quit IRC14:59
slaweqamotoki: but we can discuss it in the review of the patch probably14:59
slaweqok for You?14:59
amotokislaweq: I am okay14:59
amotokithis is really a gray zone14:59
slaweqwe are running out of time now15:00
slaweqthx for attending the meeting15:00
njohnstonvery productive meeting!  thanks all15:00
slaweqhave a great weekend15:00
yamamotogood night15:00
*** openstack changes topic to "OpenStack Meetings ||"15:00
openstackMeeting ended Fri Jul 31 15:00:22 2020 UTC.  Information about MeetBot at . (v 0.1.4)15:00
openstackMinutes (text):
*** ykatabam has quit IRC15:09
*** yamamoto has quit IRC15:18
*** whoami-rajat has quit IRC15:21
*** armax has joined #openstack-meeting15:33
*** Guest82019 has joined #openstack-meeting15:35
*** bnemec is now known as beekneemech15:35
*** Guest82019 is now known as redrobot15:37
*** jmasud has joined #openstack-meeting15:42
*** maciejjozefczyk has quit IRC15:45
*** ociuhandu has quit IRC15:55
*** psahoo has quit IRC15:56
*** irclogbot_0 has quit IRC15:56
*** irclogbot_1 has joined #openstack-meeting15:57
*** ociuhandu has joined #openstack-meeting15:59
*** ociuhandu has quit IRC16:04
*** e0ne has quit IRC16:06
*** yamamoto has joined #openstack-meeting16:06
*** ociuhandu has joined #openstack-meeting16:10
*** moguimar has quit IRC16:14
*** ociuhandu has quit IRC16:15
*** irclogbot_1 has quit IRC16:15
*** irclogbot_2 has joined #openstack-meeting16:16
*** yamamoto has quit IRC16:20
*** Lucas_Gray has quit IRC16:41
*** Lucas_Gray has joined #openstack-meeting16:43
*** maciejjozefczyk has joined #openstack-meeting17:07
*** Lucas_Gray has quit IRC17:21
*** gyee has joined #openstack-meeting17:45
*** ralonsoh has quit IRC17:52
*** yamamoto has joined #openstack-meeting18:20
*** yamamoto has quit IRC18:31
*** Liang has quit IRC18:33
*** vishalmanchanda has quit IRC18:50
*** smcginnis has quit IRC20:12
*** smcginnis has joined #openstack-meeting20:13
*** TrevorV has quit IRC20:20
*** bbowen has quit IRC20:53
*** maciejjozefczyk_ has joined #openstack-meeting20:57
*** maciejjozefczyk has quit IRC20:58
*** raildo has quit IRC21:01
*** rfolco has quit IRC21:01
*** maciejjozefczyk has joined #openstack-meeting21:02
*** yamamoto has joined #openstack-meeting21:03
*** maciejjozefczyk_ has quit IRC21:04
*** yamamoto has quit IRC21:07
*** maciejjozefczyk has quit IRC21:11
*** maciejjozefczyk_ has joined #openstack-meeting21:11
*** maciejjozefczyk_ has quit IRC21:13
*** eharney has quit IRC21:16
*** e0ne has joined #openstack-meeting21:47
*** beekneemech is now known as bnemec-pto21:48
*** bbowen has joined #openstack-meeting22:09
*** tosky has quit IRC22:10
*** slaweq has quit IRC22:17
*** e0ne has quit IRC22:20
*** e0ne has joined #openstack-meeting22:25
*** slaweq has joined #openstack-meeting22:30
*** yamamoto has joined #openstack-meeting22:46
*** e0ne has quit IRC22:48
*** _erlon_ has quit IRC22:49
*** yamamoto has quit IRC23:18
*** diurnalist has quit IRC23:30
*** armax has quit IRC23:40

Generated by 2.17.2 by Marius Gedminas - find it at!