| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 13:34:45 | sean-k-mooney | efried: thanks | |
| 13:34:47 | kashyap | But it was re-opened, and I want to see if I can convince myself again | |
| 13:34:56 | efried | sean-k-mooney: front matter has a couple of gerrit dashboard links. | |
| 13:35:00 | stephenfin | Is today a review day? | |
| 13:35:11 | sean-k-mooney | stephenfin: yes | |
| 13:35:11 | stephenfin | *spec review day | |
| 13:35:19 | sean-k-mooney | i think the final one for train | |
| 13:35:22 | stephenfin | Crap. Ugh. Too much to do | |
| 13:35:25 | efried | stephenfin: http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007381.html | |
| 13:35:34 | efried | I should have sent a reminder last night, mahbad. | |
| 13:36:08 | sean-k-mooney | spec freeze is july 25th i think so thusday 3 weeks | |
| 13:36:47 | stephenfin | I'll try schedule that for this evening so. Feck the emails | |
| 13:37:07 | openstackgerrit | Theodoros Tsioutsias proposed openstack/nova-specs master: Add PENDING vm state https://review.opendev.org/648687 | |
| 13:38:42 | alex_xu | sean-k-mooney: you want to use the min and max of inventory for the fixed size cache,right? | |
| 13:39:36 | sean-k-mooney | sorry yes min max and step size should all be set to the same | |
| 13:39:41 | sean-k-mooney | to prevent the fragmenation | |
| 13:39:45 | sean-k-mooney | not just step size | |
| 13:40:07 | lyarwood | sean-k-mooney: just posted some addition nits in the pqos spec if you're going over it still | |
| 13:40:37 | sean-k-mooney | lyarwood: i was going to leave them build up until 1600 then adress them all | |
| 13:41:02 | alex_xu | cool, sounds cool for me | |
| 13:41:10 | sean-k-mooney | but yes im checking it every so often | |
| 13:41:22 | lyarwood | sean-k-mooney: ack | |
| 13:42:44 | sean-k-mooney | alex_xu: woudl you prefer to manage the min/max/step size via the placmenet api as i was propsoeing or should i update the spec to have a config option | |
| 13:43:51 | kashyap | gibi: I'd need your re-ACK as I'm fixing the two other broken sentences, and add a note on the QEMU dep for nice-to-have. | |
| 13:44:26 | efried | Is /servers/{server_id}/action Create Image (createImage Action) aka "snapshot"? | |
| 13:44:27 | gibi | kashyap: just ping me | |
| 13:45:01 | gibi | kashyap: when you are ready | |
| 13:45:04 | kashyap | alex_xu: Are you convinced of that CPU models thing? WheN I explained this spec to two QEMU maintainers, they said "don't do that" (the CPU models as list). But rather allow them setting via flavor properties, if you want | |
| 13:45:10 | kashyap | gibi: Yep, juggling multiple things | |
| 13:45:12 | alex_xu | sean-k-mooney: I prefer to have config option. otherwise, I'm thinking how do we deal with the update_provider_tree and the user update | |
| 13:45:26 | kashyap | alex_xu: I'll comment in full, once I flush existing content to my brain's disk | |
| 13:45:32 | sean-k-mooney | efried: the create image action i think is snapshot yes | |
| 13:46:09 | sean-k-mooney | alex_xu: for update provider tree i planned to have nova only set them if it creating the inventory initailly | |
| 13:46:26 | alex_xu | kashyap: as my understand, that spec doesn't helpful for your flaw mitigation case, but that spec aims to live migration case | |
| 13:46:49 | sean-k-mooney | so update provider tree would not modify them but ill add the config option in the next version so since that is simple | |
| 13:46:58 | kashyap | alex_xu: Yeah, I do see the use case, though. Not denying that | |
| 13:47:12 | efried | looks like snapshot may also be used for shelve | |
| 13:47:40 | kashyap | alex_xu: Just weighing the costs, and if it'll come to bite us in a different scenario -- as it's hard to think through _all_ the cases that might be affected here. | |
| 13:47:50 | sean-k-mooney | efried: yes when we shelve we snapshot the root disk | |
| 13:48:06 | sean-k-mooney | but im not sure if we only do that for shelve offload | |
| 13:48:14 | sean-k-mooney | or if it happens on shelve | |
| 13:53:01 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events https://review.opendev.org/664442 | |
| 13:53:11 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events https://review.opendev.org/664442 | |
| 13:54:17 | sean-k-mooney | jinx | |
| 13:57:26 | artom|gmtplus3 | Dammit, 11 seconds | |
| 14:00:59 | sean-k-mooney | i did it via the gerrit ui | |
| 14:01:40 | sean-k-mooney | given the gate lag time it makes no difference :) | |
| 14:05:53 | gibi | sean-k-mooney: replied in https://review.opendev.org/#/c/668675 | |
| 14:07:08 | kashyap | gibi: A small heads-up: I've also fixed two more small things related to content moving. I'll append a short summary of changes for convenience, once the docs compile locally. | |
| 14:07:21 | gibi | kashyap: OK, I will look at the diff | |
| 14:08:32 | sean-k-mooney | gibi: oh wiat thost are not test they are test helper functions because they are prefixed wtih _ | |
| 14:08:51 | gibi | sean-k-mooney: yeah, they are steps of a biiig test case | |
| 14:08:53 | sean-k-mooney | so _test_shelve_and_shelve_offload_server is beeing invoked elsewhere | |
| 14:09:21 | sean-k-mooney | ah ok in that case your change makes sense i missed that | |
| 14:09:25 | gibi | sean-k-mooney: it is invoked exactly before _test_unshelve_server() | |
| 14:09:32 | sean-k-mooney | i was wondering why you were doing extra work when you did not need too | |
| 14:09:45 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.opendev.org/506720 | |
| 14:09:48 | gibi | sean-k-mooney: this is the test case https://review.opendev.org/#/c/668675/1/nova/tests/functional/notification_sample_tests/test_instance.py@342 | |
| 14:10:09 | sean-k-mooney | well in that case i dont think you need to do the unshelve right? | |
| 14:10:46 | kashyap | gibi: When you can: done. Posted the shortlog as well. | |
| 14:10:46 | sean-k-mooney | you are doing an extra unchelve and shelve that are not needed | |
| 14:10:54 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/stein: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.opendev.org/667354 | |
| 14:11:06 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.opendev.org/667355 | |
| 14:11:36 | sean-k-mooney | gibi: if _test_shelve_and_shelve_offload_server left it shelved and _test_unshelve_server required a shelved server it would speed up the test case | |
| 14:11:36 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/rocky: Ignore hw_vif_type for direct, direct-physical vNIC types https://review.opendev.org/667355 | |
| 14:12:30 | gibi | sean-k-mooney: I could skip that but then instance would be in SHELVED case between the steps and that would ruin the generic pre-condition of the test steps enforced in https://review.opendev.org/#/c/668675/1/nova/tests/functional/notification_sample_tests/test_instance.py@384 | |
| 14:13:15 | gibi | sean-k-mooney: I could combine the two test step | |
| 14:13:17 | sean-k-mooney | i see | |
| 14:13:26 | gibi | kashyap: ack | |
| 14:13:42 | kashyap | Thanks a ton. | |
| 14:13:58 | sean-k-mooney | into a _test_shelve_shelve_offload_unshelve_server | |
| 14:14:10 | sean-k-mooney | ya that would be more efficent | |
| 14:15:13 | sean-k-mooney | and it would not violate the pre/post condition that the server is active between all steps | |
| 14:16:06 | sean-k-mooney | gibi: that said, these are fucntional tests | |
| 14:16:29 | gibi | kashyap: I'm +2 on the secure boot | |
| 14:16:29 | sean-k-mooney | so we are not actully snapshoting the server and uploading it to glance and then restoring it | |
| 14:16:52 | sean-k-mooney | so what you have is proably fine for the fake driver/fake libvirt whichever we are actully using | |
| 14:16:58 | kashyap | gibi: Thank you. And FWIW, I'm giving a "semi-strong +1" to to the CPU models thing, with a note. | |
| 14:17:08 | gibi | kashyap: thanks | |
| 14:17:13 | kashyap | As I don't want to block it any further, and we can hash out the details in the implementation. | |
| 14:18:49 | gibi | kashyap: ack | |
| 14:25:29 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fail to live migration if instance has a NUMA topology https://review.opendev.org/629597 | |
| 14:25:42 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: fix up numa-topology live migration hypervisor check https://review.opendev.org/648939 | |
| 14:26:21 | mriedem | lyarwood: can you hit https://review.opendev.org/#/c/629597/ ? | |
| 14:30:35 | mriedem | coreycb: can you ack this? https://review.opendev.org/#/c/668680/ | |
| 14:41:45 | efried | kashyap: Did you forget to hit save or are you still composing? | |
| 14:42:04 | kashyap | efried: Forgot to hit save, bad me. A sec | |
| 14:42:33 | kashyap | Oh, I went noting some grammar nit, and then two other people pinged and got distracted | |
| 14:43:19 | kashyap | efried: Done. | |
| 14:43:32 | efried | thanks kashyap | |
| 14:43:53 | kashyap | We can hash out the technical details (and surely we'd want to do some some robust functional testing _and_ post the results in the review for posterity/record) | |
| 14:44:00 | kashyap | ... in the implementation. | |
| 14:44:20 | kashyap | It's a +0.8. | |
| 14:46:03 | kashyap | efried: If you feel like fixing the grammar edit & re-ACK it; if you don't want to bother, also fine. | |
| 14:47:38 | efried | kashyap: I'm not being that picky anymore. | |
| 14:48:22 | kashyap | Can fully understand. It's just my OCD. | |
| 14:48:41 | kashyap | That's why I never -1 such things (unless it hampers reading, or is too sloppy). | |
| 14:53:47 | efried | kashyap: I've started blithely posting patch sets on other people's changes to correct grammar before I review for content. | |
| 14:54:26 | kashyap | efried: So you wanted to amend that behaviour? :-) | |
| 14:54:30 | kashyap | Can understand | |