| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-26 | |||
| 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 | |
| 12:49:10 | stephenfin | it felt wrong to add type hints but not validate them, and I couldn't enable validation without some additional work | |
| 12:49:20 | stephenfin | so I did that work separately since it's not totally related | |
| 12:49:22 | stephenfin | if that makes sense | |
| 12:49:33 | bauzas | stephenfin: yeah | |
| 12:50:20 | bauzas | that's not I wanna argue against type hints | |
| 12:50:34 | bauzas | if you wanna use them, this works for me | |
| 12:50:45 | bauzas | but let's not make it mandatory for all of us | |
| 12:51:06 | stephenfin | yeah, to be clear, I'm not asking it of anyone who doesn't want to add them | |
| 12:51:10 | sean-k-mooney | once a file has first been enabeld for type hints you can add them inline | |
| 12:51:15 | sean-k-mooney | instead of as a seperate patch | |
| 12:51:15 | stephenfin | but I'd like to add them to my code. I find them helpful | |
| 12:51:34 | sean-k-mooney | but when your ading a new file you often have to update unrelated code to get it to pass | |
| 12:51:49 | sean-k-mooney | well semingly unrelated | |
| 12:52:49 | bauzas | there are two ways of seeing type hints | |
| 12:53:03 | stephenfin | sean-k-mooney: yeah, that's what I'm doing for new code at least | |
| 12:53:03 | stephenfin | for expected backports, melwitt and others have asked I do them separately to keep changes to the backport to a minimum, which I can deal with :) | |
| 12:53:10 | bauzas | either as a terrible waste of time for reviewers, or as an opportunity for code readability and static checks | |
| 12:53:29 | sean-k-mooney | bauzas: yep i am stongly in teh latter camp | |
| 12:53:31 | stephenfin | s/type hints/tests/ | |
| 12:53:33 | bauzas | I'm not opiniated on any of both, I just try to be pragmatic | |
| 12:54:04 | sean-k-mooney | lack of type hints is why i hated python for the first 2-3 years of working on openstack | |
| 12:54:07 | stephenfin | same argument can be made, though the value of tests is definitely more significant | |
| 12:54:22 | bauzas | my biggest concern being this a py3 feature, but given we now have a good consensus on things we can vs we can't do, I'm okay | |
| 12:54:23 | sean-k-mooney | wehn we started adding the parms comment it helped a bit but not as much as type hints | |
| 12:54:23 | stephenfin | but it's also dead code from the perspective of production | |
| 12:54:56 | bauzas | adding only type hints on new code seems reasonable... but... | |
| 12:55:06 | stephenfin | the current situation works for me (add them as you're going, and only if you want to) | |
| 12:55:16 | stephenfin | bauzas: to be clear, new code or modified code | |
| 12:55:20 | bauzas | there is a trade-off, the more we're using them, the higher chances we can have merge conflicts with backporting | |