| opendevreview | Miguel Lavalle proposed openstack/neutron master: [DNM] Fix support of IPv6 only networks in OVN metadata agent https://review.opendev.org/c/openstack/neutron/+/922264 | 00:39 |
|---|---|---|
| opendevreview | Miguel Lavalle proposed openstack/neutron master: [DNM] Fix support of IPv6 only networks in OVN metadata agent https://review.opendev.org/c/openstack/neutron/+/922264 | 00:41 |
| opendevreview | yatin proposed openstack/neutron stable/2024.1: [FT] Run test_periodic_sync_routers_task tests serially https://review.opendev.org/c/openstack/neutron/+/922280 | 04:30 |
| opendevreview | yatin proposed openstack/neutron stable/2023.2: [FT] Run test_periodic_sync_routers_task tests serially https://review.opendev.org/c/openstack/neutron/+/922281 | 04:30 |
| opendevreview | yatin proposed openstack/neutron stable/2023.1: [FT] Run test_periodic_sync_routers_task tests serially https://review.opendev.org/c/openstack/neutron/+/922282 | 04:34 |
| ralonsoh | slaweq, quick question: do we allow remote policy enforcers in openstack? | 07:25 |
| ralonsoh | --> https://bugs.launchpad.net/neutron/+bug/2069071 | 07:25 |
| ralonsoh | this is the first time I see that and I don't see anything in the documentation | 07:25 |
| ralonsoh | but maybe I'm wrong | 07:25 |
| ralonsoh | e.g.: "create_port:allowed_address_pairs": "http://127.0.0.1:8181/enforce" | 07:26 |
| zigo | # openstack subnet pool unset --pool-prefix 2001:x:y:z::/56 <ID> | 07:42 |
| zigo | usage: openstack subnet pool unset [-h] [--tag <tag> | --all-tag] <subnet-pool> | 07:42 |
| zigo | openstack subnet pool unset: error: unrecognized arguments: --pool-prefix <id> | 07:42 |
| zigo | WTF ?!? Is openstackclient broken with subnet pool unset ? | 07:42 |
| zigo | I had to do with Curl, that's not nice ... :/ | 07:48 |
| zigo | Is it known, or should I open a bug? | 07:48 |
| ralonsoh | zigo, https://review.opendev.org/c/openstack/python-openstackclient/+/599633 | 07:51 |
| ralonsoh | the documentation is incorrect in https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/subnet-pool.html | 07:51 |
| ralonsoh | from the revert commit message: "We do not support removing a prefix from a subnet pool, only updating | 07:52 |
| ralonsoh | with a larger prefix (which is handled by the set command)" | 07:52 |
| ralonsoh | it is a documentation bug, for sure | 07:52 |
| zigo | ralonsoh: Well, with Curl, I successfully was able to remove my ipv6 range... | 07:52 |
| ralonsoh | right, you can create and update a subnet pool | 07:54 |
| ralonsoh | and the update command will delete the current pool prefixes and create the provided ones | 07:55 |
| ralonsoh | but this is why the OSC do not allow to remove a pool prefix | 07:55 |
| ralonsoh | that could be also a bug for Neutron: if we don't allow to remove an existing pool prefix (only increase it), we should prevent that from the API | 07:56 |
| ralonsoh | but the OSC behaviour is correct | 07:56 |
| zigo | Why can't we remove pool-prefix? Is some part of the implementation missing? | 08:00 |
| ralonsoh | because the IP could be used | 08:00 |
| zigo | In my case, my network guy just did a mistake with the ranges... | 08:00 |
| ralonsoh | one IP of this pool prefix | 08:00 |
| zigo | Ok, so the *check* is missing from neutron, right? | 08:01 |
| zigo | IMO, we should still impelement it in openstackclient, and add a big warning in the doc, until the check is implemented. | 08:01 |
| ralonsoh | yes, we currently don't do it. This is why we don't support the removal. But even with that, the current update API method is incorrect if that allows a manual created call removing an existing prefix | 08:02 |
| zigo | Well, it worked out for me, and I'm happy it did. If it didn't, I would have edited the db by hand ... | 08:02 |
| zigo | In any case, thanks for your input. I'll see if I can at least contribute some doc about this. | 08:05 |
| zigo | ralonsoh: Since when do we have https://launchpad.net/bugs/2069581 ? Like forever ? | 09:26 |
| zigo | Oh, saw it. | 09:27 |
| zigo | Since https://review.opendev.org/c/openstack/neutron/+/825521 | 09:27 |
| zigo | So Victoria isn't affected, righ? | 09:27 |
| ralonsoh | no no, there are other plugin workers | 09:28 |
| ralonsoh | created when the ML2 plugin is initialized | 09:28 |
| zigo | Does this then spawn workers within the neutron-rpc-server service? | 09:28 |
| ralonsoh | no, the rpc-server only creates the RPC worker(s) | 09:29 |
| ralonsoh | there are PeriodicWorker added during the initialization | 09:29 |
| ralonsoh | one sec | 09:29 |
| zigo | So how are the works spawn, since I'm using uwsgi?!? | 09:29 |
| zigo | *workers | 09:30 |
| ralonsoh | I guess you are using ml2/ovs, right? | 09:30 |
| zigo | Yes. | 09:30 |
| ralonsoh | and what tool to deploy it? | 09:30 |
| ralonsoh | because devstack had a bug | 09:30 |
| zigo | My own: https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer | 09:30 |
| zigo | that's puppet-openstack based. | 09:30 |
| ralonsoh | so when using the eventlet based server | 09:32 |
| ralonsoh | https://github.com/openstack/neutron/blob/master/neutron/server/wsgi_eventlet.py#L24-L25 | 09:32 |
| ralonsoh | we create the (1) API workers and the (2) RPC workers | 09:32 |
| ralonsoh | but the second is not totally correct | 09:32 |
| ralonsoh | because we call neutron.service:start_all_workers | 09:33 |
| ralonsoh | that will spawn the RPC workers and what is called plugin workers (the periodic ones) | 09:33 |
| ralonsoh | we currently have 3 | 09:33 |
| ralonsoh | https://github.com/openstack/neutron/blob/466f5e6f1afc12f61d073a0c4e3e4774feb4a7cb/neutron/db/l3_db.py#L170 | 09:33 |
| ralonsoh | https://github.com/openstack/neutron/blob/466f5e6f1afc12f61d073a0c4e3e4774feb4a7cb/neutron/db/agentschedulers_db.py#L104 | 09:33 |
| ralonsoh | https://github.com/openstack/neutron/blob/466f5e6f1afc12f61d073a0c4e3e4774feb4a7cb/neutron/db/quota/driver_nolock.py#L103 | 09:33 |
| zigo | I'm using separated neutron-rpc-server and neutron-api (running over uwsgi, without any web server in front, just haproxy). So I'm not affected then? | 09:34 |
| ralonsoh | the plugin workers are wrapped inside ``AllServicesNeutronWorker``, that takes all these workers. This class is spawned as a single process and the periodic workers as threads | 09:34 |
| ralonsoh | zigo, yes you are | 09:34 |
| zigo | :/ | 09:35 |
| ralonsoh | because this ``AllServicesNeutronWorker`` is not spawned | 09:35 |
| ralonsoh | this is what I added in (one sec) | 09:35 |
| zigo | ralonsoh: Will you backport https://review.opendev.org/c/openstack/neutron/+/825521 to stable releases then? | 09:35 |
| ralonsoh | no, this is not needed | 09:35 |
| ralonsoh | this is related to the quota driver | 09:35 |
| ralonsoh | what is needed is this: | 09:36 |
| zigo | Ah ok, so only Caracal? Or not even? | 09:36 |
| ralonsoh | 1) https://review.opendev.org/c/openstack/neutron/+/922090 | 09:36 |
| ralonsoh | 2) https://review.opendev.org/c/openstack/neutron/+/922110/ | 09:36 |
| ralonsoh | 3) (devstack) https://review.opendev.org/c/openstack/devstack/+/922125 | 09:36 |
| ralonsoh | ^^ or the tool deploying the env | 09:36 |
| zigo | Oh, so we need to run a new service called neutron-services-server ? | 09:37 |
| zigo | Like, 1 per controller ? | 09:37 |
| ralonsoh | yes, this is the one that spawns the ``AllServicesNeutronWorker`` class | 09:37 |
| ralonsoh | yes, 1 per controller | 09:37 |
| zigo | Ok, but then, how far in releases? Just Caracal, or earlier ? | 09:37 |
| ralonsoh | I'll backport the Neutron patches up to Antelope, that is the oldest branch under maintenance | 09:38 |
| zigo | Allright, so I'll probably need backporting it myself up to Victoria (as Debian Bullseye is still under maintenance on Debian side). | 09:39 |
| zigo | Thanks. | 09:40 |
| zigo | ralonsoh: There's no "neutron-services-server" console script in setup.cfg ... :/ | 09:40 |
| ralonsoh | it is now | 09:41 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/922110/1/setup.cfg | 09:41 |
| ralonsoh | or it will be after this patch is merged | 09:41 |
| zigo | Thanks. I'll prepare a patch for puppet-neutron then. | 09:43 |
| zigo | Well, will do the necessary things in the Neutron Debian package first though! :) | 09:43 |
| zigo | ralonsoh: IMO, using "services-server" as a name is very annoying. I would have prefer "worker" or "engine" something like that. | 11:24 |
| ralonsoh | zigo, you can comment in the patch | 11:24 |
| zigo | In puppet, I have unreadable code like: | 11:24 |
| zigo | Service['neutron-server'] -> Service['neutron-services-server'] | 11:24 |
| ralonsoh | this is following the current naming convention | 11:24 |
| zigo | Well, I'd also prefer if it wasn't changing over time, as I already uploaded the fixed debian package ! :) | 11:24 |
| ralonsoh | it could be just neutron-services | 11:25 |
| zigo | The point is: do not use "service" in the name it's very annoyingly clashing with systemd ".service" concept. | 11:25 |
| zigo | engine, worker, central, etc. do work out better, IMO. | 11:26 |
| opendevreview | Merged openstack/neutron unmaintained/xena: [unmaintained] Drop rally jobs https://review.opendev.org/c/openstack/neutron/+/922231 | 12:32 |
| opendevreview | Merged openstack/neutron master: [OVN] Sanitize the classless-static-route DHCP option https://review.opendev.org/c/openstack/neutron/+/922119 | 13:34 |
| opendevreview | Lucas Alvares Gomes proposed openstack/neutron stable/2024.1: [OVN] Sanitize the classless-static-route DHCP option https://review.opendev.org/c/openstack/neutron/+/922323 | 13:40 |
| opendevreview | Lucas Alvares Gomes proposed openstack/neutron stable/2023.2: [OVN] Sanitize the classless-static-route DHCP option https://review.opendev.org/c/openstack/neutron/+/922324 | 13:40 |
| opendevreview | Lucas Alvares Gomes proposed openstack/neutron stable/2023.1: [OVN] Sanitize the classless-static-route DHCP option https://review.opendev.org/c/openstack/neutron/+/922325 | 13:40 |
| zigo | Trying to perform live-migration on Caracal, I'm getting issues about the default policy set. I tried fixing the default policy, and now I have: | 14:36 |
| zigo | "create_port_binding": "(rule:admin_api) or (rule:service_api)" | 14:36 |
| zigo | "delete_port_binding": "(rule:admin_api) of (rule:service_api)" | 14:36 |
| zigo | "activate": "(rule:admin_api) or (rule:service_api)" | 14:36 |
| zigo | After doing this, then now I can do a live-migration in one direction, but I'm still getting a stack dump with: | 14:36 |
| zigo | oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/nova/network/neutron.py", line 214, in wrapper | 14:36 |
| zigo | oslo_messaging.rpc.server raise exception.Forbidden(str(e)) | 14:36 |
| zigo | oslo_messaging.rpc.server nova.exception.Forbidden: rule:delete_port_binding is disallowed by policy | 14:36 |
| zigo | oslo_messaging.rpc.server Neutron server returns request_ids: ['req-da68ad41-de4d-41cd-b52d-2a7d9c5fb052'] | 14:36 |
| zigo | oslo_messaging.rpc.server | 14:36 |
| zigo | and then, it's impossible to live-migrate the VM the other way around. | 14:36 |
| zigo | So 2 questions: - is there some issues with the default policy? How come I had to do the above? | 14:36 |
| zigo | - how come I'm getting this stack dump when I have allowed rule:delete_port_binding? How to fix? | 14:36 |
| ralonsoh | zigo, https://review.opendev.org/c/openstack/neutron/+/886724 | 14:39 |
| ralonsoh | in Caracal, these commands can be performed by a service only (Nova) | 14:39 |
| ralonsoh | but I don't know how is called from Nova (if this call is using the service user) | 14:40 |
| zigo | ralonsoh: Oh, so I need to add the role service_api to my nova and neutron users, then, probably ... | 14:42 |
| zigo | Will try thanks. | 14:42 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [eventlet] Remove eventlet from the OVN metadata agent https://review.opendev.org/c/openstack/neutron/+/922329 | 14:44 |
| mnaser | https://review.opendev.org/c/openstack/neutron/+/921035 -- appreciate if someone can get this merged please :) | 14:45 |
| zigo | Ah no, role should be "service" ... | 14:46 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [eventlet] Remove eventlet from the Neutron metadata agent https://review.opendev.org/c/openstack/neutron/+/922330 | 14:57 |
| opendevreview | Merged openstack/neutron stable/2024.1: [FT] Run test_periodic_sync_routers_task tests serially https://review.opendev.org/c/openstack/neutron/+/922280 | 15:30 |
| opendevreview | Merged openstack/neutron stable/2023.2: [FT] Run test_periodic_sync_routers_task tests serially https://review.opendev.org/c/openstack/neutron/+/922281 | 15:30 |
| stephenfin | ralonsoh: I don't think this will work https://review.opendev.org/c/openstack/neutron/+/922185 ? | 15:46 |
| stephenfin | We added a neutron.wsgi module in https://review.opendev.org/c/openstack/neutron/+/916407/ | 15:46 |
| stephenfin | I'm pretty sure Python ignores 'foo/bar.py' if 'foo/bar/__init__.py' is present | 15:47 |
| stephenfin | so wsgi.py will be ignored because wsgi/__init__.py exists | 15:47 |
| stephenfin | A quick tests and this SO post suggests that is the case https://stackoverflow.com/questions/6393861/how-python-deals-with-module-and-package-having-the-same-name | 15:48 |
| stephenfin | ihrachys_: ykarel__: ^ | 15:50 |
| stephenfin | oh, gtema too ^ (we probably want to pull that out of the merge queue) | 15:51 |
| bcafarel | mnaser: done! | 15:51 |
| opendevreview | Artem Goncharov proposed openstack/neutron master: Restore neutron.wsgi for backwards compatibility https://review.opendev.org/c/openstack/neutron/+/922185 | 15:51 |
| gtema | uhm, that means my fix need to be redone, and it is in the queue since 1 day already | 15:52 |
| frickler | just move it to neutron/wsgi/__init__.py instead? | 15:56 |
| stephenfin | frickler: yes, but you can't stick the warning in there as-is because you'll get warnings if you try to import the wsgi module for e.g. uWSGI purposes | 15:58 |
| stephenfin | so we probably want to do the warning bit separately if this is house-on-fire stuff rn | 15:58 |
| frickler | ah, right | 15:58 |
| gtema | I'l just drop the warning as such. It is anyway a very temporary step | 15:59 |
| frickler | unrelated, the failure on the n-d-r fix seems unrelated https://zuul.opendev.org/t/openstack/build/439b0bf301224efc83c87b9ef4bd06ed looks like some option might have gotten dropped from sqla? will need to look deeper tomorrow | 15:59 |
| gtema | frickler: not really. This is what surprised me a lot - look at the failed py312 job | 16:00 |
| gtema | https://zuul.opendev.org/t/openstack/build/77ef4b730e6d42d58f4125f157a9c7a5 | 16:00 |
| gtema | it is exactly due to the moved module. And surprising is the fact that none other job failed same way. This is precisely what I get running tests/pep locally | 16:01 |
| opendevreview | Artem Goncharov proposed openstack/neutron master: Restore neutron.wsgi for backwards compatibility https://review.opendev.org/c/openstack/neutron/+/922185 | 16:02 |
| frickler | gtema: I'm not talking about the unit test, but the integration test. the py312 job is n-v so I ignored it so far | 16:02 |
| gtema | correct, but it is failing as expected and I am wondering that other py jobs didn't fail | 16:03 |
| mnasiadka | Hello | 16:04 |
| mnasiadka | Is there an option to set custom dhcp options per network/subnet? E.g. ntp server? | 16:04 |
| frickler | ImportError: cannot import name 'wsgi' from 'neutron.api' (/home/zuul/src/opendev.org/openstack/neutron-dynamic-routing/.tox/py312/lib/python3.12/site-packages/neutron/api/__init__.py) | 16:05 |
| frickler | is this the same error that stephenfin mentioned? is there a difference between "from neutron.api import wsgi" and "import neutron.api.wsgi as wsgi"? | 16:05 |
| gtema | it's not about that itself. It is about the fact that neutron.api does not have wsgi (released) yet - and this is expected, since change is not released yet | 16:06 |
| gtema | other jobs apparently use the tips of neutron | 16:07 |
| frickler | mnasiadka: afaict this is only per port | 16:09 |
| frickler | gtema: ah, ok, now I understand the "missing release" issue. so why not do "try: import neutron.api.wsgi except ... import neutron.wsgi" to cover both variants? | 16:12 |
| gtema | feels ugly and will require another change removing this after release | 16:13 |
| gtema | frickler: since this is the only job and it is non-voting there is no problem landing the change even before the neutron release. Still I would like to have neutron fixed till next release since not every job is installing extensions from tips | 16:14 |
| mnasiadka | frickler: ugh | 16:26 |
| *** dasm is now known as Guest10177 | 17:13 | |
| *** iurygregory_ is now known as iurygregory | 21:28 | |
| opendevreview | Merged openstack/neutron unmaintained/yoga: [unmaintained] Drop rally jobs https://review.opendev.org/c/openstack/neutron/+/922230 | 22:05 |
| opendevreview | Merged openstack/neutron unmaintained/zed: [ML2/OVN] Add gateway_port support for FIP https://review.opendev.org/c/openstack/neutron/+/921035 | 23:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!