| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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 | |
| 14:54:35 | efried | alex_xu: if you're around, would you like the +W on https://review.opendev.org/#/c/642030/ ? Else I'll push it in a bit. | |
| 14:55:14 | kashyap | yaawang: Hi, please copy me on the impl of that 'cpu_models' thing. Happy to work out the details. | |
| 14:57:48 | kashyap | LOL | |
| 14:57:57 | kashyap | (Sorry) | |
| 15:04:18 | spatel | sean-k-mooney: morning | |
| 15:04:28 | sean-k-mooney | spatel: o/ | |
| 15:05:24 | spatel | I have testing my new openstack cloud, i have spun vm-1 but i am not seeing any live migration option in drop down menu | |
| 15:05:42 | gibi | kashyap: it is the remains of time I worked on versioned notifications a lot | |
| 15:05:53 | sean-k-mooney | spatel: that sound like a horizon issue | |
| 15:06:10 | spatel | hmm! | |
| 15:06:23 | sean-k-mooney | im not sure how that is displayed but i would not expect horizon to be able to tell if live migration is uspported | |
| 15:06:37 | sean-k-mooney | we do not have a api you can query to discover that | |
| 15:07:00 | kashyap | gibi: Yeah, guessed as much :-) | |
| 15:07:01 | sean-k-mooney | we just have teh endpoint to do a migration which can succeed or fail wehn you call it | |
| 15:07:07 | kashyap | sylvainb: Quite active discussion on that 'mdevctl' thread on libvirt upstream thread | |
| 15:07:17 | kashyap | Err, bauzas: | |
| 15:08:11 | kashyap | (I see that you wanted to try it, 'mdevctl' in Nova. Haven't caught up with the rest of the KM-long thread there, though.) | |
| 15:09:33 | spatel | sean-k-mooney: oh wait, when i logged in as admin i can see live migration | |
| 15:09:48 | sean-k-mooney | spatel: yes live migration is admin only | |
| 15:09:49 | spatel | its not available for end-user | |
| 15:10:23 | sean-k-mooney | spatel: yep the only action an endupser can do that might casue a migration to happen is resize | |
| 15:11:16 | spatel | yes they do have re-size option but not live, i think this is good because we don't want end user do live migration without understanding | |
| 15:11:47 | sean-k-mooney | yep | |
| 15:12:25 | spatel | sean-k-mooney: how do i evacuate single VM? is it something only available in command line? | |
| 15:13:04 | sean-k-mooney | proably. yes | |