Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-11-15
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)?
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

Earlier   Later