| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 00:18 |
|---|---|---|
| frickler | lajoskatona: seeing what neutron did, n-d-r should also be dropping l-c jobs for stable branches instead of trying to fix them? you also could add me to n-d-r-stable group please, now that the governance change has merged | 07:21 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/xena: Dropping lower constraints testing (stable Xena) https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820315 | 07:25 |
| lajoskatona | frickler: Yes we agreed based on the discussion around l-c that on stable we can stop executing it, see the links in this patch for example: https://review.opendev.org/c/openstack/neutron/+/810858 | 07:25 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/xena: Add a StaticScheduler without automatic scheduling https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820099 | 07:26 |
| lajoskatona | frickler: it seems I can't add you but ask some stable cores | 07:26 |
| frickler | lajoskatona: oh, I though I'd added you, too. then let me use my infra powers, I'm not sure stable cores are really active any longer | 07:44 |
| lajoskatona | frickler: thanks :-) | 08:20 |
| frickler | lajoskatona: I can now +2 but not +W, maybe some issue with the acl, will have a look. can you check https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820315/1 please? | 08:23 |
| hgy | Hello, Could I ask a question? | 08:31 |
| hgy | I am deploying OpenStack Victoria in Centos8. My neutron-openvswitch-agent.service is active, but "openstack network agent list" cound not find ovs agent | 08:32 |
| hgy | like this: https://paste.opendev.org/show/811423/ | 08:34 |
| hgy | I deployed all in one node | 08:34 |
| ralonsoh | OVS agent is not populating its state, it is not sending the heartbeats (or those heartbeats are not reaching the server) | 08:36 |
| ralonsoh | check the OVS agent logs in debug mode | 08:36 |
| hgy | ralonsoh: Does "bebug mode" mean adding "debug = true" in /etc/neutron/neutron.conf | 08:37 |
| ralonsoh | yes | 08:38 |
| hgy | thank you | 08:38 |
| hgy | than I "systemctl restart neutron-server.service" and "systemctl restart neutron-openvswitch-agent.service" | 08:42 |
| hgy | ralonsoh: sorry to bother you, could you help me to have a look: https://paste.opendev.org/show/811424/ | 08:43 |
| ralonsoh | sorry but this is just the intial config loading | 08:44 |
| ralonsoh | there is no information about the hearbeats | 08:44 |
| hgy | ralonsoh: this is the end of /var/log/neutron/openvswitch-agent.log, after I restarted neutron-openvswitch-agent.service | 08:45 |
| hgy | ralonsoh: no other logs | 08:45 |
| ralonsoh | so ovs agent is not running, is stuck in this point | 08:46 |
| ralonsoh | where is the privsep config? | 08:46 |
| hgy | ralonsoh: but service status is active(running) | 08:46 |
| ralonsoh | last line should be something like this | 08:46 |
| ralonsoh | INFO oslo.privsep.daemon [-] Running privsep helper: ['sudo', '/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'privsep-helper', '--config-file', '/etc/neutron/neutron.conf', '--config-file', '/etc/neutron/plugins/ml2/ml2_conf.ini', '--privsep_context', 'neutron.privileged.default', '--privsep_sock_path', '/tmp/tmp8_6wgtx8/privsep.sock'] | 08:46 |
| ralonsoh | service could be running but the binary not | 08:47 |
| hgy | ralonsoh: I had modified [privsep] in /etc/neutron/neutron.conf, like this: | 08:50 |
| hgy | ralonsoh: privsep] | 08:50 |
| hgy | user = root | 08:51 |
| hgy | helper_command = true | 08:51 |
| hgy | ralonsoh: I | 08:51 |
| hgy | ralonsoh: It's because I missed a error: FailedToDropPrivileges: privsep helper command exited non-zero | 08:51 |
| hgy | ralonsoh: And I followed https://bugs.launchpad.net/neutron/+bug/1887147 to fix it | 08:52 |
| ralonsoh | helper_command cannot be tre | 08:52 |
| ralonsoh | you need to properly configure the shell command to be executed | 08:53 |
| ralonsoh | for example, by default we use rootwrap to run privsep (this is like "inception" movie) | 08:53 |
| ralonsoh | if you don't know how to configure it | 08:53 |
| ralonsoh | use "root" | 08:53 |
| ralonsoh | or do not add anything, leave it undefined | 08:54 |
| hgy | ralonsoh: Em~~~ yes | 08:55 |
| hgy | ralonsoh: But if I remove it, I always got "oslo_privsep.daemon.FailedToDropPrivileges: privsep helper command exited non-zero (1)" | 08:57 |
| jpic | hi all, what does this wants exactly? eutronclient.common.exceptions.Conflict: Host compute01 is not connected to any segments on routed provider network '9b78f680-9edd-4e64-85ac-9f2ad9418a3a'. It should be connected to one. | 08:58 |
| ralonsoh | then use "sudo" | 08:58 |
| jpic | does the compute host want a route or something? not sure what i'm missing | 08:58 |
| ralonsoh | jpic, are you using router provider networks? | 08:59 |
| jpic | ralonsoh: yes | 09:03 |
| jpic | routed provider network with segments | 09:04 |
| hgy | ralonsoh: Thank you very much, I'm trying it. | 09:04 |
| ralonsoh | jpic, and you know the L3 routing is provided by the underlying infrastructure, right? | 09:05 |
| jpic | yes, i've attached my router to br-ex | 09:05 |
| ralonsoh | jpic, router?? why router? | 09:06 |
| jpic | because i have multiple regions and vlans etc | 09:06 |
| ralonsoh | jpic, but which router? neutron or external? | 09:06 |
| jpic | i've attached br-ex to a switch that is attached to a router | 09:06 |
| ralonsoh | ok then | 09:07 |
| jpic | completely external, sorry | 09:07 |
| ralonsoh | are you using ovs? | 09:07 |
| jpic | yes | 09:08 |
| ralonsoh | so the ovs agent should be connected to this segment | 09:08 |
| jpic | on the compute? | 09:08 |
| ralonsoh | yes | 09:08 |
| jpic | through what bridge? there's no br-ex on the compute, br-ex is on the controler | 09:08 |
| ralonsoh | the physical network that is connected to this segment must be mapped in the OVS bridge mappings | 09:09 |
| opendevreview | Merged openstack/neutron-dynamic-routing stable/xena: Dropping lower constraints testing (stable Xena) https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820315 | 09:11 |
| jpic | I thought the compute was connected to the segment through the int-br-ex patch that connects to br-ex which connects to eth2 | 09:11 |
| jpic | but that is happening on the control server indeed | 09:11 |
| lajoskatona | frickler: elod pushed a fix for the ACL of wf+1: https://review.opendev.org/c/openstack/project-config/+/820351 | 09:13 |
| jpic | ralonsoh: i should have enabled enable_neutron_provider_networks in kolla/globals.yml ;) | 09:22 |
| jpic | then I will have br-ex on the compute and then it will be directly connected! | 09:22 |
| ralonsoh | make sense | 09:22 |
| jpic | well, I hope ... redeploying as we speak ... but pretty confident! | 09:22 |
| jpic | yesterday it was working but I had the network role applied on the compute, which gave br-ex to the compute, and today I re-created the environment but with the network role on the control and got no br-ex on the compute anymore | 09:23 |
| frickler | lajoskatona: thx, +2 | 09:43 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Keep binding:profile keys during placement allocation change https://review.opendev.org/c/openstack/neutron/+/820363 | 09:54 |
| opendevreview | Merged openstack/neutron master: Cleaning of the zuul's project.yaml file https://review.opendev.org/c/openstack/neutron/+/815466 | 10:43 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Replace "target_tenant" with "target_project" in RBAC OVOs and models https://review.opendev.org/c/openstack/neutron/+/815855 | 10:49 |
| ralonsoh | lajoskatona, https://review.opendev.org/c/openstack/neutron/+/819264 | 11:07 |
| ralonsoh | if you have time, thanks! | 11:07 |
| ralonsoh | (that will save some time in the CI, we have those jobs duplicated) | 11:08 |
| jpic | ralonsoh: that worked, but instances could not reach metadata server, so i ran kolla destroy and kolla deploy again to see if it was reproducing on a clean deployment, and now i'm getting that again eutronclient.common.exceptions.Conflict: Host compute01 is not connected to any segments on routed provider network, even though the compute *is* connected to the routed network in its br-ex, any clue | 11:26 |
| jpic | welcome! | 11:26 |
| opendevreview | Tamas Gergely Peter proposed openstack/neutron master: Check whether vxlan group and local addresses are IPv4 or IPv6 and https://review.opendev.org/c/openstack/neutron/+/820376 | 11:55 |
| lajoskatona | ralonsoh: done | 12:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][DNM] Improve DHCP RPC handler https://review.opendev.org/c/openstack/neutron/+/820190 | 12:15 |
| ralonsoh | thanks! | 12:15 |
| jpic | hi all, I don't understand: how do I get a compute host inside segment_host_mapping when creating a subnet? | 13:19 |
| lajoskatona | ralonsoh: could you check this privsep patch for msgpack buffsize: https://review.opendev.org/c/openstack/oslo.privsep/+/819996 if you have some time? | 13:30 |
| ralonsoh | lajoskatona, let me check | 13:33 |
| lajoskatona | ralonsoh: thanks, there was few arguments how to fix the issue (neutron bug: https://bugs.launchpad.net/neutron/+bug/1952611 ) and I can accept them, but you have more privsep knowledge :-) | 13:34 |
| ralonsoh | lajoskatona, right, this solution is backportable. And 100M is a lot! | 13:37 |
| lajoskatona | ralonsoh: thanks, then I will sleep well if you have your vote also on it :-) | 13:37 |
| opendevreview | Pedro Henrique Pereira Martins proposed openstack/neutron master: Extend database to support portforwardings with port range https://review.opendev.org/c/openstack/neutron/+/798961 | 13:59 |
| lajoskatona | #startmeeting neutron_drivers | 14:01 |
| opendevmeet | Meeting started Fri Dec 3 14:01:06 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:01 |
| lajoskatona | Hi | 14:01 |
| ralonsoh | hi | 14:01 |
| njohnston | o/ | 14:01 |
| obondarev | hi | 14:01 |
| slaweq | hi | 14:01 |
| lajoskatona | mlavalle can't join today | 14:01 |
| amotoki | hi | 14:02 |
| lajoskatona | so I think we can start | 14:02 |
| rubasov | hi | 14:02 |
| mlavalle | yeah, I want to pay attention to this training I'm attending | 14:02 |
| lajoskatona | The topic for today: #link https://bugs.launchpad.net/neutron/+bug/1952867 | 14:02 |
| lajoskatona | mlavalle: thanks for telling | 14:03 |
| lajoskatona | This is a bug from liuyulong, and I asked him if he can join us today, but perhaps it is too late | 14:03 |
| obondarev | there is a discussion here: https://review.opendev.org/c/openstack/neutron/+/820006 | 14:04 |
| obondarev | I tried to explain my position in the last comment | 14:04 |
| lajoskatona | obondarev: thanks | 14:04 |
| ralonsoh | I had the same concerns (written in the LP bug) | 14:05 |
| obondarev | I think we need to agree where is the best place to address that use case | 14:06 |
| obondarev | if it's neutron or not | 14:07 |
| ralonsoh | what do you mean? | 14:07 |
| obondarev | host configuration may address this I believe | 14:07 |
| obondarev | "I'm wondering if that could be addressed by creating a tagged interface eth0@4000 on the node and adding it to a separate logical bridge "br-ext". Thus bridge_mappings can stay as is {"external": br-ext, "user": br-vlan}?" | 14:08 |
| ralonsoh | ah right | 14:08 |
| ralonsoh | the problem is that could not work with DPDK or HW offload | 14:08 |
| obondarev | yeah, true | 14:09 |
| obondarev | can we do the same with pure OVS? | 14:09 |
| obondarev | with user space ports and bridges | 14:09 |
| ralonsoh | we need to handle carefully the traffic in the phys bridge | 14:09 |
| ralonsoh | tagging correctly the traffic | 14:10 |
| ralonsoh | of course, the current OF rule set we have in phys-br is not valid | 14:10 |
| ralonsoh | but it could work | 14:10 |
| slaweq | this may also be error prone if e.g. there will be 2 different flat networks and both physical networks will use same bridge in bridge mapping | 14:10 |
| ralonsoh | right | 14:11 |
| ralonsoh | that;s configuration | 14:11 |
| ralonsoh | we can't allow this | 14:11 |
| ralonsoh | same as overlapping VLAN ranges | 14:11 |
| slaweq | for the problem with vlans which liuyulong__ mentioned in gerrit - IMO that's what are vlan network types for, no? | 14:11 |
| ralonsoh | yeah... he's right | 14:11 |
| slaweq | and physical network for me always meant "really physical" network | 14:12 |
| lajoskatona | and now we create placement resources based on bridge mapping for QoS, not sure if placement can handle such change | 14:12 |
| ralonsoh | not the current code | 14:12 |
| ralonsoh | because we asume 1:1 phys bridges - network | 14:12 |
| slaweq | such change IMO would make a lot of mess in many places | 14:12 |
| obondarev | + | 14:12 |
| slaweq | and would be not correct from the "model point of view" | 14:13 |
| slaweq | I hope You know what I mean | 14:13 |
| ralonsoh | yes: 1 physnet, 1 bridge, 1 NIC | 14:13 |
| lajoskatona | yeah or we have to limit this new mapping to a few features only, and add a lot of conditions to handle | 14:13 |
| slaweq | ralonsoh++ | 14:14 |
| rubasov | I also have the understanding that we see a configuration there that ignored the original meaning of a "physnet" and now would like to change the implementation to keep the configuration intact | 14:14 |
| rubasov | of course configuration change can be real pain, but I'm not sure if it's best worked around from the implementation | 14:15 |
| opendevreview | Tamas Gergely Peter proposed openstack/neutron master: Check whether vxlan group and local addresses are IPv4 or IPv6 and https://review.opendev.org/c/openstack/neutron/+/820376 | 14:16 |
| lajoskatona | rubasov: +1 | 14:16 |
| ralonsoh | correct | 14:16 |
| lajoskatona | ok so I think we can say that it's better not to change how bridge-mapping is now and keep 1 nic - 1 bridge - 1 physnet relataion as it is today | 14:20 |
| amotoki | IIUC this proposal tries to introduce anotherr abstraction model in neutron: some ID ranges for "extrenal" and another non-overlapping ID range for "user". | 14:20 |
| amotoki | I think it is not a role of neutron. If kernel supports such kind of abstraction of bridges, neutorn can handle such as individual bridges, but it is not the real... | 14:20 |
| amotoki | I totally agree with "1 nic - 1 bridge - 1 physnet " | 14:21 |
| slaweq | yeah, I'm also for keeping current model | 14:21 |
| slaweq | so -1 for that RFE | 14:21 |
| ralonsoh | -1 | 14:21 |
| amotoki | -1 too | 14:22 |
| lajoskatona | ok, than I will add link to the logs to launchpad | 14:22 |
| lajoskatona | thanks for the discussion | 14:22 |
| lajoskatona | I am not sure if we have enough votes, let's count it, sorry.... | 14:23 |
| amotoki | I see many important points in this discussions :-) hopefully liu understands the current situation | 14:23 |
| lajoskatona | I think we have 5 -1-s | 14:24 |
| lajoskatona | yeah I think we covered the topic well | 14:24 |
| lajoskatona | We have one topic from ralonsoh in On-Demand agenda | 14:24 |
| lajoskatona | #topic On Demand Agenda | 14:25 |
| ralonsoh | thanks | 14:25 |
| lajoskatona | (ralonsoh): https://review.opendev.org/c/openstack/python-openstackclient/+/819627/1: To deprecate "force" behaviour in OSC "quota" commands. | 14:25 |
| lajoskatona | This is currently the default behaviour in Neutron; what is proposed in this patch is to move Neutron to, by default, | 14:25 |
| ralonsoh | this is related to https://bugs.launchpad.net/neutron/+bug/1936408, but not part of the bug | 14:25 |
| ralonsoh | when I pushed the patch for OSC | 14:25 |
| ralonsoh | a core reviewer proposed to unify the behaviour | 14:25 |
| ralonsoh | that means: Neutron to adopt by default the limit check | 14:26 |
| ralonsoh | same as Nova | 14:26 |
| slaweq | I didn't read logs from our previous discussion but I think I was already for unifying it at some point :) | 14:26 |
| ralonsoh | right! | 14:26 |
| ralonsoh | of course, that needs a period of migration | 14:27 |
| slaweq | or if not, then now I think it's definitely good idea to make it behave the same way for Nova and Neutron | 14:27 |
| ralonsoh | if we accept this, we need to inform during some releases that this behaviour will change | 14:27 |
| obondarev_ | + | 14:27 |
| ralonsoh | so, what do you think? | 14:27 |
| obondarev_ | + for unification | 14:27 |
| ralonsoh | if accepted, I'll open a new LP bug and push a patch with a big warning | 14:28 |
| lajoskatona | just for reference the log from last discussion: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-08-27-14.00.log.html#l-61 | 14:28 |
| amotoki | we have two places to unify the behaviors on quotas: OSC and back-end services. These are separate layers. | 14:28 |
| ralonsoh | right | 14:29 |
| amotoki | I think we can introduce the unified behavior in OSC first | 14:29 |
| ralonsoh | we have this capability now in OSC | 14:29 |
| ralonsoh | we can pass --force | 14:29 |
| ralonsoh | of course, in Neutron will do nothing (for now) | 14:29 |
| amotoki | I think OSC can have three modes: --force, --check-limit (--no-foce), --use-service-default | 14:29 |
| amotoki | the last option honors th ecurrent service default behaviors for backward compat. | 14:30 |
| ralonsoh | I didn't see the last one in OSC, I'll check it | 14:30 |
| amotoki | ralonsoh: this is just my thought right now | 14:30 |
| amotoki | when we consider existing users, we need to provide a migration path | 14:31 |
| ralonsoh | right, this is why I proposed a warning and documenting that | 14:32 |
| ralonsoh | they'll need to add the --force parameter to keep the currently functionality | 14:32 |
| ralonsoh | and we can include this parameter now in the OSC and discard it in Neutron (now) | 14:33 |
| ralonsoh | and then change the behaviour | 14:33 |
| slaweq | ralonsoh who will need to add --force now? | 14:34 |
| ralonsoh | all customers, to be prepared | 14:34 |
| ralonsoh | now this parameter is not needed in neutron | 14:35 |
| slaweq | ok | 14:35 |
| ralonsoh | but we'll accept it just to prepare the migration | 14:35 |
| slaweq | I wasn't sure I understand who is "they" :) | 14:35 |
| slaweq | I'm ok to go with that warning and docs and change default behavior in the future | 14:39 |
| ralonsoh | +1 (I can vote because the proposal is not mine, is stephenfin's proposal) | 14:39 |
| amotoki | I think the first step is to introduce a way to specify a consistent behavior in OSC | 14:40 |
| amotoki | as of now, nova default is to check limits and neutron default is to force to set limits. | 14:40 |
| lajoskatona | yeah +1 to make Nova and Neutron behave similarly | 14:40 |
| ralonsoh | amotoki, right, and we have both options now in the Neutron server | 14:40 |
| amotoki | having both --force and --no-force (--check-limit) in OSC allows us to do so | 14:41 |
| ralonsoh | we'll document this change to be done in next releases | 14:41 |
| ralonsoh | no no | 14:41 |
| ralonsoh | just nothing or --force | 14:41 |
| ralonsoh | those two options, same as in Nova | 14:41 |
| amotoki | ralonsoh: ah, i see | 14:41 |
| ralonsoh | then we'll remove --check-limit | 14:41 |
| ralonsoh | (it will make no sense then) | 14:41 |
| amotoki | but if --force is not specified, the current behavior on neutron quotas is same as --force | 14:42 |
| ralonsoh | right | 14:42 |
| ralonsoh | this is why we need to write a warning about this | 14:42 |
| ralonsoh | if you pass a "quota set" parameter to Neutron without --force (or --check-limit now) | 14:42 |
| ralonsoh | then a warning message will be writen | 14:43 |
| amotoki | so my next question is whether we (OSC) should provide a way to use the current behavior | 14:43 |
| ralonsoh | IMO, in Neutron we should accept now "nothing", --force and --check-limit | 14:43 |
| ralonsoh | and write a warning in nothing is passed | 14:43 |
| amotoki | how about at OSC level? | 14:44 |
| ralonsoh | nothing | 14:44 |
| slaweq | and --force should be "default" behaviour for now, right? | 14:44 |
| ralonsoh | just as is now | 14:44 |
| slaweq | as it's now | 14:44 |
| ralonsoh | no no | 14:44 |
| ralonsoh | OSC just pass the parameters | 14:44 |
| ralonsoh | nothing else | 14:44 |
| ralonsoh | do not introduce any logic inside OSC | 14:44 |
| ralonsoh | this should be the Neutron quota driver | 14:44 |
| ralonsoh | 1) we'll filter out --force (now) and keep the current behaviour | 14:45 |
| ralonsoh | 2) in 2-3 releases, we'll change the behaviour | 14:45 |
| ralonsoh | do you mind if I write a LP bug? | 14:45 |
| ralonsoh | just to save your time | 14:45 |
| ralonsoh | I'll write all steps there | 14:45 |
| amotoki | ralonsoh: sounds fine | 14:46 |
| slaweq | +1 for LP bug with plan of work in releases | 14:46 |
| obondarev_ | thanks ralonsoh | 14:46 |
| amotoki | line-by-line discussion is sometimes confusing :p | 14:46 |
| njohnston | +1 | 14:46 |
| slaweq | and +1 from me for doing that change really :) | 14:46 |
| ralonsoh | thanks all! | 14:46 |
| lajoskatona | +1, and thanks for summarizing it in LP | 14:46 |
| amotoki | yeah, unifying the behavior is the right future without any doubt :) | 14:47 |
| lajoskatona | ok we can close the meeting if there is no more comments or topics to discuss | 14:48 |
| amotoki | ralonsoh: do you mean bug 1936408 by "write a LP bug" above? | 14:48 |
| amotoki | or a new LP bug? | 14:48 |
| ralonsoh | a new one, this is not related | 14:48 |
| amotoki | ralonsoh: thanks. sounds reasonable | 14:49 |
| lajoskatona | Thanks for attending, and for the discussions. | 14:50 |
| slaweq | thx | 14:50 |
| ralonsoh | have a nice weekend! | 14:50 |
| amotoki | thanks all | 14:50 |
| lajoskatona | #endmeeting | 14:50 |
| opendevmeet | Meeting ended Fri Dec 3 14:50:36 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:50 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-12-03-14.01.html | 14:50 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-12-03-14.01.txt | 14:50 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-12-03-14.01.log.html | 14:50 |
| rubasov | o/ | 14:50 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 14:50 |
| slaweq | have a great weekend @all :) | 14:50 |
| lajoskatona | Have a nice weekend | 14:50 |
| obondarev_ | o/ | 14:50 |
| amotoki | o/ | 14:50 |
| opendevreview | Merged openstack/neutron stable/xena: Remove some scenario jobs from the check and gate queues https://review.opendev.org/c/openstack/neutron/+/818715 | 15:14 |
| opendevreview | Merged openstack/neutron master: Move ARM64 jobs to the corresponding zuul queue https://review.opendev.org/c/openstack/neutron/+/819264 | 15:28 |
| opendevreview | Merged openstack/neutron master: Fix links for Source code references https://review.opendev.org/c/openstack/neutron/+/819896 | 15:28 |
| frickler | tobias-urdin: added you to neutron-dynamic-routing-stable-maint, too | 15:59 |
| tobias-urdin | frickler: ack | 16:00 |
| tobias-urdin | thanks! | 16:00 |
| Zer0Byte | hey | 17:26 |
| Zer0Byte | question | 17:26 |
| Zer0Byte | im enable Qos with openvswitch as a port | 17:26 |
| Zer0Byte | is possible do the QoS globally | 17:26 |
| Zer0Byte | between all the nodes | 17:27 |
| Zer0Byte | example | 17:27 |
| Zer0Byte | set 5MB to upload and 5MB to download | 17:27 |
| Zer0Byte | if one vm is using 5mb the other vm have | 17:27 |
| Zer0Byte | try to download share these 5mb | 17:27 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 18:17 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Remove ovsdb_connection singleton for tests https://review.opendev.org/c/openstack/ovsdbapp/+/820398 | 18:17 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Remove ovsdb_connection singleton for tests https://review.opendev.org/c/openstack/ovsdbapp/+/820398 | 19:23 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 19:26 |
| *** tbachman_ is now known as tbachman | 20:55 | |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Remove ovsdb_connection singleton for tests https://review.opendev.org/c/openstack/ovsdbapp/+/820398 | 20:56 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 21:44 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Remove ovsdb_connection singleton for tests https://review.opendev.org/c/openstack/ovsdbapp/+/820398 | 23:25 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Allow functional tests to pass on older OVN w/o IC https://review.opendev.org/c/openstack/ovsdbapp/+/820275 | 23:25 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!