Earlier  
Posted Nick Remark
#openstack-nova - 2021-12-14
16:37:43 gibi \o/
16:37:46 bauzas thanks
16:37:53 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-12-14-16.00.log.html
16:37:53 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-12-14-16.00.txt
16:37:53 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-12-14-16.00.html
16:37:53 opendevmeet Meeting ended Tue Dec 14 16:37:53 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:37:53 bauzas #endmeeting
16:37:55 opendevreview mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935
16:40:41 elodilles bauzas: thanks \o/ & same to you :) & sorry :S
16:44:25 opendevreview Martin Kopec proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519
#openstack-nova - 2021-12-15
04:14:10 hungnt1 i have 1 openstack cluster run on production.
04:14:14 hungnt1 i have 1 openstack cluster run on production.
04:14:18 hungnt1 all compute run CPU Intel Xeon Gold 6126 and fixed CPU model for VM is Skylake-Server
04:14:38 hungnt1 now i have 10 new server run CPU Intel Xeon Gold 6330
04:14:54 hungnt1 How can I check the new CPU compatibility with SkyLake-Server for migration VM ?
04:14:59 hungnt1 can anyone help me ?
04:23:59 sean-k-mooney[m] the 6126 is skylake and 6330 are icelake
04:24:33 sean-k-mooney[m] if you use a custom cpu model of skulake-server on all host they should be compatible
04:25:13 sean-k-mooney[m] you will need to set cpu_mode=custom cpu_model=skylake-server in the libvirt section of the nova.conf
04:25:24 sean-k-mooney[m] rather then relying on the default host-model
04:25:38 hungnt1_ now, my config is cpu_model=skylake-server
04:25:42 sean-k-mooney[m] you can check compatibality using libvirt
04:25:54 sean-k-mooney[m] yep that should work
04:26:48 sean-k-mooney[m] the simplest way yo check really is to just deploy the nodes and try the migration honestly but it should work
04:27:33 hungnt1_ i need check compatibility before order server
04:29:06 hungnt1_ model ?
04:29:06 hungnt1_ need confirm 6330 model contain all feature flags of skylake-server
04:33:02 hungnt1_ where can get list feature flag of SkyLake and IceLake
04:33:40 sean-k-mooney[m] normally i would suggest downloading the datasheet form intel https://ark.intel.com/content/www/us/en/ark/products/212458/intel-xeon-gold-6330-processor-42m-cache-2-00-ghz.html
04:33:57 sean-k-mooney[m] but it does not seam to be avaialable for that model
04:35:57 hungnt1_ i cann't find it too
04:36:55 hungnt1_ makes me not 100% sure about compatibility
04:36:56 sean-k-mooney[m] you could compare the cpu models in libvirt/qemu
04:37:31 sean-k-mooney[m] i.e. assert the icelake model is a superset of the skylake one
04:38:10 sean-k-mooney[m] the abstract cpu models are intended too allow this type of compatiblity
04:38:40 sean-k-mooney[m] but other then that im not sure there is much else we can suggest
04:39:47 hungnt1_ maybe i need contact Intel to get list feature
04:39:57 hungnt1_ and make compareration
04:41:43 sean-k-mooney[m] https://paste.opendev.org/show/811678/
04:42:29 hungnt1_ oh
04:42:34 hungnt1_ tks u
04:42:51 hungnt1_ tôi sẽ kiểm tra, nó hữu ích
04:42:54 hungnt1_ i will check, it helpful
04:43:33 sean-k-mooney[m] no worries those xmls basicaly define the abstrack cpu models used or at least a semi human readable version of them
04:45:06 sean-k-mooney[m] the only think im not sure about is <feature name='intel-pt' removed='yes'/> everything else looks like a superset
04:47:10 sean-k-mooney[m] ah it processor tracing
04:47:12 sean-k-mooney[m] https://bugzilla.redhat.com/show_bug.cgi?id=1853972
04:47:28 sean-k-mooney[m] looks like it was never implemented in qemu/kvm
06:33:26 hungnt1_ in libvirt v4.5.0, it have <feature name='intel-pt'/> in Icelake map
06:35:19 hungnt1_ https://www.diffchecker.com/XXMDm5kL
06:35:57 hungnt1_ i had diffcheck in ver 4.5.0
10:39:30 gibi hi! I need a second core (other that bauzas) on the bugfix https://review.opendev.org/c/openstack/nova/+/820549
11:26:27 stephenfin gibi: Done. Nice work
11:26:36 gibi stephenfin: thanks a lot!
11:27:45 gibi stephenfin: this might be intresting to you as well https://review.opendev.org/c/openstack/nova/+/821423 but it is not urgent as I have to fix tempest first
11:29:59 stephenfin gibi: Looking. I'm good on https://review.opendev.org/c/openstack/nova/+/766771 too. I know I originally wrote it, but that was ages ago and I'd forgotten about it so it's basically someone else's code now, heh
11:31:11 gibi yeah, it is a long story. funnily we got hit by it downstream so suddenly it got prioritized up on my list
11:31:44 stephenfin I think it was a downstream bug that caused me to work on that originally too, but I can't really be sure at this point
11:31:45 gibi but the parallel tempest execution actually triggers the bug and as soon as I started rejecting it tempest started to fail randomly
11:32:03 gibi so now I have a nice task to fix up tempest
11:32:15 gibi hence https://review.opendev.org/c/openstack/tempest/+/821732
12:29:28 sean-k-mooney gibi: it kind of looks like it deadlocked
12:29:59 gibi sean-k-mooney: it has issues with the serial decorator itself as well. I'm troubleshooting locally
12:44:18 sean-k-mooney gibi you know looking at the decorator you could justr set __serial=True in the defition of the subclasses that should be serial too
12:44:34 gibi sean-k-mooney: sure, that is an alternative to the decorator
12:49:18 opendevreview Erlon R. Cruz proposed openstack/nova master: Fix pre_live_migration rollback https://review.opendev.org/c/openstack/nova/+/815324
12:49:19 opendevreview Erlon R. Cruz proposed openstack/nova master: Adds regression test for bug LP#1897483 https://review.opendev.org/c/openstack/nova/+/821840
12:56:09 gibi sean-k-mooney: it appears that I should not rely on __serial as the __ makes is special from attribute lookup perspective
12:56:45 sean-k-mooney oh yes __ at the start alters name mangaling
12:58:16 gibi I knew I hit this before but I alway forget
12:59:17 sean-k-mooney gibi: i woudl just make it all UPPERCASE and remvoe the undersocres
12:59:44 sean-k-mooney like the class constants we have in the func test for api version and such
13:26:22 sean-k-mooney bauzas: elodilles: this was rebased https://review.opendev.org/c/openstack/nova/+/816883 can you +w to get it moving again
13:33:00 opendevreview Merged openstack/nova master: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820549
13:36:29 elodilles sean-k-mooney: done
13:36:40 sean-k-mooney elodilles: thanks
13:36:49 elodilles no problem :)
13:37:47 sean-k-mooney we had some downstream interest in it so just wanted to relay it upstream
14:00:11 erlon sean-k-mooney: hey, can you get some time to review https://review.opendev.org/c/openstack/nova/+/821840? Its the regression test for https://review.opendev.org/c/openstack/nova/+/815324
14:00:31 erlon sean-k-mooney: please let me know if this is what you were thinking
14:01:21 erlon also, I need a piece of advice. I cant make it work, and it seems that the mock I'm using is just not mocking. I tried several ways, one is commented
14:37:54 sean-k-mooney erlon: not quite. you seam to be trying to create the reguression test more or less form scratch
14:38:41 sean-k-mooney erlon: i would have started by using one of our libvirt funtal test case base classes
14:39:07 sean-k-mooney also functional test should not really be mocking the way this is
14:39:18 sean-k-mooney this is closer to a unit test
14:40:35 sean-k-mooney erlon: so i proably should have started form 1897483
14:40:40 sean-k-mooney * https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/base.py#L31
14:41:14 sean-k-mooney or from integrated_helpers._IntegratedTestBase
14:41:37 sean-k-mooney if it was not a libvirt specific issue
14:42:59 sean-k-mooney erlon: this is an example live migration functional test
14:43:01 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/tests/functional/regressions/test_bug_1939545.py
15:21:26 opendevreview Merged openstack/nova stable/wallaby: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/816883
19:26:02 opendevreview Alexey Stupnikov proposed openstack/nova stable/victoria: Ensure MAC addresses characters are in the same case https://review.opendev.org/c/openstack/nova/+/816927
#openstack-nova - 2021-12-16
06:44:57 opendevreview mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935
08:25:37 opendevreview Balazs Gibizer proposed openstack/nova stable/xena: Reproduce bug 1953359 https://review.opendev.org/c/openstack/nova/+/820550
08:25:39 opendevreview Balazs Gibizer proposed openstack/nova stable/xena: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820553
08:25:40 opendevreview Balazs Gibizer proposed openstack/nova stable/xena: Extend the reproducer for 1953359 and 1952915 https://review.opendev.org/c/openstack/nova/+/821941
08:29:15 opendevreview Balazs Gibizer proposed openstack/nova stable/wallaby: Reproduce bug 1953359 https://review.opendev.org/c/openstack/nova/+/820554
08:30:28 opendevreview Balazs Gibizer proposed openstack/nova stable/wallaby: Extend the reproducer for 1953359 and 1952915 https://review.opendev.org/c/openstack/nova/+/821943
08:31:41 opendevreview Balazs Gibizer proposed openstack/nova stable/wallaby: [rt] Apply migration context for incoming migrations https://review.opendev.org/c/openstack/nova/+/820555

Earlier   Later