| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-15 | |||
| 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 | |
| 19:51:47 | Zer0Byte | also changed the endpoints url | |
| 19:52:10 | Zer0Byte | but nova-agent is still trying to connect to second region placement | |
| 20:09:41 | Zer0Byte | found the bug | |
| 20:09:44 | Zer0Byte | =) | |
| 21:04:30 | opendevreview | Artom Lifshitz proposed openstack/nova master: api-ref: server rescue adminPass injection is conf-dependant https://review.opendev.org/c/openstack/nova/+/818022 | |
| 21:19:46 | opendevreview | Daniel Speichert proposed openstack/nova master: conf: add [libvirt]/no_compression_image_types = qcow2 https://review.opendev.org/c/openstack/nova/+/817995 | |
| 21:25:53 | opendevreview | Daniel Speichert proposed openstack/nova master: conf: add [libvirt]/no_compression_image_types = qcow2 https://review.opendev.org/c/openstack/nova/+/817995 | |
| #openstack-nova - 2021-11-16 | |||
| 00:59:36 | sean-k-mooney | hyang[m]: its merged its not relaease yet | |
| 03:52:46 | opendevreview | melanie witt proposed openstack/nova master: Poison usage of eventlet spawn_n() in tests https://review.opendev.org/c/openstack/nova/+/818042 | |
| 07:10:12 | EugenMayer | It seems like the first boot of an instance (with cloud-init) has diffenret results in network then all the other after that. Is that desired? | |
| 07:47:40 | EugenMayer | am I right that using --user-data has 2 flavours, using it with --config-drive true will expect to have meta-data alike content there, without using config-drive yaml based cloud-init files are expected. So the same --user-data for 2 different subsystems on init? | |
| 07:48:12 | EugenMayer | (reading https://docs.openstack.org/nova/queens/user/config-drive.html) | |
| 08:03:22 | gibi_ | o/ morning nova | |
| 08:40:04 | bauzas | good spec review day, Nova | |
| 09:13:10 | opendevreview | Merged openstack/nova-specs master: Repropose flavour and image defined ephemeral storage encryption https://review.opendev.org/c/openstack/nova-specs/+/810867 | |
| 09:33:05 | jengbers | We have been adding servers to server groups by changing the database and the scheduler has always handled this well. | |
| 09:33:05 | jengbers | Morning, I have been searching OpenStack history, but I haven't been able to find why it is not possible to add existing instances to server groups. Does anyone know if that is just never discussed or if there is a fundamental technical problem? | |
| 09:38:38 | gibi | jengbers: the problem is consistency. When you add a server to a group then you can create a situation when the group membership and the actaul placement of the instance contradicts | |
| 09:38:54 | gibi | and the question is what to do then | |
| 09:39:01 | gibi | a) move the instance to restore consistency | |