| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-31 | |||
| 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" | |
| 09:32:15 | bauzas | that's what happens when you're bugged on a Monday morning :) | |
| 10:00:36 | bauzas | sean-k-mooney1: gibi: you're more experts than me on the network side, but I'm facing a small issue with the routed networks implementation | |
| 10:01:32 | bauzas | sean-k-mooney1: gibi: I only get the list of physnets from the requestspec when I'm in a prefilter, so instead of querying the list of segments from the network id or the port id, I was about to query neutron to give me the list of segments related to the physnets I got | |
| 10:01:46 | bauzas | sean-k-mooney1: gibi: do you think it's valid ? IMHO, it is. | |
| 10:03:15 | bauzas | sean-k-mooney1: gibi: this would even allow us to not care whether we were passed a port or a network like mriedem implemented in his WIP https://review.opendev.org/#/c/656885/7/nova/scheduler/utils.py@1379 | |
| 10:42:20 | sean-k-mooney1 | bauzas: one sec | |
| 10:42:49 | sean-k-mooney1 | bauzas: need to read that a couple of times :) | |
| 10:43:01 | sean-k-mooney1 | still drinking moring coffee | |
| 10:43:55 | sean-k-mooney1 | not sure the request spec is correct | |
| 10:44:38 | sean-k-mooney1 | i need to look at where the request spec gets its physnet info | |
| 10:45:03 | sean-k-mooney1 | if its getting it for the nova vif objects then that is not correct | |
| 10:45:57 | sean-k-mooney1 | the nova vif object just use the first physnet form a network not the physnet corresponding to the segment | |