Earlier  
Posted Nick Remark
#openstack-nova - 2021-11-15
15:56:12 EugenMayer sean-k-mooney my problem is with the default gateway pushed, if an instance has 2 interfaces which both have a gateway
15:56:49 sean-k-mooney right that is a common problem
15:56:57 sean-k-mooney you can disable the gateway on the subnet
15:57:17 sean-k-mooney which should prevent that
15:58:53 sean-k-mooney EugenMayer: i think you do "openstack subnet unset --gateway <subnet>"
15:59:00 EugenMayer sean-k-mooney yes, that is what i did, then i cannot route Bsub1 to Bsub2 - you cannot add the interface
15:59:21 EugenMayer if a subnet has not gateway, it cannot be added to the router to route to the subnets
15:59:30 sean-k-mooney you can add the interface but you have to specify the ip manually to be what would be the normal gateway ip
15:59:59 EugenMayer so you mean override the gateway via cloud-init?
16:00:04 sean-k-mooney so when adding the router interface you will need to give it the .1 address or whatever adress is correct for the cidr
16:00:08 sean-k-mooney no
16:00:17 sean-k-mooney do openstack subnet unset --gateway <subnet b>
16:00:18 Zer0Byte "title": "Service Unavailable"}.
16:00:18 Zer0Byte RROR nova.scheduler.client.report [req-4d4167be-e58d-42eb-bf49-ffeb0a21d42c - - - - -] [req-6400ff72-11e0-4953-9980-463cfacf7df1] Failed to retrieve resource provider tree from placement API for UUID 1c684ec9-6ab2-4ef7-8451-c989a0b90f45. Got 503: {"message": "The server is currently unavailable. Please try again at a later time.<br /><br />\nThe Keystone service is temporarily unavailable.\n\n", "code": "503 Service Unavailable",
16:00:23 Zer0Byte is exactly what i suspect
16:00:47 Zer0Byte now my question is how i force the node to populate on placement
16:03:36 sean-k-mooney then do "openstack port create --network <my net> --fixed-ip subnet=<subnet>,ip-address=192.168.2.1 router_subnet_b_port"
16:03:42 EugenMayer create a neutron router to bridge between B-sub1 and B-sub2, since a gateway in B-sub1 seems to be required for that
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)?

Earlier   Later