Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-05
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
20:03:57 cdent dansmith: I agree with you, for the most part, I’m just reporting on “things we say"
20:04:05 penick mriedem indeed we are, I think he asked about it in channel last week. I've been meaning to reply to the thread
20:04:07 cdent “opaque"
20:04:07 dansmith cdent: yep, understand
20:04:17 mriedem penick: ah cool, on a call with him now
20:04:23 mriedem this is over my head
20:04:40 dansmith cdent: the only opaqueness I think we need is just between scheduler and the things downstream of it which need to throw it back at placement
20:04:56 cdent (under it all I find the allocation_candidates thing way overly-specific and not very api-like, but it is is what we’ve reached as a workable solution when many other things would not, so… hard to keep my guns)
20:05:03 dansmith having a big chunk of data that looks useful being exposed to the client and told that there be dragons within is not a good plan, IMHO
20:05:06 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for neutron client https://review.openstack.org/509892
20:05:44 edleafe dansmith: having a big chunk of data being passed around is not a good plan IMO either, but this is what we are working with
20:06:33 edleafe cdent: we do key on rp_uuid from the a-r, which was another design compromise
20:06:35 dansmith how does the jsonschema validation work if you have a change in the a-r? does it just ignore a subtree of something and validate it separately or something?
20:06:40 penick mriedem I'll reply to the ML today or tonight.. he notes that vendordata doesn't allow you to pass parameters, but I think that's something that can be addressed. Or he can write a vendordata driver
20:06:52 cdent edleafe: so it isn’t opaque
20:07:02 edleafe cdent: which is why for a given host there may be several a-rs, and we just take the first one for claiming
20:07:06 mriedem penick: nova passes some stuff to the vendordata service
20:07:35 cdent “passes some stuff” is the new api guideline
20:07:43 cdent what should my api do? “pass some stuff”
20:07:52 edleafe cdent: {$rp_uuid: <opaque>}
20:08:08 mriedem penick: https://github.com/openstack/nova/blob/master/nova/api/metadata/vendordata_dynamic.py#L77
20:09:06 cdent edleafe: that’s not what an a-r looks like now: https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation_candidate.py#L55-L68
20:09:10 jaypipes cdent: the whole "I told you guys that this all sucks but don't have a better idea about how to solve this problem" attitude gets really old.
20:09:15 cdent and we’re planning to change it with the new format
20:09:15 penick Is he right about plaintext http only? That seems an easy fix
20:09:25 cdent jaypipes: it gets especially old when you think that’s what we are doing and we aren’t actually
20:09:53 jaypipes cdent: sure seems like it.
20:09:56 penick er, mriedem: ahah, thanks. Is he right about plaintext only? that'd be an easy fix. I'll reply to him on the ML
20:10:26 cdent jaypipes: my apologies then, but I think you’ll find that this started because I pointed dan at some clarifying info about questions he reaised on a review
20:10:36 cdent since then we’ve been talking, that’s all
20:10:37 penick mriedem nm I see the ssl bit in the code
20:10:48 mriedem penick: yeah we ust send some shit over json in the request and we hope the vendordata service finds it useful
20:11:05 edleafe jaypipes: having to have this conversation about opaqueness gets pretty old, too
20:11:05 mriedem and yeah we do the normal ksa stuff
20:11:08 mriedem for the service user

Earlier   Later