| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-05 | |||
| 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" | |
| 19:48:47 | dansmith | edleafe: we throw the a-r at placement with the version from which it came at the scheduler level, and then it can fetch the resulting allocation at the version it understands | |
| 19:49:04 | dansmith | edleafe: it has a version in the headers, so... it's saying the version it thinks the thing is | |
| 19:49:23 | edleafe | an allocation_request is not affected by the scheduler | |
| 19:49:34 | edleafe | it is an opaque blob that placement just returned to scheduler | |
| 19:49:56 | dansmith | at the version that the scheduler understands | |
| 19:50:02 | dansmith | because the scheduler has said "I understand 1.10" | |
| 19:50:35 | edleafe | wait - so now we're handling old *schedulers*? | |
| 19:50:50 | melwitt | sdague, mriedem: the devstack "pip_install -U --force PasteDeploy" hack worked, FYI. so I'm onto the next problem now | |
| 19:50:57 | edleafe | I thought the only situation of version mismatch was a claim from an old cell conductor | |
| 19:51:25 | dansmith | edleafe: old scheduler? | |
| 19:51:51 | dansmith | placement is/will be a separate thing, upgraded at different times from the scheduler, conductors, etc | |
| 19:51:52 | dansmith | if cdent had his way, it would already be (/nudge) | |
| 19:51:52 | edleafe | dansmith: -> because the scheduler has said "I understand 1.10" | |
| 19:52:04 | dansmith | this is why we version shit | |
| 19:52:10 | sdague | melwitt: \o/ | |
| 19:52:34 | edleafe | allocation_requests are short-lived. They are not persisted | |
| 19:52:35 | melwitt | progress :) | |
| 19:52:44 | dansmith | edleafe: that has nothing to do with anything | |
| 19:52:48 | dansmith | edleafe: services are long-lived | |