Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-31
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
11:36:25 openstackgerrit yatin proposed openstack/nova master: Revert "Rebase qcow2 images when unshelving an instance" https://review.opendev.org/749035
11:37:05 gibi bauzas: based on https://review.opendev.org/#/c/656885/7/nova/scheduler/utils.py@1322 I think your observation is valid. We know the requested network (or port but then that is translated back to network) and then we can query neutron for a list of segments in that network
11:37:44 sean-k-mooney gibi: right we have to query neutron
11:37:58 sean-k-mooney gibi: i think bauzas was suggesting we woudl have physnets in the request spec
11:38:05 sean-k-mooney but those would be incorrect if present
11:38:35 sean-k-mooney if you have multiple phsynets associated with a network nova only stores the frist in the vif object
11:38:39 gibi yeah, I don't think we have physnets there. But somewhere we have physnets
11:39:14 gibi yes, I remember now that we only check for the first physnet when walking the segments
11:39:18 sean-k-mooney right but they are only correct if the network has only one physnet
11:39:38 sean-k-mooney gibi: yep its a hack that we never fixed
11:40:01 sean-k-mooney fixing it is non trivial for the sriov case
11:40:21 sean-k-mooney the pci tracker cant currently take a list of physnets
11:40:25 gibi yes, agreee
11:40:47 sean-k-mooney so we cant say find a vf with any of these phsnets currently
11:41:03 sean-k-mooney i think the same would apply for bandwith requests
11:41:48 sean-k-mooney so i think looping over the requested netwroks is valid
11:42:01 gibi agree too
11:42:02 sean-k-mooney but we still need to ask neuton for the list of segments
11:42:52 sean-k-mooney we could maybe cache that if we considered it to be expensive with a time based cache
11:43:12 sean-k-mooney e.g. cache it with a hard time out of say 5 minutes
11:43:32 sean-k-mooney its something we expect to change very seldomly
11:44:22 sean-k-mooney but that can be done later if needed
11:45:01 gibi yeah, that could be an optimization. Still this is a single http request per network.
11:45:09 gibi so should not be that expensive
11:45:26 swp20 stephenin: hi, what do you means by https://review.opendev.org/#/c/715326/22..27/nova/compute/manager.py@3281
11:45:28 sean-k-mooney well not quite
11:45:40 sean-k-mooney we have to get teh list of segments form the network
11:45:58 sean-k-mooney then we need to get the phsynets form the segments in a different part of the code
11:46:23 sean-k-mooney so its 1 call for the segments and a second per segment for the segment details
11:47:21 gibi yeah you are right there are two different places where we query segments
11:47:49 gibi there the cache make more sense
11:47:54 sean-k-mooney the segment details are what i think could be cached

Earlier   Later