| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 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 | cdent: | |
| 13:19:15 | efried | @retrying.retry(stop_max_attempt_number=4, | |
| 13:19:15 | efried | retry_on_exception=lambda e: isinstance( | |
| 13:19:15 | efried | e, exception.ResourceProviderUpdateConflict)) | |
| 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 | kashyap | stephenfin: ^ | |
| 13:33:22 | efried | stephenfin, gibi, sean-k-mooney: ack, no big hurry I guess. Thanks kashyap. | |
| 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 | stephenfin | *spec review day | |
| 13:35:11 | sean-k-mooney | stephenfin: yes | |
| 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 | |