Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-31
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 gibi OK cool
12:39:11 sean-k-mooney you will get a novalid host
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
12:43:55 sean-k-mooney and jut removing xex server
12:44:03 sean-k-mooney *xen-server
12:44:15 sean-k-mooney the standalone xen driver or are we removing both
12:44:48 gibi we are removing libvirt+xen not the standalone xenserver
12:45:06 sean-k-mooney isnt the standalone xenapi the one we wanted to remove
12:45:18 sean-k-mooney libvit xen proably still works
12:45:26 sean-k-mooney xenapi was the one with issues
12:45:51 sean-k-mooney given it still needed pyton 2.6 like a year ago
12:46:01 sean-k-mooney oh the xen server side
12:47:15 sean-k-mooney oh we are doing both
12:47:17 gibi sean-k-mooney: you are right. that is a big -1 for stephenfin :)
12:47:20 sean-k-mooney https://etherpad.opendev.org/p/nova-victoria-ptg
12:47:34 sean-k-mooney lines 377 is the libvirt support
12:47:40 sean-k-mooney and 386 is xenapi
12:47:52 sean-k-mooney so we are ment to be deleteing xenapi
12:48:03 sean-k-mooney and deprecating xen an uml
12:48:08 sean-k-mooney not deleting them
12:48:39 sean-k-mooney gibi: so stephen is jumping the gun with the deletions
12:49:06 sean-k-mooney victoria is deprecation
12:49:23 sean-k-mooney for the libvirt backends and deletion for xenapi
12:49:30 sean-k-mooney stephenfin: ^
12:50:01 gibi I added the necessary -1s now. Thanks for catching this Sean
12:51:50 openstackgerrit Brin Zhang proposed openstack/nova master: Cyborg evacuate support https://review.opendev.org/715326
12:52:00 sean-k-mooney so did i :)
12:53:26 sean-k-mooney gibi: on the plus side since stephenfin has written the patches those are easy to merge in early wallaby
12:53:49 gibi yeah, but first we have to merge some deprecation patches for these
12:53:58 sean-k-mooney yep
12:54:18 sean-k-mooney while i have your attention there is a revert of one of aarents patches proposed https://review.opendev.org/#/c/749035/1
12:54:53 sean-k-mooney i dont see how we can be getting None also the ci really does not like the revert for some reason
12:55:14 sean-k-mooney but apprenlty this is failing in rdo
12:55:26 sean-k-mooney im not sure if it was a one off failure or if its blocking there gate
12:55:38 sean-k-mooney https://bugs.launchpad.net/tripleo/+bug/1893618
12:55:38 openstack Launchpad bug 1893618 in tripleo "periodic-tripleo-ci-centos-8-scenario000-multinode-oooq-container-updates-ussuri tempest test_shelve_unshelve_server failing in component-pipeline " [Critical,Triaged]

Earlier   Later