| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-05 | |||
| 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 | |
| 19:54:24 | dansmith | if placement were not lockstep with scheduler, | |
| 19:54:32 | dansmith | then we'd break if we don't tell placement what we understand | |
| 19:54:36 | dansmith | this is the whole point of microversions | |
| 19:54:46 | edleafe | dansmith: for everything else between the scheduler and placement I agree | |
| 19:55:25 | edleafe | but an a-r is an opaque blob, and will *always* be in the format that placement wants | |
| 19:59:15 | sdague | mriedem: you want to land this backport - https://review.openstack.org/#/c/509774/ ? | |
| 20:00:57 | dansmith | edleafe: a-r cannot be an opaque blob to the scheduler because it has to interpret the results to weigh things | |
| 20:01:15 | dansmith | edleafe: that means that scheduler and placement have to agree on a format between them in order for the scheduler to reliably do its thing | |
| 20:01:42 | dansmith | if the scheduler is behind placement and received an older formatted thing, | |
| 20:01:43 | cdent | it uses the providers half of the tuple to weigh, not the a-r? | |
| 20:02:02 | edleafe | cdent: correct | |
| 20:02:03 | dansmith | but compute throws that at placement either at its version or "no version assume latest" it may be wrong | |
| 20:02:03 | cdent | nm, I guess it has to scan the a-r | |
| 20:02:29 | edleafe | why? | |
| 20:02:29 | dansmith | cdent: doesn't matter if it did.. surely we're not suggesting having a versioned document where one part of it is "may be newer, don't look behind this curtain" | |
| 20:02:59 | cdent | we do have a section that we’re claiming is “don’t look behind this curtain” | |
| 20:03:11 | dansmith | but that's crazy | |
| 20:03:15 | mriedem | penick: have you seen this thread? http://lists.openstack.org/pipermail/openstack-dev/2017-September/122904.html | |
| 20:03:17 | dansmith | that's not how people work with APIs | |
| 20:03:25 | mriedem | penick: rybridges: aren't you guys doing something similar? | |
| 20:03:41 | cdent | edleafe: I may be wrong. I was thinking that during the process of choosing which of the a-rs to use, you have to know the rp ids | |
| 20:03:43 | openstackgerrit | Eric Fried proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/509892 | |