| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-14 | |||
| 17:06:01 | mriedem | or "rooted beer" as an EU might call it | |
| 17:06:09 | kashyap | Ah, yes. | |
| 17:06:49 | kashyap | mriedem: So the nice thing is that: now Nova guests can have encryption (*without* the penalty of "libvirtd tunnelling") for all migration streams | |
| 17:07:06 | kashyap | Namely: Instance guest RAM, device state + disks over NDB | |
| 17:07:36 | kashyap | And goes to upload his "evidence files" | |
| 17:08:29 | kashyap | Oh ... the fly in the ointment is I'll be on PTO next week (if I don't take them, they'll disappear). So only be back in 1st week of Jan to come back to write tests | |
| 17:09:03 | kashyap | So ... saying: "No, you wretch, I will not even click on the URL without tests" is perfectly reasonable | |
| 17:09:58 | mriedem | i seem to remember something about nbd + the tunneling thing years ago from danpb | |
| 17:10:01 | mriedem | but it's very hazy now | |
| 17:10:07 | mriedem | or maybe it was markmc | |
| 17:10:08 | mriedem | idk | |
| 17:10:43 | kashyap | mriedem_lunch: When you get back from lunch, as of today: | |
| 17:11:03 | kashyap | - Nova has 'live_migration_tunnelled' -- but if you use that, you can't do "block migration" | |
| 17:11:23 | kashyap | That is one of the major cases we fix. Thus, having encryption for all streams | |
| 17:12:09 | kashyap | (By "streams", migration stream + NBD stream) | |
| 17:13:22 | kashyap | And going forward, we will deprecate the 'live_migration_tunnelled', because it has _awful_ performance impact and latency | |
| 17:13:53 | kashyap | As there'll be no compelling reason to use it. | |
| 17:14:13 | kashyap | melwitt: Hi, forgot to address your comment | |
| 17:14:52 | kashyap | melwitt: I _thought_ I posted a spec, but only settled with "bug", as it's technically a "bug": https://bugs.launchpad.net/nova/+bug/1798796 | |
| 17:14:52 | openstack | Launchpad bug 1798796 in OpenStack Compute (nova) "libvirt: Use VIR_MIGRATE_TLS to get QEMU's native TLS support for migration and NBD" [Medium,In progress] - Assigned to Kashyap Chamarthy (kashyapc) | |
| 17:15:35 | kashyap | But, I know what you mean. | |
| 17:15:54 | melwitt | calling that a bug is a stretch IMO, if you need a commit message that long and at least a certain version of QEMU etc | |
| 17:16:21 | melwitt | but maybe that's just me | |
| 17:16:31 | kashyap | No, you're fully right. Given the length of the commit message | |
| 17:16:38 | kashyap | I might as well just put it in a spec | |
| 17:17:04 | kashyap | What do you suggest: a spec-less Blueprint, or a spec? | |
| 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 | |