| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-31 | |||
| 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 | |
| 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 | |
| 10:50:46 | stephenfin | Leaving aside the major/minor thing, 21.1.0 has been released and it clearly wasn't included there :) | |
| 10:50:54 | sean-k-mooney | if we were fixing a bug caused by a backport i guess that could be an excpetion | |
| 10:51:02 | brinzhang | sean-k-mooney: yeah, ack. We were marked this, and it is reasonable in the docs, when the use to use this feature, it's belong to the 22.0.0 | |
| 10:51:10 | sean-k-mooney | but i dont think we have used a minor verion in the past | |
| 10:51:19 | stephenfin | sean-k-mooney: yeah, sure. I don't think we have used it though | |
| 10:51:20 | stephenfin | yeah | |
| 10:52:47 | brinzhang | sean-k-mooney, stephenfin: do we need to backport this to Ussuri? | |
| 10:53:02 | stephenfin | you can't | |
| 10:53:06 | stephenfin | there's a service version bump | |
| 10:53:10 | stephenfin | not backportable | |
| 10:53:26 | brinzhang | ack ^ | |
| 10:55:21 | brinzhang | stepheinfin, gibi, sean-k-mooney: will udpate this patch later, thanks for your review, it's getting closer and closer to closing | |
| 10:55:44 | stephenfin | yup, we'll have this landed by end of the week, for sure | |
| 10:56:08 | gibi | ^^ +1 | |
| 10:57:34 | sean-k-mooney | stephenfin: oslo lib freeze was on thursday its one week before the non-client lib freeze which is this thursday | |
| 10:58:03 | stephenfin | gibi, bauzas: We discussed dropping support for the untested libvirt hypervisors at the PTG. Any chance you could review these patches at some point this week since I don't think we can merge after M3? https://review.opendev.org/#/q/topic:bp/remove-deprecated-libvirt-virt-types+status:open | |
| 10:58:13 | sean-k-mooney | i try to have a potential "release candiate" on the oslo freeze if i can but we havnt this time | |
| 10:58:26 | sean-k-mooney | so we still have till thrusday for os-vif | |
| 10:58:34 | stephenfin | sean-k-mooney: okay, good to hear | |
| 10:58:51 | gibi | stephenfin: add those to my queue now | |
| 10:59:02 | stephenfin | \o/ Great, thanks :) | |
| 10:59:06 | sean-k-mooney | i normally like to have that week to see if neutron or nova shake out something and still have time to fix it before the non-client lib freeze | |
| 10:59:30 | sean-k-mooney | anyway updating the os-vif patch now | |
| 11:02:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Update references to image properties https://review.opendev.org/744198 | |
| 11:02:31 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for UML https://review.opendev.org/743230 | |
| 11:02:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Drop support for Xen https://review.opendev.org/743231 | |
| 11:02:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: Remove 'hypervisor_version' from 'libvirt_info' https://review.opendev.org/744199 | |
| 11:02:39 | sean-k-mooney | stephenfin: i do remember i was ment to create a ci for libvirt lxc but have not :( | |
| 11:02:53 | sean-k-mooney | oh your droping uml and xen | |
| 11:02:57 | sean-k-mooney | im ok with that | |
| 11:03:02 | stephenfin | Yeah, I've left dropping that one for another cycle at least | |
| 11:03:48 | sean-k-mooney | ill see if i can create the ci between m3 and rc1 | |
| 11:04:19 | sean-k-mooney | if not ill submit a deprecation patch for it. | |
| 11:04:24 | sean-k-mooney | oh speaking of which | |
| 11:05:37 | sean-k-mooney | if i fix https://review.opendev.org/#/c/745605/ today/tomorrow to deprecate the compute an az filter can we still merge that this release | |
| 11:05:57 | stephenfin | I don't see why not | |
| 11:06:22 | sean-k-mooney | ok it would be nice to be able to remove those next cycle or at least have the option too | |
| 11:32:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Further usage of new server helpers https://review.opendev.org/743204 | |
| 11:32:46 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/ussuri: Add a lock to prevent race during detach/attach of interface https://review.opendev.org/749033 | |