| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-26 | |||
| 12:14:50 | openstackgerrit | Merged openstack/nova master: Fix indentation nits https://review.opendev.org/746765 | |
| 12:14:56 | openstackgerrit | Merged openstack/nova master: Remove deprecated scheduler filters https://review.opendev.org/744800 | |
| 12:15:04 | sean-k-mooney | bauzas: all move operation in the sepc are currently data perserving | |
| 12:15:21 | bauzas | I do understand the usecase | |
| 12:15:21 | sean-k-mooney | bauzas: we just copy the tpm data form one host to another | |
| 12:15:31 | bauzas | I'm just saying we are adding more than necessary | |
| 12:15:42 | bauzas | but again, the ship has sailed | |
| 12:16:01 | sean-k-mooney | bauzas: well it was felt that without perserving the data on move ops we could not resonably support them | |
| 12:16:02 | openstackgerrit | Merged openstack/nova master: tests: Add helpers for rebuild, cold migrate, and shelve/unshelve https://review.opendev.org/747792 | |
| 12:16:46 | sean-k-mooney | bauzas: complexity is a valid concern but i think the current semantics are what i would expect | |
| 12:19:51 | bauzas | sean-k-mooney: yup, and again, I won't bother | |
| 12:20:02 | bauzas | we had a consensus, I do respect it. | |
| 12:20:55 | efried | A lot of blood, sweat, and tears went into getting that spec to where it is. | |
| 12:21:14 | efried | Which involved some very heavy tradeoffs and compromises along the way. | |
| 12:21:33 | efried | There's some saying like, "You know it's a good compromise when nobody is happy." | |
| 12:22:57 | efried | Specifically to address the notion of pets: if you want a TPM, your VM is already a pet. | |
| 12:23:55 | gibi | efried: o/ | |
| 12:23:57 | efried | I will say that I am happy to see things like vTPM and provider config merging now -- two releases after I stopped working on them, which was multiple releases after I (and others) started working on them. | |
| 12:23:58 | elod | lyarwood: btw, should we wait this to merge too? >>> https://review.opendev.org/#/c/744550/ | |
| 12:24:25 | lyarwood | elod: that's less important tbh | |
| 12:24:42 | lyarwood | elod: just a nice to have, the other change fixes an issue introduced by an earlier change | |
| 12:26:01 | sean-k-mooney | efried: yep it will be nice to see them in the victoria project update hopefully as highlights | |
| 12:27:26 | elod | lyarwood: ok, then I've updated the release patch | |
| 12:28:38 | elod | the other patch unfortunately had to recheck anyway, so it would mean at least 3-4 hrs to merge... | |
| 12:32:11 | bauzas | gibi: lyarwood: stephenfin: -1 for relnote on https://review.opendev.org/#/c/631363/61 | |
| 12:33:13 | bauzas | stephenfin: I'm currently digging the long list of https://review.opendev.org/#/q/topic:bp/add-emulated-virtual-tpm+status:merged but I can't find where we defined docs | |
| 12:33:15 | gibi | ack, do we need to pull it out of the gate? | |
| 12:33:28 | gibi | bauzas: doc is in the next patch | |
| 12:33:38 | bauzas | ah right | |
| 12:33:39 | gibi | https://review.opendev.org/#/c/739213/17 | |
| 12:34:02 | bauzas | that's what I just saw | |
| 12:34:34 | bauzas | okay, I think we can leave as it is since lyarwood already approved the above patch but this sucks :( | |
| 12:34:58 | bauzas | and I personally feel we should rewrite the reno file to be more explicit by saying "sorry folks, only spawn as of now" | |
| 12:35:31 | bauzas | given what efried said on the life of pets, once people see TPM devices around in nova, they gonna start using those without knowing they're stukc | |
| 12:35:35 | bauzas | stephenfin: ^ | |
| 12:35:54 | gibi | bauzas: at least the doc is explicit about what does not work with vtpm | |
| 12:35:56 | bauzas | (provided we don't merge the move ops changes in the next 2 weeks obviously) | |
| 12:35:58 | stephenfin | bauzas: I can do a follow-up | |
| 12:36:05 | bauzas | stephenfin: wfm | |
| 12:36:11 | stephenfin | cool. gimme a sec | |
| 12:36:13 | bauzas | and yeah, docs are expicit | |
| 12:36:17 | bauzas | explicit even | |
| 12:36:58 | lyarwood | yeah I was under the impression that things were going to be enabled before GA anyway so it would be a waste of time detailing everything in the releasenote | |
| 12:37:05 | efried | BTW, it'll be a good idea to take your cues from jroll and penick if you have questions about how these are going to be used irl. They're the primary consumer driving this work, at least initially. | |
| 12:37:08 | lyarwood | as opposed to updating the docs | |
| 12:37:10 | bauzas | stephenfin: cool, and then say we support resize, you could then amend your renofile to include "spawn [and resize]" | |
| 12:37:38 | bauzas | lyarwood: I never predict on things being merged | |
| 12:37:45 | openstackgerrit | Lee Yarwood proposed openstack/nova master: rbd: Move rbd_utils out of libvirt driver under nova.storage https://review.opendev.org/746904 | |
| 12:37:46 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301 | |
| 12:37:46 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Bring back allowed_direct_url_schemes in support of RBD image download https://review.opendev.org/728095 | |
| 12:37:47 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Add devstack-plugin-ceph-compute-qcow2 to experimental queue https://review.opendev.org/743220 | |
| 12:38:05 | bauzas | lyarwood: and I'm on the likes to consider master as something usable as of now | |
| 12:38:05 | lyarwood | bauzas: right but my point is that it's easier to update the docs than a reno IMHO | |
| 12:38:18 | bauzas | lyarwood: but I know this is an utopia | |
| 12:38:35 | bauzas | lyarwood: well, it's just a file change, but either way | |
| 12:38:42 | bauzas | docs are good for getting all the details | |
| 12:38:49 | bauzas | release notes are good for knowing what's in the release | |
| 12:40:30 | openstackgerrit | Stephen Finucane proposed openstack/nova master: releasenotes: Detail support for server ops with vTPM https://review.opendev.org/748215 | |
| 12:40:44 | stephenfin | bauzas, gibi, lyarwood: nice and generic ^ | |
| 12:40:52 | bauzas | ++ | |
| 12:41:27 | sean-k-mooney | lyarwood: updating a reno is not that hard | |
| 12:41:40 | sean-k-mooney | we can even backport reno updtes it does actully work | |
| 12:41:44 | stephenfin | sean-k-mooney: it is tedious though | |
| 12:41:51 | bauzas | tedious in what ? | |
| 12:41:57 | stephenfin | especially when you've already got detailed info in docs | |
| 12:42:11 | bauzas | stephenfin: well, docs were giving me a 404 | |
| 12:42:16 | stephenfin | bauzas: to update incrementally as you tweak features | |
| 12:42:17 | bauzas | hence the -1 | |
| 12:42:18 | sean-k-mooney | yes as long as the reno is not wrong and directs you to the docs | |
| 12:42:28 | sean-k-mooney | then keeping the docs up to date makes sense | |
| 12:42:30 | lyarwood | bauzas: docs are the next change in the series | |
| 12:42:34 | stephenfin | oh, I thought that was okay since it's fixed in the next change? | |
| 12:42:34 | bauzas | I'm still on the side to have a digested list of features | |
| 12:42:49 | bauzas | stephenfin: I'd say I passed over ti | |
| 12:42:50 | bauzas | it | |
| 12:43:22 | bauzas | but again, and I know I'm now maybe in the minority, I don't like merging broken code that will be fixed in the next change of the series | |
| 12:43:25 | sean-k-mooney | stephenfin: i have done the update in the past its not that bad same as updating the docs | |
| 12:43:34 | bauzas | even if the change in question is next in the queue | |
| 12:43:45 | bauzas | that gives us bad habits | |
| 12:44:00 | stephenfin | true. It's not broken code though, in fairness :) | |
| 12:44:09 | lyarwood | are we classing releasenotes as code now? | |
| 12:44:14 | bauzas | it's broken docs, this is worst, indeed :p | |
| 12:44:16 | lyarwood | ops stephenfin beat me to it | |
| 12:44:24 | stephenfin | lyarwood: coke, please | |
| 12:44:56 | lyarwood | you're only getting warm tap water from me mate | |
| 12:45:23 | bauzas | in our example, we could have left the change as it is, with a reno file just giving the exact things you provided in your FUP, without providing a broken link | |
| 12:45:47 | bauzas | and in the next change, we could have provided the docs with an amended reno file that'd add the link | |
| 12:45:58 | bauzas | that's what I just call good habits | |
| 12:46:01 | stephenfin | yup, that's fair | |
| 12:46:47 | stephenfin | In this instance though, are you okay to leave it in the gate queue or should I pull it out and rework it? | |
| 12:46:50 | bauzas | stephenfin: on a fun side, should I *really* review https://review.opendev.org/#/c/742863/9 and all the type hints changes, given all the discussions we had in the past ? :D | |
| 12:47:04 | bauzas | stephenfin: nah, I said I can assume this being fixed automatically | |
| 12:47:12 | stephenfin | okay, cool | |
| 12:48:06 | bauzas | stephenfin: so, tbh, I guess you're doing https://review.opendev.org/#/c/742863/9/nova/compute/manager.py unrelated to the vTPM series, right? | |
| 12:48:07 | stephenfin | bauzas: Up to you :) It is really trivial, if that helps (not much hints being added, just getting mypy passing) | |
| 12:48:19 | bauzas | ahah, I see | |
| 12:48:32 | stephenfin | yeah, see my reply to lyarwood | |
| 12:48:35 | stephenfin | I'm adding new type functions in the next change and I want to annotate them and validate those annotations. To enable validation, I need to fix a couple of issues with the file. That's what I'm doing here. | |
| 12:48:35 | bauzas | you added type hints for the vtpm changes but this didn't work, gotcha | |
| 12:48:43 | stephenfin | exactly | |