| opendevreview | Merged openstack/neutron master: doc: Do not use dvr_snat on computes https://review.opendev.org/c/openstack/neutron/+/801503 | 05:26 |
|---|---|---|
| opendevreview | liuxie proposed openstack/neutron master: [OVN] Implement router gateway IP QoS https://review.opendev.org/c/openstack/neutron/+/749012 | 07:04 |
| *** rpittau|afk is now known as rpittau | 07:35 | |
| bcafarel | ralonsoh: hi looking at https://bugs.launchpad.net/neutron/+bug/1917487 is https://review.opendev.org/c/openstack/neutron/+/778735 worth backporting ? I don't remember if it fixed the issue completely or not (if yes we can probably update the LP) | 07:57 |
| bcafarel | the mentioned pyroute2 change was long ago so if that fix helps in master it should probably be good for many stable branches | 07:58 |
| ralonsoh | bcafarel, I think it gave some stability when creating namespaces | 07:58 |
| ralonsoh | we always had this problem in the CI | 07:58 |
| ralonsoh | I think it's worth to backport it | 07:59 |
| bcafarel | ralonsoh: ack thanks, I am on it then :) | 07:59 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/wallaby: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801880 | 08:01 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/victoria: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801881 | 08:01 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801882 | 08:02 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801882 | 08:09 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/train: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801988 | 08:11 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801882 | 08:13 |
| opendevreview | Bernard Cafarelli proposed openstack/python-neutronclient master: Set ML2/OVS backend explicitly for functional job https://review.opendev.org/c/openstack/python-neutronclient/+/801997 | 09:27 |
| viks__ | hi, when creating a port, i see a option vnic type. i.e. `VNIC type for this port (direct | direct-physical | macvtap | normal | baremetal | virtio-forwarder, default: normal)`. I'm really not sure what is the use case of each of them... i tried to google around, but did not find any related info.. So where can i get more info on these things? basically i want to understand what exactly these different option does? | 10:03 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/ussuri: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801882 | 10:56 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron stable/train: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801988 | 10:57 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM It's just a test of the tempest patch https://review.opendev.org/c/openstack/neutron/+/802008 | 11:25 |
| opendevreview | yangjianfeng proposed openstack/neutron-lib master: Adds l3-ndp-proxy extension api definition https://review.opendev.org/c/openstack/neutron-lib/+/747523 | 11:28 |
| opendevreview | yangjianfeng proposed openstack/neutron-lib master: Adds l3-ndp-proxy extension api definition https://review.opendev.org/c/openstack/neutron-lib/+/747523 | 11:33 |
| *** elvira is now known as elvira-lunch | 12:00 | |
| *** mgoddard- is now known as mgoddard | 12:18 | |
| *** elvira-lunch is now known as elvia | 12:36 | |
| *** elvia is now known as elvira | 12:36 | |
| *** ramishra_ is now known as ramishra | 12:49 | |
| slaweq | ralonsoh: if You would have few minutes, please check https://review.opendev.org/c/openstack/neutron-lib/+/747523/ | 13:26 |
| slaweq | thx in advance | 13:26 |
| slaweq | amotoki: and maybe also You can ^^ :) | 13:26 |
| ralonsoh | slaweq, I was reviewing it now | 13:27 |
| ralonsoh | I know we are going to push a new version | 13:27 |
| slaweq | ralonsoh++ thx a lot | 13:27 |
| ralonsoh | slaweq, +2. I didn't +W, waiting for more reviews | 13:32 |
| ralonsoh | if not, ping me and I'll +W it | 13:32 |
| ralonsoh | (or yourself) | 13:32 |
| slaweq | thx ralonsoh | 13:33 |
| slaweq | maybe mlavalle or amotoki will take a look at it too | 13:33 |
| ralonsoh | perfect | 13:33 |
| slaweq | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jul 23 14:00:11 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| mlavalle | o/ | 14:00 |
| slaweq | hi | 14:00 |
| slaweq | thx mlavalle for taking care of the meeting 2 weeks ago :) | 14:00 |
| mlavalle | O-) | 14:00 |
| obondarev | hi | 14:00 |
| ralonsoh | hi | 14:00 |
| mlavalle | Unluckily we didn't have quorum large enough to take care or ralonsoh's rfe | 14:01 |
| ramishra | hi | 14:01 |
| slaweq | let's see if we will have quorum today | 14:02 |
| slaweq | I know haleyb will not be here | 14:02 |
| johnsom | o/ | 14:02 |
| slaweq | but lets wait for njohnston, amotoki and yamamoto | 14:02 |
| slaweq | mlavalle: btw. can You take a look at https://review.opendev.org/c/openstack/neutron-lib/+/747523/ when You will have some time? | 14:04 |
| slaweq | thx in advance | 14:04 |
| johnsom | slaweq I am joining today to chat about the quota RFE. I think there might be a bit of confusion on it. | 14:04 |
| amotoki | hi, sorry for late | 14:04 |
| mlavalle | slaweq: will do | 14:04 |
| slaweq | johnsom: which quota rfe? | 14:04 |
| njohnston | o/ | 14:05 |
| ralonsoh | slaweq, https://bugs.launchpad.net/neutron/+bug/1936408 | 14:05 |
| johnsom | https://bugs.launchpad.net/neutron/+bug/1936408 | 14:05 |
| ralonsoh | but maybe we won't have time today | 14:05 |
| johnsom | Yeah, that one. | 14:05 |
| slaweq | johnsom: it's not on today's agenda | 14:05 |
| slaweq | but lets talk about it when we will have some time at the end | 14:05 |
| slaweq | ok? | 14:05 |
| johnsom | Ok | 14:06 |
| slaweq | ok, so lets talk about ralonsoh's rfe first | 14:06 |
| slaweq | #topic RFEs | 14:06 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1933517 | 14:06 |
| ralonsoh | thank you | 14:06 |
| ralonsoh | the link for the spec | 14:07 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-specs/+/799198 | 14:07 |
| ralonsoh | in a nuthsell | 14:07 |
| ralonsoh | what we are trying is to create a port connected to br-int | 14:07 |
| ralonsoh | and provide at the same time an ofport (in the interface) | 14:07 |
| ralonsoh | when we have a VM, the tap port is created by libvirt | 14:08 |
| ralonsoh | this is done at the end of the live-migration process | 14:08 |
| ralonsoh | with this bridge in the middle | 14:08 |
| ralonsoh | (same as with hybrid plug but with an OVS birdge) | 14:09 |
| ralonsoh | the br-int port has an interface with an ofport inmediatly assigned | 14:09 |
| ralonsoh | that triggers in OVN the port UP method | 14:09 |
| ralonsoh | that means the port is provisioned | 14:09 |
| ralonsoh | when the TAP port is connected (at the other side of this bridge) | 14:09 |
| ralonsoh | the backend is ready to continue the communication | 14:10 |
| ralonsoh | that's my summary | 14:10 |
| opendevreview | Bence Romsics proposed openstack/neutron-lib master: multi-ext-gw: api-def and api-ref https://review.opendev.org/c/openstack/neutron-lib/+/802029 | 14:10 |
| ralonsoh | any question is welcome | 14:11 |
| slaweq | I read the spec already and I'm ok with this. | 14:11 |
| ralonsoh | thank you | 14:12 |
| slaweq | I had some questions but it was already discussed in the spec | 14:12 |
| slaweq | just to clarify - You will do that only for OVN backend, at least for now | 14:12 |
| ralonsoh | right | 14:12 |
| ralonsoh | it could be extended to OVS | 14:12 |
| amotoki | does it apply to all VMs even without live migration? I think yes but it is just to clarify. | 14:12 |
| ralonsoh | but the scope is OVN now | 14:12 |
| ralonsoh | amotoki, yes, to any VM | 14:12 |
| obondarev | could ml2-ovs benefit from such plugging as well? In live-migration case (to avoid packet loss) | 14:12 |
| slaweq | and second thing - there will be no many changes in the Neutron really, most of the job will be done by os-vif, correct? | 14:12 |
| obondarev | ah, I see reply already | 14:13 |
| ralonsoh | obondarev, could be in a future, for sure | 14:13 |
| ralonsoh | slaweq, there will be | 14:13 |
| ralonsoh | because now we can send the event vif-plugged when the port is provisioned | 14:13 |
| ralonsoh | that means, when Neutron server receives the port UP event from OVN | 14:13 |
| *** rpittau is now known as rpittau|afk | 14:13 | |
| slaweq | ahh, notification... :) | 14:13 |
| ralonsoh | much better than now | 14:13 |
| slaweq | so that will really fix those notifications for OVN backend finally, right? | 14:14 |
| ralonsoh | yes, instead of sending the event when the port is updated (with migration_to in the vif details) | 14:14 |
| ralonsoh | we send it at the right moment | 14:15 |
| slaweq | ++ | 14:15 |
| njohnston | +1 for me, all the questions I had when reading the spec have been covered already | 14:15 |
| mlavalle | so, is it a question of fixing the timing of when the flows are created? | 14:16 |
| ralonsoh | exactly | 14:16 |
| ralonsoh | that's the key point here | 14:16 |
| mlavalle | so we are ready when the vm is unpaused, right? | 14:17 |
| ralonsoh | we don't now because the TAP port is not created in the dest host | 14:17 |
| ralonsoh | it is when the VM is unpaused | 14:17 |
| ralonsoh | and this is when the ofport is assigned | 14:17 |
| ralonsoh | (too late) | 14:17 |
| mlavalle | yeah, we just want to be ahead of all this | 14:17 |
| ralonsoh | exactly | 14:17 |
| amotoki | what happens for existing VMs? and what happens for live-migration for existing VMs? | 14:18 |
| ralonsoh | bad yuyu | 14:18 |
| ralonsoh | ok no | 14:18 |
| ralonsoh | if you update the server | 14:18 |
| ralonsoh | and os-vif | 14:19 |
| ralonsoh | the intermediate bridge will be created in the new VM in the dest host | 14:19 |
| ralonsoh | and, btw, this option will be configurable | 14:19 |
| ralonsoh | there is no need for a VM running now to have this bridge | 14:19 |
| ralonsoh | it is needed in the dest host | 14:19 |
| amotoki | yeah, makes sense. | 14:20 |
| amotoki | in addition, os-vif needs to handle both cases perperly when deleting ports | 14:20 |
| ralonsoh | that's a corner case... | 14:21 |
| ralonsoh | good catch | 14:21 |
| ralonsoh | I'll add this info in the os-vif patch | 14:21 |
| amotoki | no it is not a special corner case. it usually happens for existing VMs | 14:21 |
| ralonsoh | if you update the nova compute and os-vif in this host | 14:22 |
| ralonsoh | only in this acse | 14:22 |
| ralonsoh | but we usually use live-migration to move VMs to updated servers | 14:22 |
| amotoki | when we upgrade openstack only, we don't need to move VMs using live-migration | 14:23 |
| slaweq | but we have multiple port bindings, so during live-migration wouldn't this binding be changed? | 14:23 |
| slaweq | so on dest node it will already be plugged in the new way | 14:23 |
| ralonsoh | the binding doesn't change | 14:23 |
| ralonsoh | the VIF is the same | 14:23 |
| slaweq | yes, but still You will have active and inactive binding for port | 14:24 |
| slaweq | on different hosts | 14:24 |
| ralonsoh | amotoki, in any case, this is something that must be considered in the os-vif patch for sure | 14:24 |
| amotoki | ralonsoh: ack | 14:24 |
| slaweq | so one can have new details conifgured, to be plugged in own bridge, no? | 14:24 |
| ralonsoh | the binding information is the same | 14:24 |
| slaweq | ok | 14:24 |
| ralonsoh | this is an option in the os-vif library | 14:24 |
| ralonsoh | not a hybrid-plug option in vif details | 14:25 |
| ralonsoh | (as in OVS with hybrid-plug) | 14:25 |
| ralonsoh | this should be transparent | 14:25 |
| ralonsoh | (with the change in the vif-plugged event) | 14:25 |
| ralonsoh | but even the OVN QoS is the same | 14:25 |
| slaweq | I'm +1 for this RFE, as njohnston | 14:27 |
| amotoki | +1 for the RFE. | 14:28 |
| amotoki | my point on upgrade can be covered by the spec. I will add a comment to the spec. | 14:28 |
| ralonsoh | amotoki, of course and thank you | 14:29 |
| slaweq | thx amotoki | 14:29 |
| slaweq | mlavalle: what about You? Any questions/comments? | 14:29 |
| mlavalle | +1 from me as well | 14:29 |
| slaweq | thx | 14:29 |
| ralonsoh | thank you all | 14:29 |
| slaweq | so I will mark that as approved | 14:29 |
| slaweq | thx ralonsoh | 14:29 |
| slaweq | let's move on to the next one | 14:30 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1933222 | 14:30 |
| slaweq | this one was discussed on last meeting | 14:30 |
| ralonsoh | for me the RFE is valid, I had some concerns in the implementation | 14:31 |
| ralonsoh | but for sure we can address that in the patches | 14:31 |
| slaweq | personally I would like to see some detailed diagram with details how this will be implemented | 14:31 |
| ralonsoh | exactly | 14:31 |
| slaweq | but in general, I'm ok with the idea if it would be optional extension to the OVS agent | 14:32 |
| amotoki | same opinion. it is generally okay. Our previous discussion focused on clarifying the detail. the spec needs to clarify the detail. | 14:34 |
| slaweq | amotoki: yes, I think that spec is for sure needed for that one | 14:34 |
| mlavalle | +1 for clarifying during spec pahse | 14:35 |
| slaweq | njohnston: any questions/comments on that one? | 14:35 |
| amotoki | one question on testing. we have distributed version of dhcp and will have metadata. Do we want to enable them in DVR tests? | 14:36 |
| ralonsoh | we'll need new jobs, right? | 14:36 |
| amotoki | new jobs would work but I am just afraid having more jobs... | 14:37 |
| njohnston | slaweq: I am a definite +1 on the idea, but diagrams and spec discussion is a definite must for a change like this | 14:37 |
| slaweq | amotoki: I don't think we need that in the dvr job | 14:37 |
| slaweq | IMO we can enabled those features in one of the existing ovs jobs | 14:38 |
| slaweq | we have couple of them already | 14:38 |
| amotoki | okay. thanks | 14:38 |
| slaweq | but that's good point about testing :) | 14:38 |
| slaweq | so I assume that we all agreed to mark that one as approved | 14:39 |
| slaweq | and follow up in the spec now | 14:39 |
| slaweq | I will comment on it after the meeting | 14:40 |
| slaweq | now we have 3rd one: | 14:40 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1935847 | 14:40 |
| ramishra | thanks slaweq | 14:40 |
| slaweq | amotoki had some good comments there already | 14:41 |
| slaweq | and also I think that obondarev's question is very interesting | 14:41 |
| slaweq | I was also thinking about it yesterday while reading this rfe | 14:41 |
| ramishra | ironic has something similar in-tree, I've not seen any req from other services/projects | 14:42 |
| amotoki | obondarev's point is similar to my 2nd point in comment #4. | 14:42 |
| slaweq | ramishra: if ironic have it and now neutron would have it - maybe it's worth to do it as part of oslo or something like that? | 14:42 |
| obondarev | +1 | 14:43 |
| ramishra | So the intent is to make standalone neutron more usable for certain use-cases in near term | 14:43 |
| amotoki | it is not specific to neutron, so you can use an existing basic-auth middleware or develop a new one for example under oslo or outside fo openstack. | 14:43 |
| ramishra | we can probably think of having an implementation is oslo later that can be used by all projects | 14:44 |
| amotoki | ramishra: did you consider using an exisitng middleware for basic auth instead of implementing it in neutron? | 14:44 |
| amotoki | for example wsgi-basic-auth I mentioned in the comment. | 14:45 |
| slaweq | ramishra: You said that ironic have it already, can't You just import and use it in neutron's pipeline in Your use case? | 14:45 |
| slaweq | that would be fastest way to have it, no? | 14:45 |
| ramishra | amotoki: I guess the one you mentioned does not support bcrypt hash for passwords | 14:45 |
| amotoki | ramishra: okay but it does not mean we should have it in the neutron repo | 14:46 |
| slaweq | I tend to agree with amotoki here :) | 14:46 |
| ralonsoh | the idea of having it implement in oslo.middleware is interesting | 14:47 |
| ralonsoh | ironic will use it too | 14:47 |
| ramishra | IMO expecting standalone users to maintain a middleware separtely won't be big ask? | 14:47 |
| amotoki | generaly speaking, we should avoid copying implementations. if ironic already has it and it can be re-used by otherr projects, we can consider oslo | 14:47 |
| obondarev | that's what oslo is all about | 14:48 |
| amotoki | ramishra: we already uses many libraries from outside of OpenStack, so "maintain a middleware separately" is not a big risk. | 14:48 |
| ramishra | It would have been better if ironic would have proposed to oslo, but they did not in-tree | 14:49 |
| ralonsoh | oslo people are nicer than us hehehe | 14:49 |
| slaweq | ralonsoh: LOL | 14:49 |
| ramishra | not sure if they proposed to oslo | 14:49 |
| ralonsoh | if you present this idea next monday | 14:49 |
| ramishra | and was rejected | 14:50 |
| ralonsoh | the will accept if for sure | 14:50 |
| ralonsoh | you can check next monday | 14:50 |
| ralonsoh | I'll be there too | 14:50 |
| ralonsoh | at 1500 UTC | 14:50 |
| obondarev | I think ironic might thought they are the only OSt project needed it at that moment | 14:50 |
| slaweq | obondarev: but now it will be at least 2 so things have changed :) | 14:51 |
| obondarev | slaweq: right | 14:51 |
| amotoki | based on your input, at least ironic and neutron need a middleware for basic-auth, so it is a good to have it in oslo. | 14:51 |
| ramishra | OK, we can try that. But I thought for standalone services dependency external implementation or oslo should be less | 14:51 |
| amotoki | perhaps cinder standalone may use it. | 14:51 |
| obondarev | neutron already depends on oslo heavily anyway | 14:52 |
| mlavalle | yeap | 14:52 |
| amotoki | neutron standalone already depends on pyroute externally maintained (outside of OpenStack) :p | 14:52 |
| slaweq | obondarev: exactly - if You install neutron You will have oslo.middleware installed | 14:52 |
| amotoki | so I don't think one more dependency is not a matter.... | 14:53 |
| slaweq | so I'm -1 for this rfe in Neutron, it should be probably part of oslo IMO, or completly external thing | 14:53 |
| mlavalle | Agree | 14:53 |
| ramishra | As it's non-invasive middleware, IMHO having in-tree is the best thing. But I take your point, if it's to be used by other services, better keep it in neutron | 14:54 |
| amotoki | +1 as I already commented | 14:54 |
| ramishra | *keep it oslo | 14:54 |
| slaweq | ralonsoh: njohnston: any thoughts? | 14:54 |
| mlavalle | amotoki: +1 to the -1, right? | 14:54 |
| ralonsoh | +1 in oslo.middleware, -1 in Neutron | 14:54 |
| amotoki | hehe. -1 | 14:54 |
| amotoki | -1 for neutorn | 14:54 |
| slaweq | that's how I understood it too :) | 14:54 |
| njohnston | agreed with the consensus | 14:54 |
| slaweq | ok, so we are done with this one, I will comment on it after the meeting | 14:55 |
| ramishra | ok thanks folks! | 14:55 |
| slaweq | thx ramishra for discussing it with us | 14:55 |
| slaweq | ok, let's quickly discuss johnsom's rfe | 14:55 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1936408 | 14:55 |
| ralonsoh | yeah, this is mine | 14:55 |
| johnsom | ha, not mine | 14:56 |
| slaweq | ok, sorry | 14:56 |
| johnsom | I just wanted to make sure it is clear, the octavia team is not asking for this change. | 14:56 |
| ralonsoh | the point of this feature is to check the available resources when modifying the quota limits | 14:56 |
| ralonsoh | of course, this API change will be configurable | 14:56 |
| ralonsoh | the default behaviour will be the one we have now, do NOT check anything | 14:56 |
| ralonsoh | the description is easy, the problem is the implementation (but this is out of scope here, I think) | 14:57 |
| johnsom | It seemed there might be some confusion since this change was requested of octavia in addition to neutron, as we both implement the quota api in the same way. | 14:57 |
| slaweq | ralonsoh: I think You told me some day that e.g. nova behaves in the way like You are proposing now | 14:57 |
| slaweq | correct? | 14:57 |
| ralonsoh | yes | 14:57 |
| njohnston | I am wondering why this change is being requested - is this coming from the API working group to establish uniformity? | 14:57 |
| slaweq | so it seems that there are 2 "fractions" in the OpenStack | 14:57 |
| ralonsoh | but please, I'm NOT proposing any change in the current API | 14:58 |
| ralonsoh | I'm proposing make it configurable | 14:58 |
| ralonsoh | via plugin or a parameter in the CLI | 14:58 |
| slaweq | maybe we should send email and discuss it with the wider audience? to make it maybe consistent across all projects | 14:58 |
| ralonsoh | of course I'll do | 14:58 |
| slaweq | ok, we are on the top of the hour now. I think we can thing about it and get back to it on next meeting | 14:59 |
| njohnston | +1 | 14:59 |
| slaweq | btw. I will be on pto next week (again) | 14:59 |
| slaweq | mlavalle: will You be able to chair the meeting? or should I cancel it and we will meet in 2 weeks? | 15:00 |
| mlavalle | that's good. this way you will keep young and pretty for a long time | 15:00 |
| ralonsoh | hehehe | 15:00 |
| slaweq | mlavalle: LOL, sure :) | 15:00 |
| mlavalle | slaweq: yeah, I can chair the meeting | 15:00 |
| slaweq | mlavalle: ok, thx | 15:00 |
| slaweq | I will send You an email about it later tonight | 15:01 |
| slaweq | before I will leave | 15:01 |
| mlavalle | cool | 15:01 |
| slaweq | ok, thx for attending the meeting | 15:01 |
| mlavalle | with a reminder, right? | 15:01 |
| slaweq | have a great weekend | 15:01 |
| slaweq | #endmeeting | 15:01 |
| opendevmeet | Meeting ended Fri Jul 23 15:01:29 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-23-14.00.html | 15:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-23-14.00.txt | 15:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-23-14.00.log.html | 15:01 |
| mlavalle | o/ | 15:01 |
| slaweq | mlavalle: yes | 15:01 |
| ralonsoh | have a nice weekend! | 15:01 |
| johnsom | o/ | 15:01 |
| amotoki | o/ | 15:01 |
| njohnston | o/ | 15:01 |
| obondarev | o/ | 15:02 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [DVR] Set arp entries only for IPs from the correct subnet https://review.opendev.org/c/openstack/neutron/+/802037 | 15:09 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Add Health Monitor support https://review.opendev.org/c/openstack/ovn-octavia-provider/+/713253 | 15:46 |
| opendevreview | Merged openstack/neutron stable/victoria: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801881 | 16:17 |
| opendevreview | Brian Haley proposed openstack/ovn-octavia-provider stable/wallaby: Add Health Monitor support https://review.opendev.org/c/openstack/ovn-octavia-provider/+/801890 | 16:42 |
| opendevreview | Merged openstack/neutron stable/wallaby: Implement namespace creation method https://review.opendev.org/c/openstack/neutron/+/801880 | 17:17 |
| gmann | slaweq: bcafarel amotoki can either of you merge these oftc nits (proejct config chages for zuul +1 or so are merged now), it will help me to complete this migration https://review.opendev.org/c/openstack/neutron-fwaas/+/800140 https://review.opendev.org/c/openstack/networking-midonet/+/800142 https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/800141 | 19:03 |
| gmann | https://review.opendev.org/c/openstack/neutron-vpnaas/+/800145 | 19:03 |
| opendevreview | Merged openstack/neutron-fwaas master: Moving IRC network reference to OFTC https://review.opendev.org/c/openstack/neutron-fwaas/+/800140 | 19:27 |
| opendevreview | Merged openstack/networking-midonet master: Moving IRC network reference to OFTC https://review.opendev.org/c/openstack/networking-midonet/+/800142 | 19:27 |
| opendevreview | Merged openstack/neutron-fwaas-dashboard master: Moving IRC network reference to OFTC https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/800141 | 19:28 |
| slaweq | gmann: done | 19:28 |
| gmann | slaweq: thanks | 19:28 |
| opendevreview | Merged openstack/neutron-vpnaas master: Moving IRC network reference to OFTC https://review.opendev.org/c/openstack/neutron-vpnaas/+/800145 | 19:37 |
| opendevreview | Merged openstack/neutron master: use payloads for PORT and FLOATING_IP https://review.opendev.org/c/openstack/neutron/+/800604 | 21:28 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!