| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-31 | |||
| 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 | |
| 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 | 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] | |
| 12:55:38 | sean-k-mooney | https://bugs.launchpad.net/tripleo/+bug/1893618 | |
| 12:55:41 | gibi | looking... | |
| 12:57:16 | sean-k-mooney | for some reason instance.system_metadata.get('image_base_image_ref') is retruning none | |
| 12:57:45 | sean-k-mooney | but we set that in exactly one place and i dont really see how it can be none as that implies the instace has no image | |
| 12:57:56 | sean-k-mooney | which makes no sense for a qcow backed vm | |
| 13:00:03 | sean-k-mooney | actully from the pre shelve xml i can see <nova:root type="image" uuid="5cc451d5-7abe-478a-9f4f-1a804f49a3f3"/> | |
| 13:01:26 | sean-k-mooney | so its implying that the system_metadata table is populated incorrectly or instance.system_metadata does not have all the info at this point | |
| 13:01:48 | sean-k-mooney | its really strange because i would have expected this to work | |
| 13:02:46 | stephenfin | gibi, sean-k-mooney: I think those notes are wrong. Have we not already in-effect deprecated them? https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L606-L614 | |
| 13:03:14 | sean-k-mooney | no | |
| 13:03:31 | sean-k-mooney | testing is differnt | |
| 13:03:42 | sean-k-mooney | they are not deprecated yet | |
| 13:03:56 | sean-k-mooney | unless you can point to a release note | |
| 13:05:46 | sean-k-mooney | for what its worth i did not think we planned on removing support for any libvirt backends this cycle just deprecations the only removals were going to be xenapi and vmware | |
| 13:05:54 | sean-k-mooney | vmware have now fixed the ci | |
| 13:06:03 | sean-k-mooney | so they have been undeprecated? | |
| 13:06:10 | sean-k-mooney | i know gibi has a patch for that at least | |
| 13:07:18 | sean-k-mooney | stephenfin: if we just use that waring as a depercation warning then all of libvirt arm and power support would be deprecated and its not | |
| 13:08:36 | gibi | that warning was added 7 years ago https://review.opendev.org/#/c/69919/ | |
| 13:09:17 | gibi | I agree with sean-k-mooney here to state the deprecation explicitly for these first | |