| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-15 | |||
| 16:03:42 | EugenMayer | sean-k-mooney sorry i'am confused. Let met try to explain my dilemma more clearly, maybe you can point me to my mistake. Network A(sub1) and Network B(sub1,sub2) exist. Now i have to options. I disable the gw on B-sub1 so if my instance is in A-sub1 and B-sub1, the default gateway of A-sub1 is used. If i disable that gw, i'am no longer able to | |
| 16:04:05 | sean-k-mooney | then do openstack router add port <router> <port uuid for router_subnet_b_port> | |
| 16:05:10 | sean-k-mooney | EugenMayer: if the gateway is disable i think you have to manually create the port rather then addign the subnet to the router a is descibed above ^ | |
| 16:05:24 | EugenMayer | interesting | |
| 16:05:38 | sean-k-mooney | Zer0Byte: i think you jsut need to restart the compute agent | |
| 16:05:57 | sean-k-mooney | it should try again the next time the perodic runs if your keystone issues are resovled | |
| 16:06:07 | EugenMayer | so i should stick to B sub1/sub2 with gw disabled on sub1 and try to workarround the issue to bridge Bsub1 to Bsub2 | |
| 16:08:12 | sean-k-mooney | so your real issue is that dhcp is going to fight with the default router right | |
| 16:08:25 | sean-k-mooney | normally i fix this with cloud-init manually and set the metic | |
| 16:08:38 | sean-k-mooney | what sound like would be useful would be some way to configure the metric per subnet | |
| 16:09:38 | sean-k-mooney | if you never needed to have two port on the same vm (from both subnets) this woudl not normlay be an issue | |
| 16:11:00 | EugenMayer | well i need that in my case. It is an kubernetes control-plane while A is its 'intranet' for others to access apps internally and also get routed to a floating IP. B is the cluster internal network | |
| 16:12:06 | EugenMayer | sean-k-mooney i'am not sure what your advice is. Try to go with disabling the gw and try adding the port manually or try to use cloud-init to somehow change the metric for DHCP | |
| 16:14:08 | Zer0Byte | @sean-k-mooney restarning the compute agent don;t work also no error on logs :( | |
| 16:15:23 | Zer0Byte | for understand the flow nova-agent (the service isntaled on the compute node) will contact placement directly right | |
| 16:39:09 | hyang[m] | Hi Nova core reviewers, can someone help to check the patch https://review.opendev.org/c/openstack/nova/+/811521? It can resolve a bug that affects both Nova and Neutron. | |
| 16:55:10 | sean-k-mooney | hyang[m]: that is partly a feature and partly a bug | |
| 16:55:30 | sean-k-mooney | i say its partly a feature as support for neutron rbac in nova is a new feature | |
| 16:56:05 | sean-k-mooney | its partly a bug in that that should have been part of the development of security group shareing in neutorn | |
| 16:56:14 | sean-k-mooney | there shoudl have been a sibligh spec to cover the nova changes | |
| 16:56:51 | sean-k-mooney | actully is this a new neutron featfure this cycle | |
| 16:57:07 | sean-k-mooney | if so then you shoudl convert that patch to a blueprint | |
| 16:59:24 | Zer0Byte | is very weird i ssue | |
| 16:59:28 | Zer0Byte | i put the agent on debug | |
| 16:59:38 | Zer0Byte | Final resource view: name=tc-m2mem-compute2-1210 is registering on placement | |
| 16:59:44 | Zer0Byte | but don;t show as a resource | |
| 16:59:50 | sean-k-mooney | hyang[m]: actully this should have a spec or specless bluerpint its a new feature not a bug | |
| 17:00:07 | sean-k-mooney | hyang[m]:this si not something that should be backported | |
| 17:05:35 | bauzas | folks, gentle reminder that tomorrow is spec review day | |
| 17:05:38 | bauzas | sharpen your pens | |
| 17:06:18 | gibi | bauzas: good reminder | |
| 17:06:20 | gibi | thanks | |
| 17:07:40 | bauzas | gibi: you can thank sean-k-mooney for ringing me a bell in my empty closet that's called "a brain" | |
| 17:07:51 | gibi | sean-k-mooney: thanks | |
| 17:07:52 | gibi | :D | |
| 17:08:13 | sean-k-mooney | as i said downstream the only reason i rememebred is i tought i missed it last week so i checked :) | |
| 17:09:39 | gibi | bauzas: I think you can abandon these https://review.opendev.org/q/project:openstack/nova-specs+status:open+label:Code-Review-2 as all of them are heavily outdated | |
| 17:10:12 | gibi | just to have a clean spec list for tomorrow | |
| 17:11:46 | Zer0Byte | any another idea @sean-k-mooney ? | |
| 17:16:05 | sean-k-mooney | Zer0Byte: have you tried openstack resource provider list --name tc-m2mem-compute2-1210 | |
| 17:16:31 | Zer0Byte | got a empty response | |
| 17:16:53 | sean-k-mooney | Zer0Byte: assuming this is libvirt what does virsh hostname return | |
| 17:17:12 | sean-k-mooney | does it have a domain appended to it? | |
| 17:17:18 | Zer0Byte | no | |
| 17:17:29 | Zer0Byte | im using juju to install the compute nodes | |
| 17:17:43 | Zer0Byte | so the configuration is always persistent | |
| 17:18:05 | sean-k-mooney | ok libvirt via the python bindign provides the hostname to nova which we use for the RP name | |
| 17:18:22 | Zer0Byte | in this case we should have a empty record with id right? | |
| 17:18:27 | Zer0Byte | uuid | |
| 17:19:01 | sean-k-mooney | well we should have a resouce provider with the hostname as the name and the compute node uuid( not the compute service uuid) as the uuid | |
| 17:19:18 | sean-k-mooney | and then if you do an inventory list you shoudl see the reouces that are tracked | |
| 17:19:25 | sean-k-mooney | so cpu ram disk ectra | |
| 17:20:09 | sean-k-mooney | Zer0Byte: if you are not seeing the RP in placment then you should be sing an error in the compute agent log trying to create the RP at some point | |
| 17:20:26 | Zer0Byte | yeah from the other nodes yes | |
| 17:21:01 | Zer0Byte | i can see the usage form inventory | |
| 17:23:10 | Zer0Byte | my doubt here is how nova is "reporting allocations" to placement without a RP uuid | |
| 17:23:22 | Zer0Byte | or to a non visible RP | |
| 17:23:40 | Zer0Byte | Instance 21a17b74-400f-4dce-99ed-555e1ae80512 actively managed on this compute host and has allocations in placement: {'resources': {'VCPU': 8, 'MEMORY_MB': 65536}}. _remove_deleted_instances_allocations /usr/lib/python3/dist-packages/nova/compute/resource_tracker.py:1538 | |
| 17:25:16 | EugenMayer | sean-k-mooney thank you for that metric trick with cloud-init. Surely not perfect since it makes the entire instance very topology aware, but i guess that info leaked into it never the less | |
| 17:27:54 | sean-k-mooney | well normally the netowrks routers and isntance are created by the tenant | |
| 17:28:01 | sean-k-mooney | so they are creating that toplogy themselves | |
| 17:28:21 | sean-k-mooney | in your case its sligly different since you are migrating/addpoting workload form your previous enviornment | |
| 17:28:55 | sean-k-mooney | i wonder if dhcp has the concept of a metiric it can pass | |
| 17:29:11 | sean-k-mooney | if so it might be worth wile asking neutron to support setting that via the subnet | |
| 17:29:33 | Zer0Byte | i will try something @sean-k-mooney the uuid from RP is auto generated or is from the ocmpute host? | |
| 17:29:34 | sean-k-mooney | it would be nice if you could jsut declare that via the subnet and not need to do it per instance | |
| 17:29:56 | sean-k-mooney | Zer0Byte: its autogenerate when the compute agent first connect to the db | |
| 17:30:25 | sean-k-mooney | Zer0Byte: you can fined it if you have access to the db by looking at the compute_nodes table in the cell db | |
| 17:30:35 | Zer0Byte | ok i wil try that | |
| 17:30:36 | sean-k-mooney | or you can get it via the rest api vai the hyperviors api | |
| 17:30:50 | Zer0Byte | recreate manually the rp | |
| 17:31:13 | Zer0Byte | to see if after i generate it i can get the allocations that the compute node is reporting | |
| 17:31:47 | EugenMayer | i'll try sean-k-mooney | |
| 17:33:03 | sean-k-mooney | to create the allocation i think you whould have to run the allcoation audit or heal allocation nova/placment manage commands | |
| 17:38:03 | EugenMayer | interesting, there is extra_dhcp_option on the port | |
| 17:38:13 | EugenMayer | https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/resources/networking_port_v2#extra_dhcp_option | |
| 17:41:14 | EugenMayer | also here | |
| 17:41:15 | EugenMayer | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/port.html | |
| 17:41:46 | dasp | question: if I want to make a constant hardcoded in nova a configurable value instead, would tha require a spec or not? | |
| 17:47:33 | dmitriis | sean-k-mooney, gibi: I'll be around tomorrow for the spec review day in case you don't have time for a re-review until then (I resubmitted the spec so the approvals are gone) | |
| 17:48:10 | Zer0Byte | well recreted the record but still n data on it | |
| 17:48:17 | hyang[m] | sean-k-mooney: got it, thanks for your review. I'll add a blueprint for https://review.opendev.org/c/openstack/nova/+/811521. Regarding your comment https://review.opendev.org/c/openstack/nova/+/811521/comment/6954e488_0d70cd6e/ do you think the additional request in nova is acceptable given the current Neutron API behavior or the Neutron API behavior must be changed first (I'm not sure if it is possible)? | |
| 17:57:01 | Zer0Byte | @sean-k-mooney if the node appears as service in nova service probably will don't try to register on placement? | |
| 17:58:56 | opendevreview | Daniel Speichert proposed openstack/nova master: conf: add [libvirt]/no_compression_image_types = qcow2 https://review.opendev.org/c/openstack/nova/+/817995 | |
| 17:59:13 | Zer0Byte | ohh | |
| 17:59:18 | Zer0Byte | i see what happening | |
| 17:59:22 | Zer0Byte | checking on placement database | |
| 17:59:46 | Zer0Byte | as resouce_provider_id i have id 1 | |
| 18:00:08 | Zer0Byte | and the instance reported by the affected node is saving as ID 1 | |
| 18:00:10 | Zer0Byte | :s | |
| 18:34:21 | sean-k-mooney | hyang[m]: the addtional request is proably workabole but really since this is a new exttion being added this cycle i woudl jsut change it now before addign the nova support | |
| 18:34:45 | sean-k-mooney | hyang[m]:without another exteion we wont be abel to detech support for usign a signel query | |
| 18:48:18 | sean-k-mooney | hyang[m]: im going to call it a day. tl;dr if this api had already shipped in an upstream release of neutron (not neutron-lib) then i would ahve suggested addign ascond extention for the more effeicnt query but since it has not shipped yet i think we shoudl just fix it and hold the neutorn-lib release until that is done | |
| 19:11:16 | hyang[m] | sean-k-mooney: the neutron api extension and related server code is already released in both neutron-lib and neutron https://review.opendev.org/c/openstack/neutron-lib/+/812617 https://review.opendev.org/c/openstack/neutron/+/811242. Since the behavior using shared=true for SGs is same as other existing resources in Neutron like networks, I'm not sure if Neutron team will want to change it (and change for all the resources apis). | |
| 19:12:34 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova-specs master: Integration With Off-path Network Backends https://review.opendev.org/c/openstack/nova-specs/+/787458 | |
| 19:41:49 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova-specs master: Integration With Off-path Network Backends https://review.opendev.org/c/openstack/nova-specs/+/787458 | |
| 19:50:43 | Zer0Byte | alright | |
| 19:50:46 | Zer0Byte | i found the issue | |
| 19:51:31 | Zer0Byte | @sean-k-mooney i have two regions and by mistake someone when provisioning put placement on the second region as regionone | |
| 19:51:39 | Zer0Byte | now the issue is solved | |