| opendevreview | Merged openstack/neutron master: Add trusted vif api extension for the port https://review.opendev.org/c/openstack/neutron/+/926068 | 01:27 |
|---|---|---|
| opendevreview | Rico Lin proposed openstack/ovn-octavia-provider master: Add OVN DB sync in OVN driver https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925324 | 04:51 |
| opendevreview | Rico Lin proposed openstack/ovn-octavia-provider master: Add octavia_client and sync cmd https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925747 | 04:51 |
| ricolin | ralonsoh: Thanks for review, the ovn-octavia sync patch updated, please kindly review again. thank you! | 04:58 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add new API extension ``uplink-status-propagation-updatable`` https://review.opendev.org/c/openstack/neutron-lib/+/927820 | 07:07 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add API extension ``quota-check-limit-default`` https://review.opendev.org/c/openstack/neutron-lib/+/926777 | 07:07 |
| ralonsoh | lajoskatona, hello! 2024.2 was created yestarday, we can start adding new code for 2025.1 | 07:08 |
| ralonsoh | (for n-lib I mean) | 07:08 |
| lajoskatona | ralonsoh: ack, good news | 07:08 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add new "tagging" API method: create (POST) https://review.opendev.org/c/openstack/neutron/+/924724 | 07:11 |
| opendevreview | Merged openstack/os-ken master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/os-ken/+/928203 | 08:07 |
| opendevreview | Merged openstack/ovsdbapp stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/ovsdbapp/+/928210 | 08:07 |
| opendevreview | Merged openstack/ovsdbapp stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/ovsdbapp/+/928214 | 08:07 |
| opendevreview | Merged openstack/neutron-lib stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/neutron-lib/+/928182 | 08:08 |
| opendevreview | Merged openstack/python-neutronclient stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/python-neutronclient/+/928222 | 08:09 |
| opendevreview | Merged openstack/python-neutronclient stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/python-neutronclient/+/928223 | 08:09 |
| opendevreview | Merged openstack/neutron-lib stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/neutron-lib/+/928184 | 08:09 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Fix member subnet id on a fully populated LB https://review.opendev.org/c/openstack/ovn-octavia-provider/+/928335 | 10:30 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Test metadata query over IPv6 only network with OVS and LB https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/926503 | 10:31 |
| opendevreview | Merged openstack/neutron master: docs: The job is not in experimental but in periodic queue https://review.opendev.org/c/openstack/neutron/+/927971 | 10:31 |
| opendevreview | Merged openstack/os-ken stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/os-ken/+/928198 | 10:44 |
| opendevreview | Merged openstack/os-ken stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-ken/+/928199 | 11:08 |
| opendevreview | Merged openstack/neutron stable/2024.1: Fix port_hardware_offload_type ML2 extension https://review.opendev.org/c/openstack/neutron/+/927707 | 12:02 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928353 | 13:08 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928355 | 13:08 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928356 | 13:08 |
| slaweq | haleyb: hi, do we have drivers meeting today? | 13:45 |
| haleyb | slaweq: yes, i see we have two things to discuss. i'm actually double booked but will figure it out | 13:46 |
| slaweq | sure, thx | 13:46 |
| joa | hi o/ Available to discuss the spec, as ralonsoh (if i'm not mistaken) mentioned on gerrit. | 13:47 |
| opendevreview | Merged openstack/os-vif master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928356 | 13:49 |
| lajoskatona | haleyb: Hi, do we allow features to stadiums or we are over that in the release process? | 13:56 |
| haleyb | joa: ack, thanks | 13:57 |
| haleyb | lajoskatona: as in rfes? it's a good question - i guess we should but i don't remember having much come to the drivers meeting | 13:59 |
| lajoskatona | haleyb: no, the ready patches, like: https://review.opendev.org/c/openstack/neutron-fwaas/+/845756 | 14:00 |
| haleyb | lajoskatona: let's discuss after drivers | 14:00 |
| haleyb | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Sep 6 14:00:30 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. 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 |
| haleyb | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh | 14:00 |
| mlavalle | \o | 14:00 |
| obondarev | hi | 14:00 |
| ralonsoh | hello | 14:00 |
| lajoskatona | o/ | 14:01 |
| cbuggy | o/ | 14:01 |
| joa | o/ | 14:01 |
| haleyb | like last week, i have a hard stop in :30, but i only see two things on agenda for today | 14:01 |
| slaweq | o/ | 14:01 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2075955 | 14:02 |
| haleyb | this was from joa but i see ralonsoh had a comment on the spec | 14:02 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron-specs/+/927520 | 14:02 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-specs/+/927520/comments/d17f91e8_d7ac009c | 14:02 |
| haleyb | just an fyi that we didn't approve the rfe but asked for the spec to get more detail | 14:03 |
| ralonsoh | so what I commented in the review, and this is something that could be tested by the submitter, is that the spec scope can be achieved right now | 14:04 |
| ralonsoh | but, of course, that is something the LP bug submitter should consider and comment | 14:04 |
| ralonsoh | maybe there is a limitation that I didn't see | 14:05 |
| joa | I wanted to at least better understand the proposal, with operational implications. Fwiw, we're currently having something based on zed, which means the feature is not available out of the box for us anyways to test, and would require some backporting first . | 14:05 |
| ralonsoh | what feature? | 14:05 |
| ralonsoh | RBAC? | 14:05 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/883246 you mean | 14:06 |
| joa | No, the patch linked in the comment, which was recently merged | 14:06 |
| joa | yes | 14:06 |
| ralonsoh | let's be clear on this: this feature will be implemented in master | 14:06 |
| joa | yes, for sure. If usable, I'll have to backport it in our internal forks . | 14:07 |
| joa | (along with all the related shenanigans for the cli and whatnot to work) | 14:07 |
| ralonsoh | and, btw, you don't need as an admin to create the port | 14:07 |
| ralonsoh | the non-admin user can create the port. And this non-admin user port will receive the default SG | 14:07 |
| ralonsoh | and this user cannot modify the SG on the port, so you are enforcing the SG rules | 14:08 |
| ralonsoh | (you==admin) | 14:08 |
| joa | yes, that's already what I'm doing. To be frank, what the spec covers is something we're trying to POC internally at the moment, by lack of better alternative so far. | 14:08 |
| joa | we agree that to prevent modifying SG on the port, we'll require a patch to allow policy control on port/SG bindings ? | 14:08 |
| ralonsoh | in any case, and because you are testing that, I'll reply to the question of the gerrit comment (I didn't check it) | 14:09 |
| ralonsoh | this is done | 14:09 |
| joa | (which is already part of a second RFE, linked in the first) | 14:09 |
| ralonsoh | you can define that a non-admin user cannot modify a port SG | 14:09 |
| joa | oh ? might have forgotten to check on master then | 14:09 |
| ralonsoh | and by default, the default SG cannot be modify by a non-admin user | 14:09 |
| joa | it wasn't the case in zed, and I took some time to find out how to tweak that | 14:09 |
| ralonsoh | the default SG belongs to a project and only the admin can modify it | 14:09 |
| slaweq | those api policies are there for very long time already | 14:10 |
| joa | About the default SG, I understand that your proposal is to change that default, to allow the network stream we need for our project. But then it'd be applied to all networks, right ? | 14:10 |
| ralonsoh | a network belongs to a project | 14:11 |
| slaweq | by default we don't have policies for sg field in the port | 14:11 |
| ralonsoh | actually several networks can belong to a single project | 14:11 |
| slaweq | it was for sure | 14:11 |
| joa | slaweq: In zed, the `enforce_policy` flag on the sg extensions to control create_port:securitygroups and update_port:securitygroup was not set. | 14:11 |
| ralonsoh | each port created on these networks, will receive the project default SG | 14:11 |
| slaweq | you can create custom policies in policy.yaml file always | 14:11 |
| slaweq | and should be respected | 14:12 |
| ralonsoh | you can create custom policies | 14:12 |
| joa | ralonsoh: Sure, but we want to configure that specific service network as an admin, then share/external the network providing access to the service with specific projects | 14:12 |
| slaweq | it would be something like: "update_port:security_groups: rule:admin_only" if I'm not mistaken | 14:12 |
| joa | yes, but was not available/supported in zed. maybe it has been added meanwhile though, in which case I only need to backport/replicate the behavior in our old version, until we upgrade. | 14:13 |
| ralonsoh | then please move to a newer version. If you implement this RFE you are proposing, you won't have it in zed | 14:14 |
| ralonsoh | you'll have the same problem | 14:14 |
| joa | ralonsoh: I'm unsure how you perceive the "service network" I'm attempting to describe, but I don't really think it'd be a good idea to change the default for a whole project, as it might have multiple networks, that shoudl ahve the original defaults instead | 14:14 |
| ralonsoh | then please describe, in Neutron terms, what "service network" is for you | 14:15 |
| joa | ralonsoh: I'm aware that implementing it will mean backporting for zed anyways, which is not a big issue in itself. What we want is to diverge as little as possible from upstream in the long run | 14:15 |
| joa | So, we need a shared/external network, defined by the administrator, that provides access to a service which is not managed by Openstack. The reason we're doing it this way, is that we want to be able to setup the network so that we can only share it to specific projects (not all), and to make it as easy as possible to "enable" access to the service by simply adding the network to the VMs requiring | 14:16 |
| joa | it. | 14:16 |
| ralonsoh | again, that is doable now: one project creates the shared network with a set of specific RBACs to other projects | 14:18 |
| ralonsoh | and then the ports created on this network will have the same default SG | 14:18 |
| joa | Also, we want to prevent VMs attached to this network from talking to each other: thus the restriction on adding SGs/updating SGs on the port. | 14:18 |
| joa | Yes, we're already using rbac + policy to handle the individual sharing and preventing updates to the SG | 14:19 |
| joa | the thing is: How do you offer the "default" for the port, without affecting the rest of the projects/networks/ports ? | 14:19 |
| haleyb | So is the difference here between a "project default SG", which applies to all ports on all the project networks, and a "network default SG" which only applies to ports on a single network, over-riding the project default SG? | 14:19 |
| ralonsoh | the default SG is per project, the project that created the shared network | 14:20 |
| joa | haleyb: yes, that's how I see it. Of course, given how I was describing it in the spec, is slightly more flexible thatn a simple "network default sg" | 14:20 |
| haleyb | ralonsoh: understood, i'm just trying to see what the ask is and if it's already doable today | 14:20 |
| joa | ralonsoh: which is why I didn't delve into the idea of modifying the default SG. I only want that for these networks that would expose a service to some projects/VMs | 14:21 |
| joa | (and of course, if we have more than one, each should have their own settings) | 14:21 |
| ralonsoh | again: create a single project per shared network | 14:21 |
| haleyb | ralonsoh: oh, right that's one way | 14:21 |
| slaweq | joa do your tenants who owns vms connected to that "shared" network have also other vms which needs to use own, different SGs? | 14:21 |
| ralonsoh | the default SG will apply only to each shared network port | 14:22 |
| joa | so, I'd need to create as many "empty" projects as the number of networks that I need different defaults for ? | 14:22 |
| ralonsoh | why not? | 14:22 |
| joa | slaweq: Hypothetically, yes. | 14:22 |
| joa | ralonsoh: ok that makes things clearer, I understand your point now, I missed the idea of a project per network | 14:23 |
| slaweq | so if you will forbid updating SGs for regular users, it will affect all the vms/ports which they have | 14:23 |
| slaweq | and they will not be able to set/update SGs for any of their ports | 14:23 |
| slaweq | is that ok for you? | 14:23 |
| joa | slaweq: I've fiddled with it, and found the right syntax to specify specific network ids | 14:23 |
| joa | so that I can create the networks, go update the policies (tbh, that's a pain, but policies don't seem to be much for dynamism at the moment), and it'd be fine | 14:24 |
| joa | it'd look like this (quite verbose, but seemed to work during my tests): | 14:24 |
| joa | "custom_service_network": "'%%NETWORK_ID%%':%(network_id)s" | 14:24 |
| slaweq | ahh, so you have policies with rules which contains some specific network_ids in the rules? | 14:25 |
| joa | "create_port:security_groups": "rule:admin_or_network_owner or (role:member and project_id:%(project_id)s and not rule:custom_service_network)" | 14:25 |
| joa | "update_port:security_groups": "rule:admin_or_network_owner or (role:member and project_id:%(project_id)s and not rule:custom_service_network)" | 14:25 |
| joa | yes, starting from your feedback on the other RFE | 14:25 |
| slaweq | so with that if you as an admin will set SG rule for such port you will have what You need, right? | 14:25 |
| joa | probably, in which case ralonsoh cleared up what I did not understand originally, and we may be able to do without what I offered initially. Needs to be tested and validated though | 14:26 |
| joa | (we're also struggling with OVN at the moment, lacking a network-savvy expert :D) | 14:26 |
| slaweq | and in such case we may not need this RFE to be implemented at all to address Your use case so we may not want to do it, right? | 14:27 |
| ralonsoh | so I think we can wait for feedback on this RFE and discuss it once we have it | 14:28 |
| slaweq | ++ | 14:28 |
| joa | slaweq: Yes, to be confirmed. Ralonsoh: agreed. | 14:28 |
| joa | note that i'll be away for the next two weeks, so don't be in a hurry to hear from me x) | 14:28 |
| haleyb | joa: so can you investigate more based on all the great comments above :) and update the bug/spec with any notes? | 14:28 |
| * haleyb thinks that was just agreed to while he was typing | 14:29 | |
| joa | the bug sure, but how should I update the spec ? with my corrected understanding and that I'll test before closing/resuming work ? | 14:29 |
| haleyb | joa: if you can get it to work in the current (master) code and don't need the spec you can just abandon it | 14:29 |
| joa | sure | 14:30 |
| haleyb | if not we can discuss further | 14:30 |
| joa | Just to double check, Do I need the patch linked in the spec's discussion ? | 14:30 |
| joa | (I feel like I don't ?) | 14:31 |
| haleyb | #link https://review.opendev.org/c/openstack/neutron/+/883246 | 14:32 |
| haleyb | that one? | 14:32 |
| joa | yes | 14:32 |
| haleyb | i think you do as that defines the default SG objects | 14:32 |
| joa | But I can edit it on each project though, right ? | 14:33 |
| haleyb | that was merged in 2023.2 btw | 14:33 |
| haleyb | i'll let slaweq answer that :) | 14:33 |
| joa | I means, it's a bit more manual in the setup, but I fail to see the need in itself, if I can edit the Default SG on a per-projet basis. | 14:33 |
| slaweq | with this you as admin can define in neutron what SG rules will be added to every new SG created by users | 14:34 |
| slaweq | so if you want to make sure that every new project will have same rules in their SGs, you should use this APIs from that patch | 14:35 |
| slaweq | without that set of rules created automatically was always the same and hardcoded in neutron | 14:35 |
| joa | ok. This was not a concern though, current default behavior so far is ok for us. Only modifying the default SG for those specific network/projects pair was important to us. | 14:35 |
| joa | Alright, I'll try and pass the baton to someone internally, and update the RFE/Spec with our findings when I get back :) | 14:36 |
| haleyb | ok, lets move on to other topic in agenda for today | 14:37 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2078661 | 14:37 |
| haleyb | ralonsoh: that was the one you added | 14:37 |
| ralonsoh | very quick because is trivial, but there is an API change | 14:37 |
| ralonsoh | the flag propagate_uplink_status can be defined in a port during the creation | 14:37 |
| ralonsoh | (that is for ML2/SR-IOV only) | 14:37 |
| ralonsoh | I want to make is updatable, that's all | 14:37 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-lib/+/927820/3/neutron_lib/api/definitions/uplink_status_propagation_updatable.py#30 | 14:38 |
| ralonsoh | that also implies a change in the SRIOV agent, receiving this change | 14:38 |
| ralonsoh | any question? | 14:38 |
| obondarev | lgtm +1 | 14:39 |
| haleyb | ralonsoh: ack. and that was going to be my second question - the sriov agent will need a change since it has work to do when updating the flag, correct? | 14:39 |
| ralonsoh | I think (99% sure) that will work as is now | 14:39 |
| ralonsoh | but I'll check it, of course | 14:39 |
| slaweq | sounds reasonable for me | 14:39 |
| haleyb | ralonsoh: ack | 14:39 |
| slaweq | and straighforward | 14:39 |
| slaweq | so +1 | 14:39 |
| lajoskatona | +1 | 14:39 |
| haleyb | +1 from me | 14:39 |
| mlavalle | +1 | 14:40 |
| ralonsoh | thanks folks | 14:40 |
| ralonsoh | I have an on-demand topic | 14:40 |
| ralonsoh | very quick one | 14:40 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/926725 | 14:40 |
| ralonsoh | we said that in Antelope, we would start enforcing the quota | 14:40 |
| ralonsoh | not enforcing, sorry | 14:40 |
| ralonsoh | checking the quota before setting it, like any other project | 14:41 |
| ralonsoh | now we do like --force by default | 14:41 |
| ralonsoh | I'm removing it in this patch | 14:41 |
| ralonsoh | (there is a warning message added 2 years ago) | 14:41 |
| ralonsoh | what i'm removing here: https://review.opendev.org/c/openstack/neutron/+/926725/4/neutron/extensions/quotasv2.py | 14:42 |
| ralonsoh | so this is not for voting, just for consideration and review, because is a significant change | 14:42 |
| ralonsoh | thank you for reading me | 14:42 |
| lajoskatona | thanks ralonsoh | 14:43 |
| haleyb | thanks, will keep an eye on review | 14:43 |
| ralonsoh | thanks! | 14:43 |
| mlavalle | thanks for the heads up | 14:43 |
| haleyb | any other topics? | 14:44 |
| haleyb | ok, thanks for attending everyone and for the good discussion. have a nice weekend! | 14:44 |
| haleyb | #endmeeting | 14:44 |
| opendevmeet | Meeting ended Fri Sep 6 14:44:55 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:44 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-09-06-14.00.html | 14:44 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-09-06-14.00.txt | 14:44 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-09-06-14.00.log.html | 14:44 |
| obondarev | o/ | 14:45 |
| ralonsoh | have a nice weekend | 14:45 |
| lajoskatona | o/ | 14:45 |
| slaweq | have a good weekend | 14:47 |
| slaweq | o/ | 14:48 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Neutron quota engine checks the resource usage by default https://review.opendev.org/c/openstack/neutron/+/926725 | 14:50 |
| slaweq | haleyb hey, please check https://review.opendev.org/c/openstack/neutron/+/925402 when You will have few minutes. I added tests as you requested | 14:57 |
| lajoskatona | haleyb: I reread the meeting logs from Tuesday, and there's the answer for my question, bugfixes should be merged from now only | 14:58 |
| lajoskatona | haleyb: but I keep in mind to push these stadium patches (and ping the team also ;)) for the coming cycle | 14:59 |
| haleyb | lajoskatona: yes, and we can discuss exceptions. stable/2024.2 for neutron should be created soon i'd guess, same for other projects | 14:59 |
| joa | I know the meeting ended, but FWIW, policies for `create_port:security_groups` and `update_port:security_groups` do not seem to be enabled in master. (neutron/extensions/securitygroups.py, in the EXTENDED_ATTRIBUTES_2_0 dict) | 15:01 |
| lajoskatona | haleyb: ack, I think the owners of these patches can ask for exception, but on the other hand I am not sure if all the processes and communication difficulties make this easy for anybody | 15:02 |
| joa | unless the mechanism in general changed, it still requires adding the `enforce_policy: True` attribute to this dict. | 15:02 |
| lajoskatona | haleyb: but short : let's focus on the stadium hanging feature pathces at the beginning of the next cycle | 15:02 |
| haleyb | lajoskatona: sounds good | 15:03 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Add tests for the 'trusted' attribute in port resource https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/927737 | 15:46 |
| opendevreview | Brian Haley proposed openstack/neutron-lib master: Fix 'flavor' misspelling in VPN flavors https://review.opendev.org/c/openstack/neutron-lib/+/928458 | 16:48 |
| opendevreview | Merged openstack/neutron master: [OVN] Set reside-on-chassis-redirect also for FLAT networks https://review.opendev.org/c/openstack/neutron/+/925402 | 16:56 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-tempest-plugin master: Log console output on con.test_connection timeout https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/928460 | 16:58 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-tempest-plugin master: Log console output on con.test_connection timeout https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/928460 | 17:04 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-tempest-plugin master: refactor: Kill _verify_http_connection (dead code) https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/928461 | 17:07 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: Degrade openstack-tox-py311-with-sqlalchemy-master to periodic https://review.opendev.org/c/openstack/neutron/+/927847 | 17:16 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron-tempest-plugin master: refactor: Kill dead code from utils and tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/928461 | 17:27 |
| opendevreview | Merged openstack/neutron-lib master: Add API extension ``quota-check-limit-default`` https://review.opendev.org/c/openstack/neutron-lib/+/926777 | 19:09 |
| opendevreview | Brian Haley proposed openstack/neutron master: DNM: Test tempest port wait patch https://review.opendev.org/c/openstack/neutron/+/928472 | 20:17 |
| opendevreview | Merged openstack/neutron-lib master: Fix 'flavor' misspelling in VPN flavors https://review.opendev.org/c/openstack/neutron-lib/+/928458 | 21:04 |
| opendevreview | Merged openstack/neutron master: Add new "tagging" API method: create (POST) https://review.opendev.org/c/openstack/neutron/+/924724 | 21:06 |
| zigo | Howdy here! New fun OpenStack cli tool: https://salsa.debian.org/openstack-team/clients/oscs | 21:16 |
| opendevreview | Merged openstack/neutron master: Add L3 HA fullstack failover tests https://review.opendev.org/c/openstack/neutron/+/917429 | 21:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!