Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-02-07
12:11:38 bauzas ack
12:11:59 bauzas fwiw, looping over 78 different libvirt funct tests
12:12:17 bauzas first pass was saying OK
12:18:47 dvo-plv Sorry, Sean, but I do not get your final think. Do you prefer to use. Honestly, I would like to implement it as I have suggested, all interfaces what I need already exists and I will not extend other methods and classes with one parameter that will not use often. It will be a delicate way to extend the existing bunch of filters with one more filter.
12:50:28 gibi bauzas: added another https://bugs.launchpad.net/glance/+bug/2006473
12:57:06 sean-k-mooney dvo-plv: i was suggeting using the extra specs/image properties for now
12:57:51 sean-k-mooney dvo-plv: and when we raise our min libvirt/qemu version eventually we can enable it by defualt then
12:58:39 sean-k-mooney dvo-plv: that would be my prefence. its simple to add to nova, easy to document and understand and easy to test
12:59:26 sean-k-mooney dvo-plv: we can evenutally turn this on by default when we nolonger supprot qemu/libvirt version that dont have this and there is nolonger an upgade impact
13:01:23 sean-k-mooney dvo-plv: we did the same thing with the virtio random number generator in the past
13:01:53 sean-k-mooney dvo-plv: intially it was opt in and we enabled it by default after a few release after we raised our min libvirt/qemu version
13:14:48 bauzas gibi: after one hour, still none of the 79 tests were having an issue
13:18:17 opendevreview Jorge San Emeterio proposed openstack/nova master: Moving privsep profiles to nova/__init__.py https://review.opendev.org/c/openstack/nova/+/872010
13:18:27 dvo-plv Yes, I would like to have some general pre-approval from you here, before starting to implement and verify this functionality and present it in the blueprint to be sure that it will work okay, and does not waste your time on the blueprint spec file review process 1) User will have the ability to enable/disable this feature via flavor/image. 2) User will have the ability to set trait COMPUTE_NET_VIRTIO_PACKED to the flavor
13:19:10 dvo-plv Sorry, I have interrupt, I will resend my question
13:19:30 dvo-plv Yes, I would like to have some general pre-approval from you here, before starting to implement and verify this functionality and present it in the blueprint to be sure that it will work okay, and does not waste your time on the blueprint spec file review process
13:19:53 dvo-plv 1) User will have the ability to enable/disable this feature via flavor/image. 2) User will have the ability to set trait COMPUTE_NET_VIRTIO_PACKED to the flavor to choose some specific servers. Compute node will set this trait to the resource provider here static_trait.
13:20:11 dvo-plv 3) Scheduler will handle migration and OpenStack cluster update process with automatically understanding which node has this function with extended ALL_REQUEST_FILTERS array with a new filter similarly how it was implemented for accelerators_filter ( get a packed request from flavor ).
13:20:15 sean-k-mooney dvo-plv: yep so requesting the feature via flavor/image shoudl automatically result in the trait request via a pre_fiter like the acclerator filter
13:20:19 dvo-plv 4) As far as Qemu from v4.2 can not be compiled without packed ring support and Libvirt from v6.3, we can get if the current compute node can use this functionality and if it is available for the user.
13:20:25 dvo-plv OR do we need just implement options 1, 2, and 4 without the automatic scheduler handling this feature exists on the compute target node?
13:20:33 sean-k-mooney so they can ask for COMPUTE_NET_VIRTIO_PACKED explictly but it should not be required
13:21:26 sean-k-mooney 2 you get for free we already support arbitry trait request in the flavor/image
13:21:58 sean-k-mooney as part of implementeing 1 you should add a schduler prefilter to request COMPUTE_NET_VIRTIO_PACKED if the extra_spec/image property is set
13:22:23 sean-k-mooney so 1 and 3 are what you need to enable this feature properly
13:23:20 sean-k-mooney dvo-plv: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L212-L222
13:23:38 sean-k-mooney our current min libvirt is 6.0 and Qemu is 4.2
13:24:58 sean-k-mooney we have not bumped that in a few releases so we will likely go to libvirt 7.0 and qemu 5.2 in the B release
13:25:32 sean-k-mooney although we can technially do that in the A release
13:25:49 dvo-plv Okay, I see, but it in the future, for now Libvirt support packed from 6.3, Should I just update minimum libvirt version, or create my own define for my trait?
13:25:52 sean-k-mooney bauzas: kashyap any reason not to do that in A
13:26:38 sean-k-mooney dvo-plv: we have a speicifc procedure for updating it where we have to annowuch our new min version in advacne for at least 1 cycle
13:27:00 sean-k-mooney we declared 7.0 and 5.2 as our next verion in Wallaby
13:27:31 sean-k-mooney so we could have done that bump some time ago
13:27:46 bauzas sean-k-mooney: we can if you want
13:27:50 sean-k-mooney although we now have new upgrade requirement to test the previous LTS
13:27:54 sean-k-mooney bauzas: i just realsied we cant
13:28:03 sean-k-mooney we need to support focal for A for upgrade reasons
13:28:16 sean-k-mooney bauzas: so we should do this in early B
13:29:00 sean-k-mooney we need to not have 20.04 in our greade job to do this bump
13:29:12 bauzas hmmm ok
13:29:29 sean-k-mooney and the dedicated focal job to go away
13:29:43 sean-k-mooney for B we will be useing 22.04
13:30:47 sean-k-mooney dvo-plv: so what that means for you is if your patch is after we have done the bump you will not need to do the version check
13:31:01 gibi bauzas: I'm not surpirsed, it seems both of us are missing some hidden ingredients to reproduce the same thing that happens on the gate
13:31:06 sean-k-mooney if its before we do the bump you will ahve to do the version check when reportin the trait
13:31:32 bauzas - Unexpected Success: 0
13:31:32 bauzas - Expected Fail: 0
13:31:32 bauzas - Skipped: 0
13:31:32 bauzas - Passed: 4144
13:31:32 bauzas Ran: 4144 tests in 4758.5975 sec.
13:31:34 bauzas - Failed: 0
13:31:36 bauzas Sum of execute time for each test: 32443.8935 sec.
13:31:38 bauzas :)
13:31:51 sean-k-mooney what kind of potato is that running on
13:32:20 sean-k-mooney or were you just running those in a loop
13:32:46 bauzas sean-k-mooney: see what we discussed before you arrived
13:33:08 bauzas gibi: yah, maybe
13:33:17 dvo-plv Okay, If Libvirt version will be lower that 6.3, when I will present patch in the blueprint, I will create separate define with Libvirt version
13:33:23 bauzas gibi: I'm now looking at the code and trying to understand what we use
13:33:48 opendevreview Jorge San Emeterio proposed openstack/nova master: Moving privsep profiles to nova/__init__.py https://review.opendev.org/c/openstack/nova/+/872010
13:33:51 kashyap sean-k-mooney: Hi, reading back. (Was buried elsewhere in an urgent thing)
13:34:13 sean-k-mooney kashyap: its fine it was just on our next libvirt/qemu version
13:34:14 kashyap sean-k-mooney: Yeah, bumping the min versions in 'A' is totally fine.
13:34:25 sean-k-mooney kashyap: actully it used to be its not anymore
13:34:40 sean-k-mooney kashyap: form a pure nova point of view it would be
13:34:53 sean-k-mooney kashyap: but we have PTI/governance requirements
13:34:59 kashyap Right, I'm talking from a Nova PoV
13:35:05 sean-k-mooney that reqire use to supprot 20.04 for A
13:35:22 sean-k-mooney right so because of the other requirement we cant bump it in nova until B
13:35:40 sean-k-mooney kashyap: https://github.com/openstack/governance/blob/master/reference/runtimes/2023.1.rst#additional-testing-for-smooth-upgrade
13:36:23 kashyap What is "support 20.04 for A", I don't get
13:36:39 dvo-plv Thank you for your time and conversation. Have a nice day
13:36:41 kashyap Ah, it is Ubunutu 20.04
13:37:09 sean-k-mooney yes basicaly every time we cange a base OS in the testign requirement we need to have one release wehre we test the old and new version
13:37:25 sean-k-mooney kashyap: we chavned form 20.04 to 22.04 in this release
13:37:54 sean-k-mooney so the same would happen for debiany 11->12 or centos 9->10 in the future
13:38:42 sean-k-mooney its to ensure you can upgrade openstack without nessiarly needing to upgrade the OS it also mimic how our greneade jobs work
13:39:36 sean-k-mooney its related to https://github.com/openstack/governance/blob/master/resolutions/20220210-release-cadence-adjustment.rst the skip level upgrade release and the new lifecycle for integrated release projects
13:40:01 sean-k-mooney dvo-plv: o/
13:40:05 kashyap sean-k-mooney: Yeah, the upgradeability makes sense
13:40:31 sean-k-mooney kashyap: bauzas any objection to doing the bump in a few weeks after RC 1 is out
13:40:41 sean-k-mooney better to try and do that early rather then late
13:40:55 sean-k-mooney or at least identify what our next versions should be declared as
13:41:02 bauzas when RC1 is out, then the master branch will be the Bobcat release, so ok
13:41:14 kashyap sean-k-mooney: Definitely agree on doing it earlier
13:42:20 opendevreview Merged openstack/nova master: Move comment about _destroy_evacuated_instances() https://review.opendev.org/c/openstack/nova/+/872348
13:42:28 opendevreview Merged openstack/nova stable/wallaby: [stable-only][cve] Check VMDK create-type against an allowed list https://review.opendev.org/c/openstack/nova/+/871557
13:42:35 bauzas \o/
13:45:10 bauzas gibi: interestingly, if I restrict the logsearch call to ImportError: This test imports the 'libvirt' module, which it should not in the test environment. Please add appropriate mocking to this test." which is the latest exception I only get 19/143 failures that match (from the last 20 days)
13:45:26 opendevreview Maxim Monin proposed openstack/nova master: Server Rescue leads to Server ERROR state if base image is deleted https://review.opendev.org/c/openstack/nova/+/872385
13:45:41 bauzas by comparing https://7ffaea22ff93fca2f0ea-bf433abff5f8b85f7f80257b72ac6f67.ssl.cf5.rackcdn.com/869900/7/gate/nova-tox-functional-py38/3b10d8a/testr_results.html to https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_d00/868237/9/check/nova-tox-functional-py38/d00d1ff/testr_results.html that's why I think we have this
13:46:44 gibi I dont see the difference both has the import error line
13:57:31 bauzas gibi: I mean, this is just a canary line for not getting the false positives
13:58:03 gibi do you have a false positive where this line is missing?
14:00:35 opendevreview David Hill proposed openstack/nova master: Increase user_data from 64k to 128k https://review.opendev.org/c/openstack/nova/+/872931
14:04:31 bauzas gibi: one of the false positives is https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_aea/850501/15/check/nova-tox-functional-py38/aea02af/testr_results.html
14:05:22 bauzas gibi: you can find the DB issue in job_output.txt but the tests aren't failing
14:05:25 bauzas https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_aea/850501/15/check/nova-tox-functional-py38/aea02af/job-output.txt
14:06:05 bauzas and you won't see the canary line

Earlier   Later