| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-14 | |||
| 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: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543 | |
| 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: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 | |
| 18:21:09 | kashyap | Was just writing that in the TODO :-) | |
| 18:38:42 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Support native TLS for migration and disks over NBD https://review.openstack.org/625216 | |
| 19:07:21 | openstackgerrit | Merged openstack/nova stable/queens: Add secret=true to fixed_key configuration parameter https://review.openstack.org/623509 | |
| 19:31:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fail to live migration if instance has a NUMA topology https://review.openstack.org/611088 | |
| 19:50:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: remove live_migration_progress_timeout config https://review.openstack.org/619142 | |
| 19:50:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: add live migration timeout action https://review.openstack.org/619143 | |
| 20:15:46 | melwitt | started the "first week of jan" etherpad here https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze | |
| 20:16:03 | melwitt | will send it to the ML when I have more filled out | |
| 20:16:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix up force live migration completion docs https://review.openstack.org/625339 | |
| 20:27:11 | mriedem | dansmith: so i want to test triggering a post-copy in the gate, but the problem is these tiny cirros instances live migrate in less than a second, and our completion timeout is in seconds (integers) so i need it to take at least a second. wondering if you're aware of any libvirt guest APIs where I can inject something into the guest to basically stall the live migration and force the timeout and switch to post-copy | |
| 20:27:19 | mriedem | i know sahid had that bandwidth thing... | |
| 20:30:33 | mriedem | hey we even have a config option for this... live_migration_bandwidth | |
| 20:33:33 | dansmith | mriedem: the only thing you can do to stall it from the inside is to dirty memory like a banshee | |
| 20:33:51 | dansmith | iirc, danpb had a little C program that would behave badly | |
| 20:34:03 | dansmith | but it'd be pretty dependent on how fast the machine was that you're testing on | |
| 20:34:44 | dansmith | but no, not aware of anything libvirty to help with that | |
| 20:35:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: test for force complete live migrate with post-copy https://review.openstack.org/625343 | |
| 20:35:38 | openstackgerrit | Merged openstack/nova master: Remove lock on SchedulerReportClient._create_client https://review.openstack.org/624770 | |
| 20:35:46 | openstackgerrit | Merged openstack/nova stable/pike: Add secret=true to fixed_key configuration parameter https://review.openstack.org/623510 | |
| 20:36:04 | mriedem | yeah ok maybe that won't work then | |
| 20:36:06 | mriedem | but i tried! | |
| 20:44:15 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Spec to implement os-vif generic datapath offloads https://review.openstack.org/607610 | |
| 21:02:50 | pbandark | hi.. i am facing issue while creating instance on openstack. the instance is getting created. but, when I check the console logs of the vm, i can see kernel panic. https://pastebin.com/dZ2uTuFa any suggestion would be really helpful. | |
| 21:07:13 | openstackgerrit | Merged openstack/nova-specs master: Spec to implement os-vif generic datapath offloads https://review.openstack.org/607610 | |
| 21:46:07 | openstackgerrit | Ben Nemec proposed openstack/nova master: Migrate upgrade checks to oslo.upgradecheck https://review.openstack.org/603499 | |
| 21:51:34 | mriedem | beekneemech: heh forgot about the functional test | |
| 21:52:13 | mriedem | dansmith: replied to your replies and new questions in the cross-cell resize spec https://review.openstack.org/#/c/616037/ - good things in there again, thanks. good news is since i wrote that, i think quite a bit of this is at least more clear, so some of the open questions are closing, which is nice. | |
| 21:52:15 | beekneemech | mriedem: Yeah, looks like it just got moved so it wouldn't have shown up in the conflict list. | |
| 21:52:29 | mriedem | dansmith: so you can exit for the year knowing it's sort of coming together | |
| 21:53:13 | mriedem | probably hairiest issue is how much existing code do we want to hack vs just writing something entirely new from scratch | |
| 21:53:44 | mriedem | i'm not sure i'll have the energy to poc an alternative next week, but maybe | |