| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-05 | |||
| 18:16:29 | mriedem | if you don't pipe down | |
| 18:16:40 | dansmith | heh | |
| 18:17:48 | melwitt | mriedem: sure, will do | |
| 18:40:39 | cdent | mriedem: is this back in business? https://review.openstack.org/#/c/267587/ | |
| 18:46:42 | mriedem | cdent: the spec isn't approved yet | |
| 18:46:53 | mriedem | cdent: the multiattach stuff is all dependent on the new style volume attachment stuff | |
| 18:47:40 | cdent | ah. I got so excited by seeing it laying around. | |
| 18:48:03 | cdent | the feature that failed to live but won’t die | |
| 18:49:05 | dansmith | too fast to live, too young to die | |
| 18:49:09 | dansmith | james dean. | |
| 19:02:59 | dansmith | mriedem: I was just looking at my live migration patch wondering why it wasn't failing a test because it doesn't clean up by migration uuid on rollback | |
| 19:03:09 | dansmith | and then ran tests again to check, which it failed | |
| 19:03:15 | dansmith | confused because I thought this was passing | |
| 19:03:24 | dansmith | found the test that tests this, which I fail | |
| 19:03:33 | dansmith | dug through the path to figure out where we're cleaning up now | |
| 19:03:51 | dansmith | didn't find it, almost filed a bug | |
| 19:03:52 | dansmith | re-read test, found bug reference, found patch that addeded | |
| 19:03:58 | dansmith | remembered I reviewed and approved that | |
| 19:04:05 | dansmith | and that you have a fix on top of it waiting for +W | |
| 19:04:29 | dansmith | so, altogether a pretty productive hour.. total work product output: one +W vote | |
| 19:12:59 | openstackgerrit | OpenStack Proposal Bot proposed openstack/os-vif stable/newton: Updated from global requirements https://review.openstack.org/373293 | |
| 19:13:12 | openstackgerrit | Merged openstack/nova master: fix unstable shelve offload functional tests https://review.openstack.org/509759 | |
| 19:15:16 | dansmith | jaypipes: this is needed for the migration uuid stuff, if you wanna slap yer +W on it: https://review.openstack.org/#/c/508699/ | |
| 19:15:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Revert allocations by migration uuid https://review.openstack.org/498949 | |
| 19:15:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Pre-create migration object https://review.openstack.org/498950 | |
| 19:15:25 | openstackgerrit | Dan Smith proposed openstack/nova master: Make migration uuid hold allocations for migrating instances https://review.openstack.org/506420 | |
| 19:15:25 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor resource tracker to account for migration allocations https://review.openstack.org/506419 | |
| 19:15:26 | openstackgerrit | Dan Smith proposed openstack/nova master: Make live migration hold resources with a migration allocation https://review.openstack.org/507638 | |
| 19:15:34 | jaypipes | dansmith: on it. | |
| 19:16:02 | jaypipes | dansmith: the whole series I presume? | |
| 19:16:19 | dansmith | jaypipes: just that linked one is what I want right now | |
| 19:16:33 | dansmith | jaypipes: I was just pushing the series in parallel to begging for your +W | |
| 19:16:53 | dansmith | jaypipes: i.e. https://review.openstack.org/#/c/508699/ | |
| 19:18:41 | mriedem | dansmith: heh, well, i did beg for reviews a few times on that one | |
| 19:18:54 | dansmith | mriedem: I know, I had a lot of stuff in my head at the time | |
| 19:18:57 | mriedem | oh wait not that one | |
| 19:19:27 | mriedem | was thinking this one https://review.openstack.org/#/c/507687/ | |
| 19:19:31 | mriedem | is that what you meant? | |
| 19:19:52 | mriedem | yeah it is, nvm | |
| 19:20:24 | mriedem | just about done with this epic internal email on scheduler configuration | |
| 19:20:26 | dansmith | mriedem: I meant the one I linked | |
| 19:20:33 | dansmith | oh | |
| 19:20:42 | dansmith | you mean my earlier story, yes, I was talkin gabout 687 | |
| 19:22:55 | mriedem | 36 minutes until a call about instance users | |
| 19:22:56 | mriedem | yay! | |
| 19:23:17 | mriedem | i need a trombone as mine is in the shop | |
| 19:23:21 | dansmith | mriedem: btw, since I re-pushed that whole migration set, I squashed that extra test patch into the bottom | |
| 19:23:47 | melwitt | I can't remember what "instance users" was about. maybe I should be grateful | |
| 19:24:51 | sdague | anyone seen any of the john hopkins folks recently on irc? I was going through their image signing spec and code and just had a few quick questions | |
| 19:25:28 | mriedem | sdague: nope | |
| 19:26:09 | sdague | neither dane nor kaitlin are here unless I suck at tab completing. But I'm not sure if others have irc nicks. | |
| 19:28:22 | mriedem | that's who i was looking for | |
| 19:29:17 | mriedem | cdent: btw this is the goal https://review.openstack.org/#/c/330285/ | |
| 19:29:22 | mriedem | for the new style volume attach stuff, | |
| 19:29:35 | mriedem | jgriffith is working on a new microversion on the cinder side, patch is up for that now but needs some work, | |
| 19:29:48 | mriedem | but then the nova change will require that new cinder microversion and we can work on getting the nova patch in, | |
| 19:29:51 | mriedem | and then it's multiattach time | |
| 19:30:15 | openstackgerrit | melanie witt proposed openstack/nova master: Make setenv consistent for unit, func, and api-samples https://review.openstack.org/507976 | |
| 19:30:58 | mriedem | cdent: have your corporate overlords expressed an interest in multiattach? | |
| 19:31:47 | cdent | not that I’m aware of, but my corporate overlords interests via me are pretty focused | |
| 19:31:56 | cdent | I would assume they probably are interested | |
| 19:32:29 | cdent | my interest is mostly sparked by observing it for enough ptgs, summits, midcycles to think of it is a somewhat annoying friend | |
| 19:33:47 | openstackgerrit | melanie witt proposed openstack/nova master: Make setenv consistent for unit, func, and api-samples https://review.openstack.org/507976 | |
| 19:34:47 | mriedem | melwitt: i believe, to summarize, an instance user was the ability for a guest to get a token to do things | |
| 19:34:57 | melwitt | ohhh | |
| 19:35:06 | melwitt | that was the new vendordata thing right? | |
| 19:35:07 | mriedem | but i was never really involved (by my own choosing) in that discussion, so i'm blissfully ignorant | |
| 19:35:22 | jaypipes | dansmith: k, done | |
| 19:35:29 | melwitt | or that discussion resulted in the new vendordata I thought | |
| 19:35:39 | mriedem | melwitt: kind of yeah | |
| 19:35:51 | dansmith | well, only for certain types of things | |
| 19:35:54 | mriedem | vendordata was also to get rid of hooks | |
| 19:35:54 | dansmith | vendordata could be used for some of that, | |
| 19:36:05 | mriedem | which, now that i think about it, we haven't removed yet | |
| 19:36:07 | dansmith | but I think the real use case requires more integration than that | |
| 19:36:13 | dansmith | the real instance_users case I mean | |
| 19:36:17 | melwitt | okay | |
| 19:36:53 | cdent | dansmith: your thing about microversions on Selection objects, there’s some discussion about it on https://review.openstack.org/#/c/498830/ (patchset 7) where I expressed a lot of confusion that ed and jay tried to clear it up. Eventually I capitulated | |
| 19:37:49 | dansmith | cdent: okay I'm fairly concerned about this, but I shall go read | |
| 19:38:24 | cdent | It may not illuminate, but it may | |
| 19:38:55 | mriedem | uh oh, lar bear is home | |
| 19:40:21 | dansmith | cdent: uh, I certainly did not agree to that which was agreed to in denver | |
| 19:40:33 | dansmith | cdent: that makes the microversion thing way too fluid, IMHO | |
| 19:40:51 | dansmith | cdent: you remove a field in 1.5, add it again in 1.50 with a different meaning or format, and boom | |
| 19:41:52 | jaypipes | dansmith: welcome to hear other ideas here, but please do read the one long comment I gave to cdent on PS7 on that patch | |
| 19:42:52 | dansmith | jaypipes: yeah I completely understand the situation | |
| 19:42:59 | cdent | “microversion thing way too fluid” was my concern too, but, like I said, I decided to capitulate | |
| 19:43:21 | dansmith | jaypipes: but making placement just be "meh" about the mismatch between versions and formats is totally not the right plan, IMHO | |
| 19:43:32 | cdent | my capitulation is a somewhat more complex version of the plan that ed original presented | |
| 19:43:35 | dansmith | jaypipes: all we have to do is pass the microversion that matches the blob, and have the report client use that version | |
| 19:44:33 | dansmith | (in terms of "other ideas") | |
| 19:46:46 | edleafe | dansmith: when will an allocation not match the version placement understands? | |
| 19:47:01 | dansmith | edleafe: it's not about that | |
| 19:47:09 | cdent | do people have preferences on what stays or goes? | |
| 19:47:17 | dansmith | edleafe: it's about the version sent by the client not matching the payload | |
| 19:47:43 | dansmith | edleafe: and the server side having to just "be flexible" about what it thinks the client wants | |
| 19:48:02 | edleafe | dansmith: yes, I understand. But even an old client will have gotten (and be returning) a current-version allocation | |
| 19:48:06 | dansmith | the client has said "this is a 1.5 thing" and the server says "well, kinda looks like a 1.10 thing, so...I'll just assume 1.10" | |
| 19:48:23 | dansmith | edleafe: the allocation, sure, like Isaid initially: | |
| 19:48:32 | edleafe | the client isn't saying that. It's saying: "here is the thing you just sent me" | |