Earlier  
Posted Nick Remark
#openstack-nova - 2020-08-31
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
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: libvirt: Drop support for UML https://review.opendev.org/743230
11:02:31 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Update references to image properties https://review.opendev.org/744198
11:02:32 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Remove 'hypervisor_version' from 'libvirt_info' https://review.opendev.org/744199
11:02:32 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Drop support for Xen https://review.opendev.org/743231
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
11:36:25 openstackgerrit yatin proposed openstack/nova master: Revert "Rebase qcow2 images when unshelving an instance" https://review.opendev.org/749035

Earlier   Later