| opendevreview | ZhouHeng proposed openstack/neutron master: [api]adds port_forwarding id when list floatingip https://review.opendev.org/c/openstack/neutron/+/840565 | 00:46 |
|---|---|---|
| opendevreview | Merged openstack/neutron stable/xena: [OVN] Remove session check in ``update_network_postcommit`` https://review.opendev.org/c/openstack/neutron/+/854234 | 01:47 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Just test of the Centos 9 stream periodic job https://review.opendev.org/c/openstack/neutron/+/854191 | 07:21 |
| slaweq | ralonsoh lajoskatona ykarel obondarev hi, can You check https://review.opendev.org/c/openstack/neutron/+/851733 when You will have few minutes? | 07:49 |
| slaweq | thx in advance | 07:49 |
| ralonsoh | sure | 07:49 |
| lajoskatona | slaweq: yes | 07:50 |
| ykarel | ack | 07:50 |
| slaweq | thx guys | 07:50 |
| opendevreview | Merged openstack/neutron master: Allow operator to disable usage of random-fully https://review.opendev.org/c/openstack/neutron/+/854041 | 08:42 |
| lajoskatona | ralonsoh, slaweq, bcafarel: Could you please check the stein fix patches: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/853794 & https://review.opendev.org/c/openstack/neutron/+/853608 | 08:51 |
| ralonsoh | sure, let me check | 08:51 |
| bcafarel | lajoskatona: sure thing! | 08:51 |
| lajoskatona | ralonsoh, slaweq, bcafarel: the devstack fix/backport from slaweq is merged | 08:51 |
| bcafarel | lajoskatona: just a nit on DNM test comment https://review.opendev.org/c/openstack/neutron/+/853608/8/neutron/common/constants.py#16 else nice to see zuul happy with it! | 08:57 |
| slaweq | lajoskatona please address bcafarel | 09:00 |
| slaweq | *bcafarel's comment and I will +2 Your neutron patch :) | 09:00 |
| opendevreview | Gregory Thiemonge proposed openstack/ovn-octavia-provider master: Fix create_vip_port prototype based on octavia-lib https://review.opendev.org/c/openstack/ovn-octavia-provider/+/854764 | 09:06 |
| lajoskatona | bcafarel: thanks, I forgot about that line :-) | 09:27 |
| opendevreview | Lajos Katona proposed openstack/neutron stable/stein: Stein only: Make CI green again https://review.opendev.org/c/openstack/neutron/+/853608 | 09:28 |
| opendevreview | Merged openstack/neutron stable/xena: [OVN] Remove ACLs with remote SG during deletion of SG https://review.opendev.org/c/openstack/neutron/+/854559 | 09:54 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron master: Update NDP proxy documentation https://review.opendev.org/c/openstack/neutron/+/854350 | 10:10 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Stein: fix failing jobs https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/853794 | 10:28 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: DNM Just test of the Centos 9 stream periodic job https://review.opendev.org/c/openstack/neutron/+/854191 | 11:01 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 11:47 | |
| opendevreview | Merged openstack/neutron stable/stein: Stein only: Make CI green again https://review.opendev.org/c/openstack/neutron/+/853608 | 13:07 |
| opendevreview | David Hill proposed openstack/neutron stable/yoga: Allow operator to disable usage of random-fully https://review.opendev.org/c/openstack/neutron/+/854795 | 13:17 |
| opendevreview | Merged openstack/neutron stable/yoga: [OVN] Remove session check in ``update_network_postcommit`` https://review.opendev.org/c/openstack/neutron/+/854233 | 13:24 |
| lajoskatona | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Aug 26 14:00:11 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. 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 |
| lajoskatona | o/ | 14:00 |
| ralonsoh | hello | 14:00 |
| amorin_ | hello | 14:00 |
| *** amorin_ is now known as amorin | 14:00 | |
| slaweq | hi | 14:00 |
| njohnston_ | o/ | 14:01 |
| lajoskatona | mlavalle can't join today | 14:02 |
| mlavalle | o/ | 14:03 |
| * mlavalle in another meeting | 14:03 | |
| lajoskatona | we have four drivers today, but we need at least 5 as I count | 14:04 |
| obondarev_ | hi | 14:04 |
| lajoskatona | 5 :-) | 14:04 |
| *** dasm|off is now known as dasm | 14:04 | |
| haleyb | hi | 14:04 |
| *** obondarev_ is now known as obondarev | 14:04 | |
| lajoskatona | Let's start :-) | 14:04 |
| lajoskatona | We have 2 RFEs which are related to each other as I see: | 14:05 |
| lajoskatona | [RFE] Add DSCP mark 44 (#link https://bugs.launchpad.net/neutron/+bug/1987378 ) | 14:05 |
| ralonsoh | This one is easy, I think | 14:05 |
| lajoskatona | In comment slaweq already added that perhaps no need for a formal RFE for this | 14:05 |
| slaweq | TBH, for me it doesn't seems like real RFE even | 14:05 |
| *** njohnston_ is now known as njohnston | 14:05 | |
| lajoskatona | +1 | 14:05 |
| ralonsoh | (I added the RFE just in case) | 14:05 |
| slaweq | this seems like minor and obvious change (addition) | 14:06 |
| njohnston | +1 | 14:06 |
| ralonsoh | I have just one question related, now you are here | 14:06 |
| lajoskatona | ralonsoh: please | 14:06 |
| ralonsoh | this feature implies to add a new DSCP mark, that implies changing the API | 14:06 |
| ralonsoh | but | 14:06 |
| ralonsoh | the API values can be consulted via API too | 14:06 |
| ralonsoh | example | 14:07 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/854369/1/neutron_tempest_plugin/api/test_qos.py | 14:07 |
| ralonsoh | so I don't think we need an extension, because those values can be consulted via API (these values = DSCP accepted values, per driver) | 14:07 |
| ralonsoh | right? | 14:08 |
| slaweq | for me this sounds good | 14:08 |
| slaweq | we can discover values acceptable in the cloud using that existing API | 14:08 |
| ralonsoh | exactly | 14:08 |
| obondarev | makes sense | 14:08 |
| njohnston | agreed | 14:08 |
| ralonsoh | thanks a lot, that's all from me related to this feature | 14:09 |
| lajoskatona | +1 | 14:09 |
| haleyb | +1 from me | 14:09 |
| njohnston | I would just say that we should make sure that discoverabiluty method is in the api ref - I don't see it when I look at the DSCP api | 14:10 |
| ralonsoh | it is in the rule-type API | 14:10 |
| ralonsoh | I'll send you the link | 14:10 |
| ralonsoh | https://docs.openstack.org/api-ref/network/v2/index.html?expanded=list-qos-rule-types-detail,show-qos-rule-type-details-detail#show-qos-rule-type-details | 14:11 |
| njohnston | perhaps we add an example there that shows the DSCP details, none of the examples demonstrate that | 14:11 |
| ralonsoh | njohnston, I'll add it | 14:12 |
| njohnston | +1 thanks! | 14:12 |
| lajoskatona | good idea | 14:12 |
| lajoskatona | ok, I think we can move on | 14:12 |
| lajoskatona | [RFE] Add a port extension to set/define the switchdev capabilities (#link https://bugs.launchpad.net/neutron/+bug/1987093 ) | 14:12 |
| ralonsoh | the goal of this RFE is to avoid exposing/modifying the port bindings from Neutron (or a Neutron user) | 14:13 |
| ralonsoh | port binding should be read-only always | 14:13 |
| ralonsoh | and only Nova should change that | 14:13 |
| ralonsoh | so, in order to create a HW offloaded port, I'm proposing this new extension | 14:14 |
| ralonsoh | why? a non-admin user, with the needed policies, can change a port binding PCI address | 14:14 |
| ralonsoh | pointing, for example, to the compute node hard drive PCI address | 14:14 |
| ralonsoh | that means when you boot the VM, this compute nodes dies | 14:14 |
| ralonsoh | that's a possible security issue | 14:15 |
| slaweq | for backward compatybility will this value be still exposed in binding profile, as it is now? | 14:15 |
| ralonsoh | yes | 14:15 |
| slaweq | so there will be no changes on nova required | 14:15 |
| ralonsoh | it will | 14:15 |
| slaweq | ok, sounds good for me | 14:15 |
| lajoskatona | agree, as I see it is nova who has all the knowledge for the profile, let it do its best :-) | 14:16 |
| ralonsoh | (and btw, that was something proposed by a Nova folk, sean-k-mooney ) | 14:16 |
| ralonsoh | so we'll have full support from Nova side | 14:16 |
| lajoskatona | :-) | 14:16 |
| obondarev | should we try make it consistent with direct ports (SRIOV)? | 14:16 |
| ralonsoh | yes, that's the goal | 14:17 |
| obondarev | ok cool | 14:17 |
| lajoskatona | Ok, it was also easy | 14:18 |
| lajoskatona | We have no more RFEs, but: | 14:18 |
| lajoskatona | #topic On Demand Agenda | 14:19 |
| lajoskatona | (amorin): Add new novaplug mechanism driver | 14:19 |
| amorin | Hey | 14:19 |
| lajoskatona | https://bugs.launchpad.net/neutron/+bug/1986969 | 14:19 |
| lajoskatona | https://review.opendev.org/c/openstack/neutron/+/854553 | 14:19 |
| amorin | I can explain a little bit the context | 14:19 |
| sean-k-mooney | o/ | 14:19 |
| amorin | hey sean-k-mooney | 14:19 |
| sean-k-mooney | this the trusted vf changes | 14:20 |
| sean-k-mooney | or hardware offloaed ovs | 14:20 |
| ralonsoh | sean-k-mooney, it is approved, yes | 14:20 |
| sean-k-mooney | for the swtichdev capablity nova should set that on our side | 14:20 |
| ralonsoh | we are talking about other bug now | 14:20 |
| sean-k-mooney | fro trustedVF a new extstion on the neutron side | 14:20 |
| sean-k-mooney | woudl be ideal | 14:20 |
| lajoskatona | sean-k-mooney: for this one: https://bugs.launchpad.net/neutron/+bug/1987093 ? | 14:21 |
| sean-k-mooney | we should not do that | 14:21 |
| sean-k-mooney | at least not as the tital states | 14:21 |
| sean-k-mooney | nova can detect if the VF has that capablity and set it | 14:22 |
| sean-k-mooney | no if we want to allow user to schdule to a shost that has hardawr offloaed ovs | 14:22 |
| sean-k-mooney | having an extion to request that via a triat or somthing would be nice | 14:22 |
| sean-k-mooney | but setting the capablit is somethign we shoudl fix in nova | 14:22 |
| sean-k-mooney | the trusted VF feature ahs a simiar problem however | 14:22 |
| sean-k-mooney | that can only be fixed in neutorn | 14:23 |
| sean-k-mooney | it also requires a vaule to be set in the profile to use | 14:23 |
| sean-k-mooney | that shoudl be done differntly | 14:23 |
| ralonsoh | but this is other feature, not related | 14:23 |
| ralonsoh | we can address it in other bug | 14:23 |
| sean-k-mooney | yes but i don tthink you shoudl try to adress https://bugs.launchpad.net/neutron/+bug/1987093 in nova | 14:23 |
| sean-k-mooney | * in neutron | 14:24 |
| ralonsoh | ok, now I'm lost | 14:24 |
| lajoskatona | me too :-) | 14:24 |
| sean-k-mooney | the binding profie is ment to be used to pass info form nova to the network backend | 14:24 |
| lajoskatona | ok, let's go back to https://bugs.launchpad.net/neutron/+bug/1987093 ([RFE] Add a port extension to set/define the switchdev capabilities ) | 14:24 |
| sean-k-mooney | right so i am not conviced we shoudl do ^ | 14:25 |
| sean-k-mooney | nova does not use the "{"capabilities": ["switchdev"]}" for anything today | 14:25 |
| lajoskatona | do we need a spec on nova side also to be in sync? | 14:26 |
| sean-k-mooney | and the enduer has no idea if the VF supports it | 14:26 |
| ralonsoh | and how should we ask for a HWOL port? | 14:26 |
| sean-k-mooney | just vic type = direct | 14:26 |
| sean-k-mooney | no special request | 14:26 |
| ralonsoh | and if we have SRIOV + OVS? | 14:27 |
| ralonsoh | what driver should attend this request? | 14:27 |
| sean-k-mooney | if we want to suppot that we shoudl have a custom trait | 14:27 |
| sean-k-mooney | but just adding "{"capabilities": ["switchdev"]}" | 14:27 |
| sean-k-mooney | will not allow you to chosee today | 14:27 |
| sean-k-mooney | the nova spec to implemnt the checking based on that was not finished | 14:27 |
| sean-k-mooney | ralonsoh: you wote the code may years ago but we never merged it | 14:27 |
| ralonsoh | this is the way we have now to discriminate if this port is for OVS (HW offload) or SRIOV (not HWOL) | 14:28 |
| sean-k-mooney | nope | 14:28 |
| ralonsoh | in Neutron yes | 14:28 |
| sean-k-mooney | the bug fix that enforect that requriemtn was wrong | 14:28 |
| sean-k-mooney | its check by ovs but that check is useless | 14:28 |
| ralonsoh | if (vnic_type == portbindings.VNIC_DIRECT and | 14:28 |
| ralonsoh | 'switchdev' in capabilities): | 14:28 |
| ralonsoh | LOG.debug("Refusing to bind due to unsupported vnic_type: %s " | 14:28 |
| ralonsoh | "with switchdev capability", portbindings.VNIC_DIRECT) | 14:28 |
| ralonsoh | ^^ SRIOV | 14:28 |
| ralonsoh | and the opposite in OVS | 14:28 |
| sean-k-mooney | yep | 14:28 |
| sean-k-mooney | that check is pointless | 14:29 |
| sean-k-mooney | you have no idea if that port is conencted to a VF that is in swtichdev mode | 14:29 |
| ralonsoh | Ok, let's do this | 14:29 |
| ralonsoh | let's move this discussion out of this meeting | 14:29 |
| sean-k-mooney | +1 | 14:29 |
| ralonsoh | between you and me | 14:29 |
| ralonsoh | and we can continue with amorin bug | 14:29 |
| sean-k-mooney | well with anyone that is interested | 14:29 |
| amorin | ok | 14:29 |
| sean-k-mooney | but sure | 14:29 |
| ralonsoh | (I'll update the bug in LP) | 14:29 |
| lajoskatona | thanks, let's do that | 14:30 |
| lajoskatona | ralonsoh, sean-k-mooney: thanks | 14:30 |
| amorin | we have customers using neutron api from terraform, they create port with a device_id, which endup NOT beeing attached to the instance | 14:30 |
| amorin | so, to solve this on our side, we will add a custom mech-driver (novaplug) | 14:30 |
| sean-k-mooney | ah this im glad im here :) | 14:30 |
| amorin | after a discussion with sean-k-mooney | 14:31 |
| amorin | it seems that the best would be to set device_id to be an admin only thing | 14:31 |
| ralonsoh | (BTW, the goal of https://bugs.launchpad.net/neutron/+bug/1986969 was not to create a new mech driver, but to document the current behaviour) | 14:31 |
| amorin | because nova will never approve plugging a port outside of a regular nova attache | 14:31 |
| amorin | ralonsoh, yes true | 14:32 |
| amorin | I just wanted to share what we will do downstream | 14:32 |
| amorin | I dont want to bring our solution upstream, I just want to fix the issue at the end | 14:32 |
| amorin | I created this in nova: https://review.opendev.org/c/openstack/nova/+/854627 | 14:32 |
| sean-k-mooney | yep so form a nova point of view detaching or attaching a port via neuton is not supported | 14:33 |
| sean-k-mooney | and we dont want to supprot that in the future | 14:33 |
| ralonsoh | right, you shouldn't | 14:33 |
| sean-k-mooney | so we would prefer i fthe device_id and devie_oweer filed were admin/service user ownly for post/put | 14:33 |
| sean-k-mooney | allowing normaly users readonly access is fine | 14:34 |
| sean-k-mooney | but only nova/ironic/zun shoudl set them | 14:34 |
| sean-k-mooney | as part of there internal interface attach workflows | 14:34 |
| sean-k-mooney | well or neuton in the case of l3 router ports ecrta | 14:34 |
| lajoskatona | sounds logical | 14:35 |
| amorin | +1 | 14:35 |
| slaweq | ok, but if we will change that API and allow it only to the admin, we may break someone's usecase potentially if e.g. someone uses this field now for some custom ports | 14:35 |
| sean-k-mooney | yes that is possible | 14:36 |
| obondarev | for device_owner I think many users might use it | 14:36 |
| amorin | maybe we can add an extra option in neutron.conf to change this behavior> | 14:36 |
| amorin | ? | 14:36 |
| slaweq | (I don't know about such uses cases in real world, just thinking loud now) | 14:36 |
| sean-k-mooney | well it can be contoled by custom policy | 14:36 |
| ralonsoh | this is part of the port binding | 14:36 |
| sean-k-mooney | i know of one incorrect use today | 14:36 |
| amorin | custom policy is not an option here, if it's available, our customer expects to use it | 14:37 |
| sean-k-mooney | the shfit on stack team were considering using the id to reserve ip for contianer | 14:37 |
| ralonsoh | so another reason to make the port binding read only | 14:37 |
| slaweq | ralonsoh port binding? | 14:38 |
| slaweq | don't we talk about device_id and device_owner fields? | 14:38 |
| obondarev | these are separate fields | 14:38 |
| ralonsoh | sorry, no, this is not part of the port binding info | 14:38 |
| sean-k-mooney | yes are seperate yes | 14:38 |
| ralonsoh | my bad | 14:38 |
| lajoskatona | slaweq: I thought the same | 14:38 |
| slaweq | ok | 14:38 |
| sean-k-mooney | nova sets them during port attch at the same time it binds the port | 14:38 |
| sean-k-mooney | but they are seperate | 14:38 |
| sean-k-mooney | but that is just use minimisng the api calls not | 14:39 |
| slaweq | ok, so I would like to clarify one thing as I'm not sure I'm following all the discussion here | 14:39 |
| slaweq | what is the proposal to discuss: document current behaviour on Neutron side or add new mechanism driver in neutron as amorin proposed already in gerrit or maybe something else? | 14:40 |
| slaweq | like changing current default API policies? | 14:40 |
| opendevreview | sean mooney proposed openstack/neutron master: Revert "ovs mech: bind only if user request switchdev" https://review.opendev.org/c/openstack/neutron/+/854796 | 14:40 |
| sean-k-mooney | i was suggesting changing the default api policy | 14:40 |
| lajoskatona | To document is the minimum as I see | 14:40 |
| amorin | document +1 | 14:41 |
| sean-k-mooney | documenting is alwasy good | 14:41 |
| amorin | changing it to admin only | 14:41 |
| lajoskatona | but changing the policies that can be risky as you said with current unknown users | 14:41 |
| sean-k-mooney | the issue is right now if you set the device-id to a nova server uuid you will start currptiong the nova db | 14:41 |
| amorin | moreover, you can set it to a device_id which does not belong to the same tenant | 14:41 |
| amorin | nova does nothing about it | 14:41 |
| amorin | but openstack port list --server uuid | 14:42 |
| amorin | as admin | 14:42 |
| amorin | will print it | 14:42 |
| sean-k-mooney | really thats not nice | 14:42 |
| obondarev | should nova distinguish real interfaces from such manually created ones? | 14:42 |
| amorin | very confusing for admins | 14:42 |
| sean-k-mooney | the curent api contarct is that the device-id should be set to the entity that consumes the port | 14:43 |
| sean-k-mooney | entiy being nova instnace, ironic server or zun contianer | 14:43 |
| sean-k-mooney | the device-owner field is not used for filtering | 14:43 |
| slaweq | so as sean-k-mooney said, we can change default API policies, document it and write "big" release note that this behaviour changed and if You want to use it in old way, You need to change Your API policies | 14:43 |
| amorin | +1 | 14:44 |
| sean-k-mooney | yep | 14:44 |
| lajoskatona | yeah, as it wa never an official "feature" | 14:44 |
| lajoskatona | +1 | 14:44 |
| sean-k-mooney | by the way the usecase the opensfhit had was creating port to reservice ips for there use | 14:44 |
| sean-k-mooney | so i also feel like that could be adress as its won feature another way | 14:44 |
| sean-k-mooney | i.e. provide a way to reserve ips without having to create unattached ports | 14:45 |
| amorin | but you can create ports without device_id, why do they need a device_id? | 14:45 |
| sean-k-mooney | baicaly like creating flotating ip but form a normal subnet | 14:45 |
| slaweq | ^^ that would be another, bigger RFE IMO | 14:45 |
| sean-k-mooney | amorin: they wanted to track that the ip is used by that vm | 14:46 |
| sean-k-mooney | or rahter a contianer on that vm | 14:46 |
| amorin | ack | 14:46 |
| sean-k-mooney | slaweq: yes it would | 14:46 |
| amorin | were they aware that a reboot hard of the VM would actually attached it? | 14:46 |
| sean-k-mooney | nope | 14:46 |
| sean-k-mooney | and we were not either | 14:47 |
| sean-k-mooney | (nova team) | 14:47 |
| amorin | ok | 14:47 |
| sean-k-mooney | i dont thin that used to happen | 14:47 |
| ralonsoh | it works, yes | 14:47 |
| sean-k-mooney | i think its a side effect of the network info cahce healing i added a few cycle ago | 14:47 |
| lajoskatona | do we have to handle that case? I mean hard reboot ? | 14:47 |
| amorin | true | 14:47 |
| sean-k-mooney | its not ment ot work because it does not actully set thing up in our db properly | 14:47 |
| amorin | (for the healing side effect) | 14:47 |
| obondarev | so should we disallow device_id only or device_owner is also required? | 14:47 |
| amorin | both I think | 14:48 |
| sean-k-mooney | nova likely need to have its own bug for this and figure out hwo we want to move forward | 14:48 |
| lajoskatona | perhaps a good discussion for the PTG :-) | 14:48 |
| sean-k-mooney | yep perhaps | 14:49 |
| sean-k-mooney | likely we shoudl jsut reject the external event and not populate it in the netowrk info cache and complain loadly | 14:49 |
| sean-k-mooney | the probalem is to who | 14:49 |
| lajoskatona | ok, so today and from Neutron perspective we agree that we have to document this behaviour and change the default policies for dev_id and dev_owner, am I right? | 14:50 |
| ralonsoh | I think so, this should be the first step | 14:50 |
| obondarev | well, the issue described is only related to device_id, so not sure device_owner is required here also | 14:50 |
| lajoskatona | ok, thanks | 14:50 |
| lajoskatona | no it mentions owner also, let's see it in the review, I would say :-) | 14:51 |
| obondarev | less potential "broken" users is better I think | 14:52 |
| ralonsoh | right | 14:52 |
| slaweq | ++ | 14:52 |
| lajoskatona | that is a good point | 14:52 |
| obondarev | + for continue in review | 14:53 |
| lajoskatona | Ok, so documentation and policy change for device_id for now | 14:53 |
| amorin | ok | 14:53 |
| lajoskatona | Do you have anything more to discuss today? | 14:53 |
| lajoskatona | If nothing we can close the meeting for today | 14:54 |
| slaweq | nothing from me | 14:54 |
| lajoskatona | #endmeeting | 14:55 |
| opendevmeet | Meeting ended Fri Aug 26 14:55:24 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-08-26-14.00.html | 14:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-08-26-14.00.txt | 14:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-08-26-14.00.log.html | 14:55 |
| obondarev | thanks, bye | 14:55 |
| ralonsoh | have a nice weekend | 14:55 |
| lajoskatona | Have a nice weekend | 14:55 |
| slaweq | have a great weekend | 14:55 |
| slaweq | o/ | 14:55 |
| amorin | see you, thanks | 14:59 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Retrieve the DSCP valid marks from the API https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/854369 | 15:14 |
| opendevreview | Merged openstack/neutron master: Bump revision number of objects when description is changed https://review.opendev.org/c/openstack/neutron/+/851733 | 16:17 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/ussuri: Ensure members without subnet belong to VIP subnet or fail https://review.opendev.org/c/openstack/ovn-octavia-provider/+/850996 | 18:55 |
| opendevreview | Merged openstack/neutron stable/yoga: Allow operator to disable usage of random-fully https://review.opendev.org/c/openstack/neutron/+/854795 | 19:43 |
| opendevreview | Merged openstack/neutron master: Update NDP proxy documentation https://review.opendev.org/c/openstack/neutron/+/854350 | 20:51 |
| *** dasm is now known as dasm|off | 21:07 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!