| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-30 | |||
| 12:45:02 | openstackgerrit | Merged openstack/nova master: Add a lock to prevent race during detach/attach of interface https://review.opendev.org/747957 | |
| 12:55:43 | openstackgerrit | Merged openstack/nova master: QEMU/KVM: accept vmxnet3 NIC https://review.opendev.org/738695 | |
| #openstack-nova - 2020-08-31 | |||
| 01:18:36 | openstackgerrit | Keigo Noha proposed openstack/nova stable/ussuri: Change default num_retries for glance to 3 https://review.opendev.org/748936 | |
| 02:20:01 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Coding style and test cases improvment https://review.opendev.org/748939 | |
| 02:22:22 | openstackgerrit | Tony Su proposed openstack/nova master: Provider Config File: Coding style and test cases improvement https://review.opendev.org/748939 | |
| 07:21:43 | swp20 | gibi: hi gibi, morning. | |
| 07:23:34 | swp20 | I have a question: As we donnot delete allocations when evacuate, so this case `nova.tests.functional.wsgi.test_services.TestServicesAPI.test_evacuate_then_delete_compute_service` is not reasonable, right? | |
| 07:35:59 | gibi | swp20: the source host allocation is not deleted during evacuation. It is left for the source host to delete it when it is recovered. If the source host is never recovered but deleted instead then we might need to delete the source side of the allocation of successfull evacuations | |
| 07:40:08 | gibi | swp20: alternatively we can reject the service delete if there is allocations against the RP due to finished evacuations | |
| 07:41:34 | gibi | and ask the admin to clean that up manually before delete the service | |
| 07:41:44 | swp20 | so how can we process the exception when we delete rp failed? we cannot raise the exception. | |
| 07:42:19 | swp20 | please see the patch: https://review.opendev.org/#/c/748339/ | |
| 07:42:48 | bauzas | good morning | |
| 07:43:30 | gibi | swp20: I will check | |
| 07:43:34 | gibi | bauzas: good morning | |
| 07:43:59 | swp20 | gibi: thanks | |
| 07:54:38 | suryasingh | @gibi hi... Sorry to address directly. Do you know if graceful shutdown of nova-compute is supported from nova side (For ex: like SIGTERM send to nova-compute to stopped in the middle of instance boot operation) | |
| 07:59:44 | gibi | suryasingh: hi! good questions. I'm not sure. | |
| 08:01:45 | gibi | suryasingh: looking at the nova.service.Service impl, I don't see specific implementtin | |
| 08:02:22 | gibi | nova.service.Service.stop just stops the RPC service and then calls manager.clean_up | |
| 08:03:06 | gibi | we do cancel ongoing live migration though | |
| 08:03:16 | gibi | via nova.compute.manager.ComputeManager._cleanup_live_migrations_in_pool | |
| 08:03:27 | gibi | but I don't see any more gracefullness | |
| 08:05:51 | suryasingh | I see gibi, Thanks for response though. | |
| 08:09:25 | gibi | suryasingh: if you would need more gracefullness the I suggest to describe you use case in a mail on the mailing list or in a nova specification | |
| 08:11:56 | suryasingh | gibi: thanks for info. I will do once feel require to mail. | |
| 08:12:14 | bauzas | gibi: suryasingh: we just hook the SIGHUP signal | |
| 08:12:22 | bauzas | hook up* | |
| 08:12:38 | bauzas | we don't indeed have any other signal for a graceful restart | |
| 08:13:04 | bauzas | but operators just disable the service before they restart | |
| 08:13:17 | bauzas | so they don't need to wait | |
| 08:23:53 | bauzas | gibi: IIRC, oslo.service also waits gracefully | |
| 08:24:02 | brinzhang | gibi, stephenfin: Fixed stephenfin's comments inline in Cyborg evacuate patch, hope you can review again https://review.opendev.org/#/c/715326/ | |
| 08:24:28 | bauzas | https://docs.openstack.org/oslo.service/ocata/history.html#id17 | |
| 08:24:32 | bauzas | gibi: ^ | |
| 08:24:35 | bauzas | suryasingh: ^ | |
| 08:25:24 | frickler | bauzas: I have two question regarding https://bugs.launchpad.net/neutron/+bug/1861401: a) is "hostname is immutable" documented somewhere? nearest thing I found is https://bugs.launchpad.net/nova/+bug/1068154 | |
| 08:25:24 | openstack | Launchpad bug 1861401 in OpenStack Compute (nova) "Renaming instance brokes DNS integration" [Low,Opinion] | |
| 08:25:25 | openstack | Launchpad bug 1068154 in OpenStack Compute (nova) "Renaming Instance Name doesn't change hostname on a Rebuild" [Wishlist,Opinion] | |
| 08:25:39 | frickler | and b: is it possible to retrieve the original hostname via the API? | |
| 08:26:05 | bauzas | suryasingh: gibi: https://docs.openstack.org/oslo.service/latest/reference/service.html#oslo_service.service.Service.stop | |
| 08:26:58 | bauzas | frickler: looking | |
| 08:27:43 | suryasingh | bauzas: thanks for heads up, sorry i couldn't get much. How disabling benefits in graceful shutdown ? >> so they don't need to wait ? | |
| 08:28:11 | bauzas | suryasingh: by disabling the service, you avoid having instances be going to it | |
| 08:28:33 | suryasingh | bauzas: yes that's correct | |
| 08:28:53 | bauzas | suryasingh: so, then, when restarting the compute service, the instances are not restarted | |
| 08:29:40 | frickler | bauzas: ah, for b) I found OS-EXT-SRV-ATTR:hostname, though it's admin-only by default, which kind of restricts it's usefulness | |
| 08:30:07 | bauzas | frickler: corrrect, but you can change the policy | |
| 08:30:37 | bauzas | frickler: I mean, it's a cloud API, right ? :) | |
| 08:30:53 | bauzas | so that's why it's defaulted to No | |
| 08:31:09 | suryasingh | bauzas: what about on going instance booting process, suppose i disabled the nova-compute even before nova-compute gets net-id, or requested volume or object from other openstack services (neutron, cinder, swift) | |
| 08:31:58 | bauzas | frickler: for the first question, it's because we have persisted objects that use the name for knowing which compute they are related | |
| 08:32:20 | bauzas | so, changing it would mean that you should also have to change the objects too | |
| 08:33:09 | bauzas | frickler: it's possible I think, and maybe some operators have some tools for it | |
| 08:33:19 | frickler | bauzas: I don't question why it is immutable, I'd just like to see that clearly documented, so I can point people to it | |
| 08:34:01 | frickler | bauzas: for the API I do question why the default is admin-only, though, because that data seems to be readily available via metadata | |
| 08:34:20 | bauzas | frickler: ahah good point | |
| 08:34:40 | gibi | bauzas: would that service stop wait for every eventlet thread to finish too? that would mean a sort-of gracefull shutdown then | |
| 08:34:50 | bauzas | frickler: you get the hostname thru the metadata API, really ? | |
| 08:35:09 | gibi | bauzas: I guess suryasingh or me could try in devstack to see what happens with on the fly spawns | |
| 08:35:17 | bauzas | gibi: I'm not an oslo.service expert, but I'd think it does | |
| 08:35:42 | bauzas | gibi: that's what I'd expect at least | |
| 08:35:55 | bauzas | (the service wait) | |
| 08:36:22 | frickler | bauzas: http://169.254.169.254/latest/meta-data/hostname gives me the original hostname, not the changed (display_)name, yes | |
| 08:38:00 | bauzas | eeek | |
| 08:38:01 | frickler | oh, wait, is that an even different hostname? | |
| 08:40:13 | bauzas | frickler: wait | |
| 08:40:28 | bauzas | frickler: hostname will give you the display_name of the instance VM I'd say | |
| 08:40:39 | bauzas | that's what I'd expect | |
| 08:41:18 | bauzas | at least it's what EC2 Metadata format will give you https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html | |
| 08:42:14 | bauzas | https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html => | |
| 08:42:15 | bauzas | hostname The private IPv4 DNS hostname of the instance. In cases where multiple network interfaces are present, this refers to the eth0 device (the device for which the device number is 0). | |
| 08:42:15 | bauzas | ||
| 08:44:26 | frickler | bauzas: nope, those data seem immutable in my test, too (rocky). the openstack meta_data.json gives "hostname": "oldname.novalocal", "name": "newname" | |
| 08:45:20 | frickler | which is consistent with how neutron seems to handle dns at least | |
| 08:52:30 | bauzas | frickler: lemme rephrase, this hostname value matches the original instance name, not the compute service hostname | |
| 08:55:24 | openstackgerrit | Mamduh proposed openstack/os-vif master: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/746673 | |
| 09:06:02 | frickler | bauzas: not sure what you mean by "compute service hostname". the metadata matches the original instance name and OS-EXT-SRV-ATTR:hostname, not the new instance name | |
| 09:08:55 | openstackgerrit | Akhil Gudise proposed openstack/nova master: Moved all calls from _ENFORCER.authorize to a separate _authorize method https://review.opendev.org/739460 | |
| 09:08:56 | bauzas | frickler: okay, my bad, I see the confusion | |
| 09:09:07 | gibi | swp20: left comment in https://review.opendev.org/#/c/748339 | |
| 09:09:28 | bauzas | frickler: I thought you were asking whether the compute service hostame was immutable | |
| 09:09:33 | bauzas | I'm tired | |
| 09:09:41 | bauzas | you asked about the instance hostname | |
| 09:10:06 | bauzas | and yeah, this is immutable, users can only change the display_name field | |
| 09:10:10 | bauzas | frickler: I apologize | |
| 09:10:31 | bauzas | which is consistent with what you get from the metadata API | |
| 09:10:55 | bauzas | now, back to your original question, where it is documented, I'm doublechecking things | |
| 09:12:18 | bauzas | frickler: first, the API fields are documented here https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detailed-detail#id21 | |
| 09:12:43 | bauzas | and the "name" field is actually the display_name fiedl | |
| 09:28:22 | frickler | bauzas: "The hostname set on the instance when it is booted." if one interprets "booted" as "created", that would almost do it, I guess | |
| 09:29:26 | swp20 | gibi: thanks for review. | |
| 09:29:28 | bauzas | frickler: agreed, fancy fixing the api ref ? | |
| 09:29:28 | frickler | bauzas: related strangeness: while the API seems to allow to filter the server list based on instance hostname, "openstack server list --host $hostname" actually seems to filter on hypervisor_hostname | |
| 09:29:44 | bauzas | frickler: hence my confusion | |
| 09:29:59 | bauzas | in nova, host generally refers to the compute service hostname | |
| 09:30:20 | frickler | bauzas: ah, I see. I can do a patch for the api-ref, yes | |
| 09:31:03 | bauzas | frickler: and fwiw, we have OS-EXT-SRV-ATTR:host which gives you the compute service hostname | |
| 09:31:45 | bauzas | see the problem ? :) | |
| 09:32:06 | frickler | bauzas: yeah, nice semantic overload, "name of the host" vs. "(DNS) hostname of the instance" | |