| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-29 | |||
| 15:59:08 | stephenfin | correct | |
| 15:59:19 | stephenfin | there have to be 4k pages | |
| 15:59:21 | artom | stephenfin, gotcha, thanks | |
| 15:59:25 | stephenfin | on x86(_64) anyway | |
| 15:59:33 | sean-k-mooney | if you did they would be the native page size on the system | |
| 15:59:34 | artom | Right, in retrospect, when you put it that way, it seems kinda obvious | |
| 15:59:36 | stephenfin | I don't know what pagesizes are on other platforms | |
| 15:59:37 | sean-k-mooney | not a hugepage | |
| 15:59:49 | sean-k-mooney | ntataive page size can be bigger then 4k | |
| 16:00:03 | artom | So I need to setup my fake hostinfo accordingly | |
| 16:00:27 | sean-k-mooney | mem_size small menas that you get teh smallest pageszie on the host | |
| 16:00:36 | sean-k-mooney | so if the only one is 2048 then that what you get | |
| 16:06:02 | bauzas | calling it a day | |
| 16:06:15 | bauzas | stephenfin: I'm a mean guy https://review.opendev.org/#/c/679273/1 | |
| 16:06:59 | bauzas | no, seriously, I'm torn but I feel from an operators perspective that 'upgrades' is better. That said, that would in theory leave us having some kind of nova-manage stuff to do | |
| 16:07:11 | bauzas | nova-status, my bad | |
| 16:07:19 | stephenfin | I was also on the fence | |
| 16:07:28 | stephenfin | I can do upgrades | |
| 16:07:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Follow-up for I491eb7abe1405b27c552cdef142c688a46e914f2 https://review.opendev.org/679273 | |
| 16:07:58 | stephenfin | bauzas: ^ | |
| 16:08:49 | openstackgerrit | Merged openstack/nova master: trivial: Rename 'nova.tests.unit.test_nova_manage' https://review.opendev.org/679095 | |
| 16:10:04 | bauzas | stephenfin: https://docs.openstack.org/nova/latest/contributor/releasenotes.html#when-a-release-note-is-needed makes me torn | |
| 16:10:13 | bauzas | (and that's actually me who wrote this) | |
| 16:10:58 | stephenfin | I'm not planning to backport this fix though | |
| 16:11:07 | stephenfin | so upgrade impact does make sense | |
| 16:19:45 | artom | Hrmm, is the conductor/scheduler code for live migration host selection even set up to handle the case of no host being found? | |
| 16:20:00 | mriedem | yes | |
| 16:20:58 | mriedem | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L439 | |
| 16:21:00 | artom | OK, then I'm doing something wrong | |
| 16:21:48 | artom | Oh, wait, are func tests using cast as call? | |
| 16:21:53 | artom | So it gets bubbled up to the API? | |
| 16:25:11 | aspiers | stephenfin: can I raise exception.FlavorImageConflict from within ResourceRequest? | |
| 16:25:44 | stephenfin | Probably not | |
| 16:25:52 | stephenfin | You don't _need_ it though, right? | |
| 16:25:55 | aspiers | Yes I do | |
| 16:26:01 | aspiers | Otherwise the conflict isn't handled correctly | |
| 16:26:05 | stephenfin | Per the "this happens in the API already" conversation? | |
| 16:26:14 | stephenfin | or am I mixing things up? | |
| 16:26:19 | aspiers | Oh I see | |
| 16:26:32 | aspiers | Hrm I guess :-/ | |
| 16:27:29 | stephenfin | It'll be raised if the API check didn't work for some reason, right? | |
| 16:27:33 | aspiers | Yes | |
| 16:27:46 | stephenfin | Cool. I wouldn't try handling it | |
| 16:27:48 | stephenfin | Let things die | |
| 16:27:49 | aspiers | OK | |
| 16:28:01 | stephenfin | Something's wrong. People should know | |
| 16:28:04 | aspiers | Right | |
| 16:28:19 | stephenfin | Sweet | |
| 18:01:45 | openstackgerrit | Merged openstack/nova stable/rocky: rt: only map compute node if we created it https://review.opendev.org/676280 | |
| 18:01:52 | openstackgerrit | Merged openstack/nova stable/rocky: Add functional regression recreate test for bug 1839560 https://review.opendev.org/676513 | |
| 18:01:54 | openstack | bug 1839560 in OpenStack Compute (nova) rocky "ironic: moving node to maintenance makes it unusable afterwards" [High,In progress] https://launchpad.net/bugs/1839560 - Assigned to Matt Riedemann (mriedem) | |
| 18:15:41 | mriedem | artom: ideally any new functional tests for your stuff won't use the CastAsCall fixture | |
| 18:15:51 | mriedem | b/c it makes things unrealistic for how the user would experience the API | |
| 18:19:28 | mriedem | efried: https://review.opendev.org/#/c/679251/ is good now | |
| 18:22:12 | openstackgerrit | Merged openstack/nova stable/rocky: Restore soft-deleted compute node with same uuid https://review.opendev.org/676514 | |
| 18:23:09 | sean-k-mooney | by the way i dont know if people say my commnet on patchset 20 last night | |
| 18:23:28 | sean-k-mooney | https://review.opendev.org/#/c/672595/21 | |
| 18:23:30 | artom | sean-k-mooney, the test results? | |
| 18:23:34 | sean-k-mooney | yep | |
| 18:23:46 | artom | The executive summary would be "woot", correct? | |
| 18:23:54 | sean-k-mooney | yes | |
| 18:24:00 | artom | Woot! | |
| 18:24:06 | sean-k-mooney | it seamed to work as intended | |
| 18:24:35 | sean-k-mooney | i am currently redeployting ot test a different patch | |
| 18:24:54 | sean-k-mooney | should i redeploy with v21 after or is it more or less the same | |
| 18:25:06 | mriedem | https://review.opendev.org/#/c/678887/ failed again | |
| 18:25:34 | artom | mriedem, yeah, I'm done faffing with the tests (for now, I suppose), looking into why virt_type still isn't being set correctly | |
| 18:25:39 | mriedem | https://zuul.opendev.org/t/openstack/build/49bea2053e864a9c818840b8c452606a/log/logs/subnode-2/etc/nova/nova-cpu.conf.txt.gz | |
| 18:25:39 | mriedem | the subnode is still wrong | |
| 18:25:40 | sean-k-mooney | woudl it be simpler if we jsut wrone a non legacy job to test it | |
| 18:26:03 | mriedem | i'm just going to write a devstack patch to set LIBVIRT_TYPE=kvm and depend on it | |
| 18:26:04 | sean-k-mooney | https://review.opendev.org/#/c/652197/ more or less is that non legacy job | |
| 18:26:11 | sean-k-mooney | but its failing because of fedora | |
| 18:26:46 | sean-k-mooney | new version of qemu is breaking oslo utils | |
| 18:27:11 | sean-k-mooney | but its fedora with the nightly build of qemu so we wont see that in distors for quite some time yet | |
| 18:27:39 | sean-k-mooney | mriedem: and ya that should also work | |
| 18:28:10 | sean-k-mooney | im going to try and get that nfv job passing again before RC1 | |
| 18:28:22 | sean-k-mooney | but can you wighin in on one aspect | |
| 18:28:59 | artom | mriedem, hah, that's one way of doing it | |
| 18:29:02 | sean-k-mooney | would you prefer a fedora based job that uses nightly qemu or a ubuntul 18.04 based job that only ran on vexhost/used neted virt | |
| 18:29:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: Run LM integration tests with NUMA flavor https://review.opendev.org/678887 | |
| 18:29:29 | sean-k-mooney | artom: well we already tried 4 others that didnt work | |
| 18:29:35 | sean-k-mooney | so its worth a shot | |
| 18:29:50 | artom | I'm not complaining :) | |
| 18:30:14 | sean-k-mooney | any opipion on ^ | |
| 18:30:44 | sean-k-mooney | e.g. should i piviot https://review.opendev.org/#/c/652197/ to just use nested vert on vexhost or try to get teh fedora based job working | |
| 18:30:53 | artom | I don't understand the differences between the options well enough to make a call | |
| 18:31:23 | sean-k-mooney | one ues fedroa an the virt preview repo to get a new enought qemu to support pinning and numa wiht out nested vert | |
| 18:31:31 | sean-k-mooney | so it would run on all the providers | |
| 18:31:47 | artom | Except that's now how it's done in real life, right? | |
| 18:31:54 | sean-k-mooney | the other option is to say screwit and just make it use nested vert and only run it on vexhost | |
| 18:32:00 | artom | So the second option would be better for a "permanent" CI thing | |
| 18:32:07 | artom | that's not | |
| 18:32:56 | sean-k-mooney | it depense if you are emulating other architefure like when rackspace used to run x86 on power its realisitc | |
| 18:33:21 | sean-k-mooney | but most people will use kvm or xen or hardware accleration | |
| 18:35:08 | artom | So I think yeah, go with the most realistic scenario | |
| 18:36:08 | artom | Also, keep in mind Fort Nebula was willing to provide multi-node NUMA flavors, and though infra wasn't thrilled because they want to be cloud-agnostic, they were OK with an experimental manually-triggered job to run on only that nodeset. | |
| 18:36:26 | mriedem | efried: belay that | |
| 18:37:08 | sean-k-mooney | ok in that case ill rebase it on top of your stuff to test that too but i might wait a bit before doing that | |
| 18:37:44 | artom | donnyd, actually, since we're on the topic, is ^^ still a thing you're planning to do, and do you need any assistance in doing it? | |