Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-31
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
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
11:48:06 sean-k-mooney the segments per network im not sure needs to be
11:48:16 brinzhang stephenfin: hi, what do you means by https://review.opendev.org/#/c/715326/27/nova/compute/manager.py@3281
11:48:39 sean-k-mooney gibi: anyway we can cross that bridge later
11:49:15 gibi yepp, totally agree
12:01:13 bauzas sean-k-mooney: gibi: I'm just back, looking above
12:02:06 bauzas sean-k-mooney: gibi: okay, lemme provide the implementation today, you'll see my question
12:03:01 gibi sure
12:03:27 bauzas (I mean the client)
12:06:31 gibi bauzas: I guess the previous patch did not try to call neutron from the request filter, but did the data collection earlier and stored the requested aggregate info in request_spec.request_level_params.member_of.append
12:07:13 gibi neutron was queried in conductor https://review.opendev.org/#/c/656885/7/nova/conductor/manager.py
12:07:44 bauzas gibi: yep, but you'll see I don't use it
12:08:27 bauzas instead, I use a new request filter method and I use the requested destination object for passing the aggregates
12:08:39 bauzas but meh, you'll see
12:10:10 gibi OK, I will check
12:15:43 openstackgerrit Merged openstack/nova master: doc: Update references to image properties https://review.opendev.org/744198
12:28:52 gibi stephenfin: do we actively reject img_hv_type=uml after https://review.opendev.org/#/c/743230/4 ?
12:33:42 sean-k-mooney gibi: stephenfin did not update teh nova object
12:33:54 sean-k-mooney so the image property wont reject it
12:34:26 gibi sean-k-mooney: but then what will happen? NoValidHost?
12:35:09 sean-k-mooney its still here https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/fields.py#L405
12:36:01 sean-k-mooney well you cant set the uml virt type anymore since the config is updated
12:38:12 sean-k-mooney it looks like this was only used in https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/filters/image_props_filter.py#L55
12:39:02 sean-k-mooney so since there are no hosts with that hypervior type
12:39:03 gibi as this is an image property UML still can be requested from the image. But then I guess it will simply result in a NoValidHost
12:39:04 sean-k-mooney then ya
12:39:11 sean-k-mooney you will get a novalid host
12:39:11 gibi OK cool
12:39:48 sean-k-mooney we proably should also update the field definiton to make that invalid
12:41:09 sean-k-mooney which requires a slightly differnt approch where we raise an excption in obj_make_compatiable instead of just droping it
12:41:13 sean-k-mooney like this https://opendev.org/openstack/nova/src/branch/master/nova/objects/image_meta.py#L191-L197
12:41:55 gibi yeah, that could be done as a follow up cleanup I guess
12:42:23 sean-k-mooney ya its not strictly required i guess. but the valuse wont be vaild anymore
12:42:39 sean-k-mooney it might make sense to have only one object bump for both
12:43:06 sean-k-mooney although i can see a counter argument to be made that you might continue to support uml with an out of tree driver or something
12:43:07 gibi agree on a single bump for multiple removals
12:43:19 sean-k-mooney uml is unlikly to do that
12:43:29 sean-k-mooney xen might be more likely
12:43:47 sean-k-mooney although we are keeping libvirt-xen right

Earlier   Later