| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-31 | |||
| 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 | openstack | Launchpad bug 1861401 in OpenStack Compute (nova) "Renaming instance brokes DNS integration" [Low,Opinion] | |
| 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: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 | ||
| 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: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 | 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:28 | bauzas | frickler: agreed, fancy fixing the api ref ? | |
| 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 | |
| 10:46:29 | brinzhang | stephenfin: https://review.opendev.org/#/c/715326/27/api-guide/source/accelerator-support.rst@56 | |
| 10:47:41 | brinzhang | stephenfin: In https://releases.openstack.org/victoria/ we are not update the nova version for Victoria, do you need to keep use ussuri version 21.1.0? | |
| 10:48:28 | stephenfin | brinzhang: You mean there's no 22.0.0 release yet? | |
| 10:48:44 | stephenfin | That makes sense. It hasn't been released. You're writing these docs for when it *is* released | |
| 10:48:45 | brinzhang | stephenfin: yes | |
| 10:49:39 | brinzhang | aha, I think yes, it make sense | |
| 10:49:42 | sean-k-mooney | brinzhang: we only ever use the major version in the release notes | |
| 10:50:10 | stephenfin | Yeah, when writing things like the 'versionchanged' directive, you give the first version the change is *included* in | |