Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-05
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 dansmith vendordata could be used for some of that,
19:35:54 mriedem vendordata was also to get rid of hooks
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 edleafe dansmith: -> because the scheduler has said "I understand 1.10"
19:51:52 dansmith if cdent had his way, it would already be (/nudge)
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
19:53:01 dansmith edleafe: I upgrade placement to rocky a month before I upgrade my nova
19:53:05 edleafe They are obtained from placement, and returned unchanged
19:53:15 dansmith edleafe: the scheduler has to tell placement what it understands
19:53:52 edleafe but a change to the format of an allocation_request does not affect the scheduler
19:53:57 edleafe it's an opaque blob
19:53:59 dansmith edleafe: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L270
19:54:06 dansmith that stops working when placement is kicked out
19:54:12 dansmith it's not even really right currently, but we have't done it

Earlier   Later