| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-22 | |||
| 07:26:37 | bauzas | good morning Nova | |
| 07:33:39 | aarents | 'morning | |
| 08:22:02 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548 | |
| 08:22:20 | bauzas | last iteration of prelude ^ | |
| 09:57:24 | openstackgerrit | Merged openstack/os-resource-classes master: Cleanup py27 support https://review.opendev.org/719351 | |
| 10:42:28 | gibi | lyarwood: hi! do you still plan to have a stable release this week? | |
| 10:43:39 | kashyap | lyarwood: I have this open, will check this today: https://zuul.opendev.org/t/openstack/build/8011a4c1b08e4b9d921660d0c5c2505d | |
| 10:43:45 | kashyap | The virt-preview + Q35 job failure | |
| 10:47:15 | zigo | elod: Should you recheck https://review.opendev.org/711233 ? | |
| 10:47:26 | zigo | The errors look like unrelated. | |
| 10:56:39 | elod | zigo: thanks, yes they seem unrelated, I've initiated the recheck | |
| 10:57:16 | elod | zigo: could you test perhaps the patch somewhere? | |
| 11:00:38 | lyarwood | gibi: yup sorry just on a call, back in 10 | |
| 11:01:37 | gibi | lyarwood: no prob | |
| 11:09:00 | zigo | elod: I can yes. | |
| 11:09:15 | zigo | elod: Also, I have tons of warning like this one: "Instance d459e746-ac99-448b-9e44-890fbfdcb6f0 has been moved to another host hostB(hostB). There are allocations remaining against the source host that might need to be removed: {u'resources': {u'VCPU': 1, u'MEMORY_MB': 512, u'DISK_GB': 1}}." | |
| 11:09:25 | zigo | elod: Can this also be due to the same problem ? | |
| 11:10:20 | zigo | elod: Also, I'm unsure how to reproduce the failed migration though ... | |
| 11:10:38 | zigo | That's kind of needed if I want to test your patch, no? | |
| 11:14:32 | lyarwood | gibi: back, so yeah I did want to propose something for each supported branch. I'll get something posted later today for Train and work back from there. | |
| 11:14:36 | lyarwood | elod: ^ FYI | |
| 11:14:56 | lyarwood | kashyap: ack thanks, I've not had a chance to look through it all yet, I assume there's f31 failures in there tbh. | |
| 11:25:10 | elod | lyarwood: thanks for doing that! is there anything waiting for review and then merged before the relese? | |
| 11:27:00 | lyarwood | elod: not for stable/train | |
| 11:27:05 | elod | lyarwood: and of course I can also try to prepare the release patches if needed (do we need other than that for the release?) | |
| 11:27:23 | lyarwood | looks like we have a few things in stable/stein | |
| 11:27:34 | lyarwood | elod: if you have bandwidth then please feel free to do so for train | |
| 11:27:57 | kashyap | lyarwood: Nod | |
| 11:28:47 | elod | lyarwood: sure, I'll do that now | |
| 11:28:54 | lyarwood | awesome thanks elod | |
| 11:32:35 | elod | zigo: hmmm, interesting. I have to check that. About reproduction: there are steps in the bug report but I think that not everything are needed, but haven't looked at it yet. | |
| 11:33:30 | sean-k-mooney | alex_xu: by the way i dont know why https://review.opendev.org/#/c/662264/ that show up as last updted 2 days ago i have not touch it since i abandonded it last august and there has been no update to it in the last 2 days | |
| 11:37:59 | sean-k-mooney | alex_xu: my best guess is someone removed there name form the review list or something like that. | |
| 11:45:40 | openstackgerrit | Qiu Fossen proposed openstack/nova master: The instance is volume backed and power state is PAUSED，shelve the instance failed https://review.opendev.org/711609 | |
| 11:55:29 | gibi | lyarwood, elod: thanks a lot! | |
| 12:05:02 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Make Q35 machine type the default for x86 https://review.opendev.org/631154 | |
| 12:05:18 | kashyap | lyarwood: --^ For your "copious free time" :) | |
| 12:05:39 | kashyap | lyarwood: I also threw you under the "liaoson bus" without asking checking in first with you ... | |
| 12:17:20 | sean-k-mooney | kashyap: im not actully sure we shoudl be doing that vs the hw:profile concept | |
| 12:17:48 | kashyap | sean-k-mooney: Well, is there something up for the hw:profile thing? | |
| 12:18:00 | kashyap | sean-k-mooney: And why not? 'pc' will be dead _anyway_ | |
| 12:18:04 | sean-k-mooney | no not yet | |
| 12:18:07 | kashyap | And we'll be doing the operators a disservice | |
| 12:18:12 | kashyap | I know; not at least for 5 years | |
| 12:18:19 | sean-k-mooney | kashyap: because we can potentailly break people on upgrade | |
| 12:18:29 | sean-k-mooney | its the same reason libvirt did not change the default | |
| 12:18:58 | kashyap | Well, the discussion there is _far_ more nuanced; libvirt is different - it gives the nuts and bolts | |
| 12:19:23 | kashyap | I actually had a few paragraphs of text in the spec (but deleted), they were about: | |
| 12:19:34 | sean-k-mooney | kashyap: there are other factors but that does not demish the fact that we have many fo the same constratints | |
| 12:19:54 | kashyap | ... whether Nova shold make the 'policy' decision. I wrote an example, etc. But cut it out after I saw the recommendations from the QEMU/KVM/libvirt folks over the year | |
| 12:20:28 | kashyap | sean-k-mooney: Yeah, I'm aware of why libvirt did it; I've even linked to it in a previous edition of the commit message | |
| 12:20:36 | kashyap | (The exact change of libvirt and its reasoning) | |
| 12:20:50 | kashyap | sean-k-mooney: I'm typing fast, as I need to have lunch and head out for some air, been cooped up long | |
| 12:20:56 | kashyap | But will catch here later | |
| 12:21:46 | sean-k-mooney | ok but as it stand while i think we shoudl make q35 our default in osp in not sure if we shoudl chagne the code to do that | |
| 12:23:47 | kashyap | sean-k-mooney: Before I head out: | |
| 12:23:49 | kashyap | I'm also open for this: | |
| 12:23:56 | kashyap | - A Nova CI job with 'q35' passes | |
| 12:24:11 | kashyap | - TripleO flips the default from 'pc' --> 'q35' | |
| 12:24:12 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846 | |
| 12:24:14 | sean-k-mooney | kashyap: lyarwood is working to make nova-next do that | |
| 12:24:34 | kashyap | sean-k-mooney: Yes, I investigated the failures yesterday and posted a Tempest one-liner for the failing test | |
| 12:24:39 | kashyap | All linked in the spec | |
| 12:24:42 | sean-k-mooney | the ci job and then ya the plan as far as i understood for osp was to change the default in ooo | |
| 12:25:05 | kashyap | sean-k-mooney: Yes, TripleO upstream has this posted: https://review.opendev.org/#/c/716526/ | |
| 12:25:11 | kashyap | It is waiting on the Nova CI | |
| 12:25:22 | sean-k-mooney | ah cool | |
| 12:25:40 | sean-k-mooney | im reading your spec now. go have lunch :) | |
| 12:26:43 | kashyap | sean-k-mooney: Thanks. :) Likewise | |
| 12:33:14 | bauzas | gibi: can I hold the bugs lock again ? | |
| 12:33:44 | bauzas | aarents: thanks for reporting https://bugs.launchpad.net/nova/+bug/1874032 | |
| 12:33:44 | openstack | Launchpad bug 1874032 in OpenStack Compute (nova) "nova-compute become stuck when doing IO on busy file system" [Undecided,New] | |
| 12:34:26 | gibi | bauzas: sue | |
| 12:34:28 | gibi | sure | |
| 12:35:02 | gibi | I'm swamped with a downstream stuff with a close deadline | |
| 12:35:09 | aarents | bauzas: this one is painfull.. | |
| 12:35:13 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548 | |
| 12:35:31 | bauzas | gibi: <3 with love for your pain | |
| 12:36:05 | bauzas | aarents: sure, but I think it should be a Wishlist bug | |
| 12:36:29 | gibi | bauzas: thanks | |
| 12:36:59 | gibi | funny that RC1 is due tomorrow and my downstream high prio stuff due today (but was not on the radar until Monday) | |
| 12:39:38 | bauzas | gibi: in my company, we also have sometimes some downstream priorities that are in the same times than upstream yes... | |
| 12:39:50 | bauzas | I totally understand you :p | |
| 12:39:58 | bauzas | aarents: so, about your bug | |
| 12:41:08 | bauzas | aarents: you asked why we don't have compute workers, right? | |
| 12:41:20 | aarents | yep | |
| 12:41:34 | bauzas | b/c there is only one service per host | |
| 12:42:16 | bauzas | and in general, when you want to call some I/O issue, you don't do this by the nova-compute service | |
| 12:42:47 | bauzas | that's rather the nova-compute service which calls privsep | |
| 12:45:06 | bauzas | aarents: eg. https://github.com/openstack/nova/blob/master/nova/privsep/qemu.py#L37 | |
| 12:45:57 | bauzas | and then as you can see we call processutils.execute() https://github.com/openstack/nova/blob/master/nova/privsep/qemu.py#L81 | |
| 12:47:08 | aarents | bauzas: ok.. so to workaround this we have to put glance upload outside of nova-compute, in fact that what I've done to fix that on our release I made an execute(*curl).. | |
| 12:48:10 | bauzas | aarents: do you have I/O issues when snapshoting or uploading ? | |
| 12:48:22 | bauzas | from what I see, you generate some I/O calls | |
| 12:48:41 | bauzas | so I thought the problem would be around snapshoting, not uploading to glance | |
| 12:48:43 | aarents | yes during glance upload because IO is made inside nova-compute | |
| 12:49:10 | bauzas | we don't write on disk when we do glance upload, do we ? | |
| 12:49:20 | aarents | the glance upload done during instance snapshot | |
| 12:50:09 | aarents | we read an extracted file (done by qemu-ing convert)) | |
| 12:50:14 | aarents | localy | |