Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-14
17:17:37 melwitt I usually say, start with a specless blueprint (you need a blueprint either way) and then usually we discuss in the nova meeting and decide whether a spec is needed
17:17:41 dansmith I agree with melwitt, and I think it's a spec given the commit message is already nearly a spec
17:17:55 dansmith well, I agree with melwitt as of 30s ago :P
17:17:59 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/618478
17:18:20 kashyap dansmith: Okido. As you know, I'm not averse to (efficient and useful!) words
17:18:31 kashyap Sorry for being a lazy pig and not writing it until the last moment
17:18:37 dansmith in said meeting, I would just say "if you need a spec in the commit message it should probably be a spec" :)
17:18:38 kashyap I accept any penalty you may incur on me.
17:18:53 kashyap dansmith: No...that's too quippy
17:19:45 kashyap Okay, before the my brain cache gets flushed, might as well just do it. Here we go.
17:19:56 melwitt heh. well, true if it were specless it would have to be like, literally the commit message was enough to explain it and no one had further questions and no additional details were needed
17:20:09 melwitt which is unlikely
17:20:24 kashyap melwitt: Did you read the commit message? :-)
17:20:24 dansmith the code is really simple,
17:20:54 dansmith so it seems overkill for a spec, but the commit message is long, and there's apparently another tome of reference material from kashyap
17:20:56 dansmith so I dunno
17:20:57 kashyap Yeah, except the part about _which_ of the 4 flags go together, and _which_ I shold not mix
17:21:24 melwitt kashyap: yes :) it is a mini spec
17:21:29 kashyap dansmith: From enabling point of view, it's straight-forward
17:21:31 kashyap melwitt: LOL
17:21:59 kashyap Yeah, I spent a whole 2 hours to write. I'm a slow-as-molasses with writing down thoghts
17:22:06 dansmith so i could be maybe persuaded that it should just be a BP, if the commit message was trimmed down to non-kashyap standards and the patch included docs changes to explain what the commit message is
17:22:12 melwitt another advantage of the spec is it goes into our docs as nice reference place
17:22:40 dansmith yes, the commit message is documenting usage, which isn't right, IMHO
17:22:43 kashyap dansmith: The TODO will be gone from the commit. Isn' it quite trimmed?
17:22:59 kashyap Yeah, I agree with both of you
17:23:06 dansmith kashyap: no
17:23:20 kashyap This is so frelling fiddly because it took me the whole dammed WEEK to set it up!
17:23:24 dansmith kashyap: if you need rst formatting and section headers in your commit message, you're doing it wrong
17:23:38 melwitt haha
17:23:44 kashyap dansmith: I dare you:
17:23:48 dansmith melwitt: amirite? :)
17:23:55 kashyap No
17:24:16 melwitt dansmith: yup
17:24:17 kashyap dansmith: So long as the commit message is _useful_, readable, conveys meaningful information, the format doesn't matter
17:24:30 kashyap You've seen kernel commit messages, they go longer :D
17:24:37 kashyap News at 11: "This is not the kernel"
17:24:43 dansmith kashyap: they use them for a totally different purpose
17:25:20 kashyap dansmith: All the while I was writing that commit, I thought: "A cover letter would be nice" ... which is the "spec" :-)
17:26:52 kashyap dansmith: And yes: as you asked earlier: I of course want to write docs with the patch.
17:27:09 melwitt kashyap: yeah, I think you have great info there, just better in a design doc rather than commit message, IMHO
17:27:23 kashyap Yeah, agreed. I just wrote that to not lose the context in the head.
17:27:29 kashyap Will move it around.
17:27:34 melwitt and commit message refers to that design doc (blueprint) so we can get to it
17:27:46 melwitt yeah, I understand
17:28:27 kashyap At the risk of being banned from the channel, if I might say ... I'm a bit old-fashioned in the sense that: A commit should explain without requiring network access :-)
17:28:45 melwitt heh
17:29:10 kashyap Sorry, it's a habit I learnt from the "mailing list" folks.
17:29:17 melwitt these days it feels like there's nothing you can do without network access
17:29:45 kashyap That's why I try to not "break people's flow of reading" by saying: here you must click on this link, and then, get distrated by the Reddit tab next to it
17:29:59 kashyap And then forget that you were reading the commit message :D
17:32:19 melwitt I'll put this bp (after you create it) on the "first week of jan" list since it sounds like the code change is simple, just a matter of docs and capturing details
17:33:09 kashyap Thanks, one messy thing (even the libvirt storage folks said) is the item I noted in the 1023434th line on the commit:
17:33:17 kashyap "Figure out _which_ combination of migration flags are valid. E.g. VIR_MIGRATE_NON_SHARED_INC + VIR_MIGRATE_TLS: To migrate the NBD stream over TLS. And what about VIR_MIGRATE_NON_SHARED_DISK?"
17:33:49 kashyap I need to carefully re-review what flags Nova uses, and what combinations we allow.
17:34:04 kashyap It's actually not "messy"; just a logic thing I need to work out.
17:35:22 melwitt ok
17:38:33 kashyap melwitt: When you get a minute: one comment on benchmarks
17:39:15 kashyap Benchmarks of non-native TLS vs. "native TLS", i.e. DanPB did some of it when he was doing the QEMU work
17:39:34 kashyap But I don't have the URL ready; I'll check w/ him and add that details in the "Q&A" with the reviewers
17:39:42 kashyap Hope it's not a "hard requirement"
17:45:41 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
17:45:42 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
17:45:42 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
17:45:56 melwitt kashyap: I don't think so, since it's opt-in via conf option
17:50:58 openstackgerrit Jan Gutter proposed openstack/nova-specs master: Spec to implement os-vif generic datapath offloads https://review.openstack.org/607610
17:52:56 kashyap melwitt: Okido, noted.
17:53:36 melwitt would be certainly nice to include in the docs and/or spec when you find it
17:55:14 jangutter dansmith: so... I'm looking for a place to jot down the stuff I learned about ovo and versioning before I forget it and have to rediscover it.
17:55:52 jangutter dansmith: mostly the things about the great "composition vs inheritance" debate of 2018.
17:56:16 dansmith jangutter: yeah, I'm not sure what to tell you, but it seems like somewhere in ovo is the right place
17:57:07 jangutter dansmith: even if it ends up being an abandoned doc review, want to do something in January or so...
17:57:40 dansmith jangutter: january sounds god :)
17:57:41 dansmith *good
17:58:41 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add workaround to cleanup instance dir when using rbd https://review.openstack.org/618478
17:59:30 jangutter dansmith: I was half-afraid that "just do it as a blog post" would be the go-to thing, but I'll try to make it generic enough that it's not a pain to update.
18:00:14 dansmith jangutter: yeah docs somewhere would be better I think, even if it has to start in nova, but just a text file in ovo would be better than nothing
18:00:43 kashyap melwitt: When you have a moment, as promised: https://blueprints.launchpad.net/nova/+spec/support-qemu-native-tls-for-live-migration
18:00:59 melwitt thanks
18:01:27 melwitt aw, I was expecting a paste of your commit message in there
18:01:28 kashyap melwitt: Does it make sense? My eyes are weary from reading my own sentences
18:01:47 kashyap melwitt: I thought it's not "allowed"?
18:01:54 melwitt why not?
18:02:03 kashyap Can post the rest of it there as well. As the Blueprint says "this is shown in feature texts"
18:02:10 kashyap Implying: "be mindful what you post"
18:02:22 kashyap Okay, let me go post the rest
18:02:31 melwitt oh, I didn't know that. it's not shown in any of our docs
18:03:01 kashyap Ah, okay, then.
18:03:18 melwitt we use launchpad just for the milestone tracking and such, for organizing things
18:11:23 kashyap Yep, noted.
18:11:49 kashyap melwitt: When you can, please refresh and see if it's better
18:12:35 kashyap No ... he is a good mood today; I even got the Christmas present of a hug from him
18:12:53 kashyap Err, that "/me" sentence got borked. Let me rewrite
18:16:14 melwitt kashyap: looks fine to me. I didn't think anyone would have a problem with it, so if someone does, sorry for leading you astray. tell them it's my fault :)
18:16:29 kashyap Hehe
18:16:56 kashyap melwitt: No problem. If people ask me questions & convince me to write a spec, and I can't defend myself, I will of course write one without making excuses :-)
18:17:10 kashyap Okay, I'll make dinner, then
18:18:50 melwitt kashyap: yeah, I think the thought is, either way we want the details documented somewhere. so you can either add docs changes to your patch that explains all the version needed, flags to use, benchmark link, reference material link, etc. or, you can put that stuff in a spec. for now, I thought since you wrote that commit message, why not paste it in the blueprint for a starting point
18:19:29 melwitt you'll need a release note too, in your patch
18:20:59 kashyap Yeah, absolutely

Earlier   Later