| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-12 | |||
| 20:31:46 | openstackgerrit | Julia Kreger proposed openstack/nova master: [ironic] ignore conflict upon cleaning up node https://review.openstack.org/643484 | |
| 20:31:47 | mriedem | i guess if it's just a smaller set of tests in a non-voting job, sure | |
| 20:31:51 | mriedem | better than 0 coverage | |
| 20:32:00 | sean-k-mooney | we jsut need the new libvirt really | |
| 20:32:11 | sean-k-mooney | i have a devstack plugin that can compile it form source | |
| 20:32:14 | sean-k-mooney | and qemu | |
| 20:32:23 | fried_rice | tjgresha: this conversation may interest you ^ | |
| 20:32:33 | sean-k-mooney | so i caould also use that do it with ubuntu or centos | |
| 20:32:58 | fried_rice | sean-k-mooney: I think there's work in progress to resurrect nfv CI, so if you think we don't need it at all, that'd be a good thing to know. | |
| 20:33:26 | sean-k-mooney | https://github.com/openstack/devstack-plugin-libvirt-qemu | |
| 20:34:04 | sean-k-mooney | yes i heard | |
| 20:34:29 | sean-k-mooney | we currently dont have vm with multiple numa nodes in the gate | |
| 20:34:41 | sean-k-mooney | which is onething the nfv ci had | |
| 20:35:10 | sean-k-mooney | we coudl maybe ask operators to donate such a nodeset | |
| 20:35:38 | mriedem | that's what the openlab request from artom was fore | |
| 20:35:40 | mriedem | *for | |
| 20:35:56 | mriedem | but that would definitely be a periodic queue kind of thing | |
| 20:36:06 | mriedem | or on-demand at best | |
| 20:36:20 | artom | And also, if we get nested virt, do we need multiple physical NUMA nodes? | |
| 20:36:42 | artom | mriedem, yeah, but better than nothing | |
| 20:37:09 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Error out migration when confirm_resize fails https://review.openstack.org/652127 | |
| 20:37:10 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Delete allocations even if _confirm_resize raises https://review.openstack.org/652146 | |
| 20:37:19 | mriedem | eandersson: ^ that should do it | |
| 20:37:54 | sean-k-mooney | artom: about 10 | |
| 20:38:01 | sean-k-mooney | we started wtih 3 | |
| 20:38:07 | sean-k-mooney | then grew to 5 | |
| 20:38:11 | artom | sean-k-mooney, ah, that makes more sense | |
| 20:38:23 | mriedem | speaking of ci, the ibm zkvm ci should be shutdown | |
| 20:38:25 | artom | So clearly the 1 or 2 machines we might get from openlab won't handle it ;) | |
| 20:38:29 | mriedem | fails immediately | |
| 20:38:49 | sean-k-mooney | artom: actully it coudl depending on how you set it up | |
| 20:38:55 | artom | sean-k-mooney, remind me why need multiple physical NUMA nodes? I recall having this conversation with you before... | |
| 20:39:08 | artom | Can't the all be nested virt multinode? | |
| 20:39:11 | artom | *they all | |
| 20:39:52 | sean-k-mooney | we coudl if i was allowed to change the libvirt dirver code but everytime i suggest it people complain | |
| 20:40:05 | artom | Eh? | |
| 20:40:33 | sean-k-mooney | in the libvirt driver we implemented it in such a way as to always map virtual numa nodes to different phyical numa nodes | |
| 20:40:52 | sean-k-mooney | but we never ever said that was guarenteed | |
| 20:41:08 | sean-k-mooney | but it was someing people observed and started to depend on | |
| 20:41:14 | artom | Oh right, that was the thing. If this was pure libvirt/kvm we could | |
| 20:41:26 | artom | But because our dsvm will be servers in an openstack cloud | |
| 20:41:26 | sean-k-mooney | yes and we could in nova | |
| 20:41:34 | artom | We're limited by that thing | |
| 20:41:44 | sean-k-mooney | this is purly a nova limitation | |
| 20:42:19 | sean-k-mooney | we coudl cange the code however | |
| 20:42:30 | artom | Seems like a lot of work :) | |
| 20:42:44 | sean-k-mooney | if you use multipl virtual numa nodes on hyperv i dont think they give the same guarentee | |
| 20:42:45 | melwitt | fried_rice: thanks | |
| 20:42:46 | artom | No reason we can't push the openlab thing as far as it'll go first | |
| 20:43:00 | mriedem | cfriesen: how much does this matter to you guys? https://bugs.launchpad.net/nova/+bug/1824420 | |
| 20:43:01 | openstack | Launchpad bug 1824420 in OpenStack Compute (nova) "Live migration succeeds but instance-action-list still has unexpected Error status" [Undecided,Triaged] | |
| 20:43:36 | sean-k-mooney | artom: you know after i get a gate job working i might actully put up a patch to make the numa maping configurable | |
| 20:44:23 | sean-k-mooney | i at least want to see how invaisge it woudl be to allow it. i thnk it would be a very minor change but that code is ... | |
| 20:44:46 | artom | Doesn't feel very minor, but you probably know that code better than I do | |
| 20:45:26 | sean-k-mooney | its a slight tweek to how we iterate over the posible permutaion in the hardware.py module when we fit an instance to the host | |
| 20:46:10 | sean-k-mooney | currently wehn we alocate a instance numa node to a host cell we dont consider that cell again for subsequent guest numa nodes | |
| 20:54:16 | mriedem | melwitt: dansmith: please to be reviewing these backports https://review.openstack.org/#/q/topic:bug/1669054+branch:stable/queens | |
| 20:56:17 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Error out migration when confirm_resize fails https://review.openstack.org/652150 | |
| 20:56:36 | dansmith | feel like I've reviewed these so many times | |
| 20:57:14 | openstackgerrit | François Palin proposed openstack/nova master: nova diagnostics command is not working with all interfaces https://review.openstack.org/648123 | |
| 20:59:28 | dansmith | mriedem: shall I slam these? | |
| 21:03:32 | melwitt | I can review too | |
| 21:03:46 | dansmith | they're ready for +W | |
| 21:04:00 | melwitt | coolio | |
| 21:04:53 | mriedem | dansmith: because we have 5 stable branches now :) | |
| 21:05:15 | dansmith | mriedem: I know.. I was being fuh shee zus | |
| 21:05:33 | mriedem | i'm very sensitive | |
| 21:06:37 | sean-k-mooney | artom: by the way the 2 server from openlab shoudl be enough to handel nova if we can get 12-14 vms running jobs in paralles and can keep the job under 2.5-3 hours | |
| 21:06:40 | melwitt | conflict city | |
| 21:06:51 | sean-k-mooney | anyway enjoy ye're weekend o/ | |
| 21:07:46 | mriedem | oh i forgot i'd backported https://review.openstack.org/#/c/648691/ | |
| 21:08:32 | mriedem | oh nvm you're talking about something else | |
| 21:10:39 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Delete allocations even if _confirm_resize raises https://review.openstack.org/652153 | |
| 21:18:00 | melwitt | mriedem: I noticed remnants of unused retry code in the test https://review.openstack.org/#/c/649363/1/nova/tests/unit/objects/test_request_spec.py did you want to just leave it or? | |
| 21:20:26 | mriedem | oh yeah... | |
| 21:21:30 | mriedem | replied; i could remove it, but then have to redo my pike and ocata cherry picks | |
| 21:21:38 | mriedem | i'm fine either way | |
| 21:21:58 | melwitt | ok, I guess I choose path of least work and leave it | |
| 21:22:12 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Error out migration when confirm_resize fails https://review.openstack.org/652127 | |
| 21:22:13 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Delete allocations even if _confirm_resize raises https://review.openstack.org/652146 | |
| 21:24:23 | mriedem | that's what i like to hear | |
| 21:24:48 | melwitt | I was thinking if it was an easy inline edit, that would be cool. but meh if you have to redo other stuff | |
| 21:25:18 | mriedem | i'm sure i'll never have to touch this request spec code again in these old stable branches... | |
| 21:25:30 | melwitt | right exactly | |
| 21:25:47 | melwitt | request spec is solid | |
| 21:48:45 | mriedem | eandersson: let me just say it's good you went to rocky rather than pike because trying to get that allocation leak fix back to pike is a huge pain in the ass, so i'm just going to not work on that for pike unless someone comes along and really needs it | |
| 22:03:19 | eandersson | I wish we could go to stein tbh, but we still rely on some vendor drivers | |
| 23:20:33 | openstackgerrit | Merged openstack/nova stable/stein: Error out migration when confirm_resize fails https://review.openstack.org/649421 | |
| 23:20:39 | openstackgerrit | Merged openstack/nova stable/stein: Delete allocations even if _confirm_resize raises https://review.openstack.org/650437 | |
| 23:20:45 | openstackgerrit | Merged openstack/nova stable/queens: Add functional regression test for bug 1669054 https://review.openstack.org/649362 | |
| 23:20:47 | openstack | bug 1669054 in OpenStack Compute (nova) queens "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Medium,In progress] https://launchpad.net/bugs/1669054 - Assigned to Matt Riedemann (mriedem) | |
| 23:20:52 | openstackgerrit | Merged openstack/nova stable/queens: Do not persist RequestSpec.ignore_hosts https://review.openstack.org/649363 | |
| 23:39:59 | cfriesen | mriedem: sorry, was having computer issues. I think that would be lowish priority. makes it a bit harder to write automated stuff if there are spurious error events. | |
| 23:59:23 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.openstack.org/639396 | |
| 23:59:23 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [DNM: extra logs] Revert resize: wait for external events in compute manager https://review.openstack.org/644881 | |
| 23:59:24 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: DNM: extra logging in neutron api for revert resize https://review.openstack.org/652174 | |
| 23:59:53 | artom | Oh, if you want to change the subject you can't just edit them in `git rebase -i` | |
| #openstack-nova - 2019-04-13 | |||
| 00:00:05 | artom | *shrug* it's all a big WIP/DNM mess anyways for now | |
| 00:35:22 | eandersson | Got a fun one | |
| 00:35:30 | eandersson | Nova deleted the compute, but it very much still exists | |