| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 13:04:58 | sean-k-mooney | gibi alex_xu just responded to https://review.opendev.org/#/c/662264/5 ill respin in an hour or two and adress the issue you raised, let me know if the repsoces make sense or if you have other question and ill adress them all as part of the respin. thanks for reviewing :) | |
| 13:05:24 | gibi | sean-k-mooney: ack | |
| 13:08:20 | gibi | sean-k-mooney: your responses looks good to me | |
| 13:08:52 | sean-k-mooney | ok ill leave it as is for people to leave more feedback if the chose too and ill resping as i said in an hour or so | |
| 13:09:10 | gibi | sean-k-mooney: cool | |
| 13:09:23 | sean-k-mooney | in general are you ok with the feature? include the seperate RPs to make reshap simpler in the future? | |
| 13:10:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Stabilize unshelve notification sample tests https://review.opendev.org/668675 | |
| 13:10:52 | gibi | efried, mriedem: super simple test only change ^^ | |
| 13:12:10 | sean-k-mooney | i need to read the commit but how is this sablising the test? | |
| 13:13:03 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Add "Secure Boot support for KVM & QEMU guests" spec https://review.opendev.org/506720 | |
| 13:13:43 | kashyap | lyarwood: Hey, when you get 10-ish minutes, want to have a gander at ⮭ | |
| 13:14:11 | kashyap | (You looked at it previously.) I've also included a short changelog of all the things I addressed, based on johnthetubaguy's feedforward. | |
| 13:16:00 | lyarwood | kashyap: ack will do | |
| 13:16:54 | efried | sean-k-mooney: Thanks for pointing out that MKTME spec. I was expecting it to show up, but didn't see it come in for some reason, possibly because it's proposed to backlog/ and I'm focused on train/. | |
| 13:17:21 | sean-k-mooney | oh i totally missed that | |
| 13:17:28 | sean-k-mooney | i thought it was for train | |
| 13:17:31 | efried | cdent: Unfortunately set_inventory_for_provider retry isn't "clean" because it goes through a dozen layers of the periodic update in the resource tracker | |
| 13:17:39 | efried | gibi: ack | |
| 13:18:10 | sean-k-mooney | in that case im less worried about the scope/alingment with the current sev spec | |
| 13:18:19 | mriedem | lyarwood: melwitt: i replied about the conflicts in this queens backport https://review.opendev.org/#/c/662471/ | |
| 13:18:24 | gibi | sean-k-mooney: yes, those test could fail if the timing is unlucky | |
| 13:18:54 | sean-k-mooney | ya i just figured out how this fixes it | |
| 13:18:56 | efried | cdent: oh, actually, snot so bad. set_inventory_for_provider called by update_from_provider_tree (both in report client) called by _update_to_placement (in resource tracker) | |
| 13:19:04 | efried | cdent: _update_to_placement has the retry decorator on it. | |
| 13:19:11 | sean-k-mooney | gibi: we are setting up the verifies but the test could end before the notificaion is sent | |
| 13:19:15 | efried | e, exception.ResourceProviderUpdateConflict)) | |
| 13:19:15 | efried | retry_on_exception=lambda e: isinstance( | |
| 13:19:15 | efried | @retrying.retry(stop_max_attempt_number=4, | |
| 13:19:15 | efried | cdent: | |
| 13:19:26 | mriedem | lyarwood: sean-k-mooney: is stephenfin around this week? | |
| 13:19:45 | sean-k-mooney | mriedem: he was on eairlier | |
| 13:20:09 | sean-k-mooney | mriedem: and he does not have PTO in our team calander so i think so | |
| 13:20:17 | gibi | sean-k-mooney: yes, to core of the issue is that instance.vm_state is set ACTIVE before the the end notification is emitted but the test only waits for the ACTIVE state | |
| 13:20:23 | sean-k-mooney | he might be at the gym at the moment | |
| 13:20:26 | mriedem | ok looking for answers on this queens numa live migration change https://review.opendev.org/#/c/629597/ | |
| 13:20:57 | sean-k-mooney | mriedem: ya i was planning to bug him about that chagne today too | |
| 13:21:38 | sean-k-mooney | mriedem: your trying to do a queens release soon right | |
| 13:21:54 | stephenfin | mriedem: I'm here, yeah | |
| 13:21:56 | sean-k-mooney | i would like to include that in the next queens release if we can | |
| 13:22:28 | stephenfin | mriedem: Saw comments on a queens backport in the scrollback. I'll get to that once I've finished with this mountain of email :'( | |
| 13:23:52 | efried | yaawang: If you like, I can update the cpu_models spec real quick | |
| 13:24:07 | mriedem | sean-k-mooney: yes i'm flushing for a queens release | |
| 13:24:20 | mriedem | nearly there https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/queens+label:Code-Review=2 | |
| 13:27:27 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.opendev.org/642030 | |
| 13:31:25 | efried | alex_xu, stephenfin, gibi: I'm +2 on ^ if one of you wants to push it. | |
| 13:31:54 | efried | kashyap: Are you convinced enough of the use case to accept this being implemented? ^ | |
| 13:31:56 | stephenfin | efried: The spec? Has kashyap looked through that again? | |
| 13:31:59 | stephenfin | Jinx :) | |
| 13:32:30 | stephenfin | I'd like to look through that again myself. Can we hold off until tomorrow at least? If I don't get to it by then, carry on | |
| 13:32:33 | efried | kashyap: note that under the latest design proposal, existing confs will continue to work, so the load on the deployer isn't as great. | |
| 13:32:37 | sean-k-mooney | ill quickly re reivew it too now but i was ok with the usecase in the past i think | |
| 13:33:16 | kashyap | efried: Will look once I address gibi's comments in my own spec | |
| 13:33:22 | efried | stephenfin, gibi, sean-k-mooney: ack, no big hurry I guess. Thanks kashyap. | |
| 13:33:22 | kashyap | stephenfin: ^ | |
| 13:34:01 | sean-k-mooney | efried: its proably one of the spec we should be able to close out on today as part of the review day | |
| 13:34:09 | kashyap | gibi: On the Secure Boot thing, fixing your remarks. My eyes are glazing over from looking at my own text. Note that the "firmware descriptor files" from QEMU are nice-to-have, but doesn't block Train | |
| 13:34:15 | kashyap | I'll add notes there. | |
| 13:34:19 | efried | sean-k-mooney: yeah, that was my hope :) | |
| 13:34:28 | gibi | kashyap: ack | |
| 13:34:31 | sean-k-mooney | efried: by the way do you have the link handy to the dashboard you created | |
| 13:34:33 | kashyap | sean-k-mooney: I was not OK with the spec, and actually abandoned it | |
| 13:34:41 | efried | sean-k-mooney: https://etherpad.openstack.org/p/nova-spec-review-day | |
| 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. | |