| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-03 | |||
| 13:52:47 | edleafe | jaypipes: so without a consumer gen in the PUT, how would the second actor ever modify allocations? | |
| 13:53:16 | jaypipes | edleafe: the second actor does GET /allocations/{consumer_uuid}, then POST /allocations | |
| 13:53:24 | edleafe | <shudder> | |
| 13:53:24 | jaypipes | edleafe: as I wrote in the spec response. | |
| 13:53:58 | edleafe | jaypipes: that would be a PATCH, which I proposed but was argued against | |
| 13:54:04 | cdent | jaypipes: why POST instead of PUT? It is in fact (restully speaking) a PUT | |
| 13:54:18 | edleafe | the POST, as cdent mentioned, is for multiple consumers | |
| 13:54:36 | edleafe | The POST actually does a series of PUTs, one for each consumer | |
| 13:55:06 | jaypipes | cdent: because that ship has already sailed? I argued for PATCH instead of POST /allocations to handle multiple consumers, but we went with POST /allocations to handle the "change multiple allocations at once" scenario for migrations/resizes | |
| 13:55:58 | edleafe | jaypipes: sure, but we aren't changing *multiple* | |
| 13:56:08 | cdent | jaypipes: what edleafe just said | |
| 13:56:18 | jaypipes | edleafe: nothing about POST /allocations implies or denotes changing multiple things. | |
| 13:56:29 | cdent | there's only one consumer uuid. and yes it does | |
| 13:56:35 | cdent | post allocations is for multiple consumers | |
| 13:56:49 | jaypipes | cdent: where? | |
| 13:57:02 | efried | POST is allowed to be used for just one, sure. | |
| 13:57:03 | cdent | that's why we created it and how I wrote it | |
| 13:57:09 | edleafe | jaypipes: the handler for POST loops on consumer_uuid. It's pretty clear that it is designed to handle multiple consumers | |
| 13:57:11 | cdent | it _can_ do one, but that's not it's point | |
| 13:57:37 | jaypipes | so tell me folks, what about my proposal *won't work*? | |
| 13:57:55 | edleafe | jaypipes: it also doesn't *add* them to any existing allocations for a consumer; it overwrites them | |
| 13:58:02 | cdent | there's no reason not to have generation on PUT because what we want to do, on PUT, is to write allocations for the consumer uuid in the URI. That's what it is for. | |
| 13:58:06 | cdent | What's wrong with that | |
| 13:58:08 | jaypipes | edleafe: which is what we want here. | |
| 13:58:19 | cdent | that's what PUT means jaypipes | |
| 13:58:25 | cdent | overwrite allocations for consumer X | |
| 13:58:35 | cdent | the generation is acting a the etag | |
| 13:58:44 | jaypipes | cdent: are you talking about HTTP/REST semantics? | |
| 13:58:57 | cdent | I'm talking about what we already have in put, minus the generation | |
| 13:59:22 | cdent | adding a generation to PUT makes more sense than overloading POST when we already have an existing semantic that is correct | |
| 13:59:30 | edleafe | jaypipes: using the POST code, there is still no way to add allocations to a consumer | |
| 13:59:54 | jaypipes | edleafe: ? sure there is... you just list a set of allocations for a consumer. | |
| 13:59:55 | cdent | I wonder if maybe I'm not understanding jay's suggestion properly | |
| 14:00:16 | efried | FWIW, I agree that we should add generation to PUT, even if not doing so would allow us to sidestep the question of what generation should be specified for creation, which it doesn't. | |
| 14:00:21 | cdent | how is post to /allocations different from put to /allocations/consumer_uuid (with a generation)? | |
| 14:00:52 | efried | jaypipes: POST still needs to be *able* to be used to *create*. Because migration scenario. So we still have to address the question of "what generation do we send down for a consumer that doesn't yet exist?" | |
| 14:00:56 | edleafe | jaypipes: changing the POST code to make it additive would break migrations | |
| 14:01:11 | cdent | efried: yeah, as I said on the spec the none thing is meh-ish, but seems kinda gotta with the model being considered | |
| 14:01:29 | efried | IMO there's no meh about it. It's ick-but-necessary. | |
| 14:01:41 | cdent | isn't that what meh means? | |
| 14:01:50 | cdent | resignation in the face of crushing reality | |
| 14:01:56 | efried | To me "meh" means "could do with or without it" | |
| 14:01:57 | jaypipes | edleafe: sorry, I'm not suggesting modifying POST /allocations to be additive. I am suggesting to keep it as "overwrite the allcations for all consumers listed in the resquest payload" | |
| 14:02:40 | efried | jaypipes: Cool, so how do you handle the generation for a newly-created consumer in POST? | |
| 14:02:57 | edleafe | jaypipes: so in the example case of two actors creating their subset of allocations to placement, how will the second one ever be able to get theirs in? | |
| 14:03:18 | jaypipes | efried: overwrite. | |
| 14:03:31 | efried | jaypipes: There's nothing to overwrite. The consumer doesn't exist. | |
| 14:03:40 | jaypipes | efried: so it is created? | |
| 14:03:50 | jaypipes | efried: I'm not proposing anything different for that. | |
| 14:03:54 | efried | yes, it is created by the POST (in e.g. the migration scenario). | |
| 14:04:24 | efried | jaypipes: Right, I'm asking, now that we have to specify the generation per consumer chunk in the POST payload: what generatio do we send down for the new consumer? | |
| 14:04:39 | jaypipes | edleafe: the second one gets a 409 Conflict when trying to do the PUT /allocations/{consumer}. It then does a GET /allocations/{consumer} and merges its needed resources into a call to POST /allocations | |
| 14:04:41 | edleafe | for allocations, POST == a set of PUTs | |
| 14:04:51 | jaypipes | efried: we don't. | |
| 14:04:59 | edleafe | jaypipes: so you | |
| 14:05:01 | edleafe | ugh | |
| 14:05:21 | edleafe | jaypipes: so you're saying that POST needs a consumer gen, just to avoid adding one to PUT?? | |
| 14:05:49 | efried | edleafe: He also just said leave the consumer generation off of the respective subsection of POST if it's a new consumer. | |
| 14:06:00 | jaypipes | right. | |
| 14:06:09 | jaypipes | edleafe: what I'm proposing is the least amount of change to the API. | |
| 14:06:11 | edleafe | efried: if it's a new consumer, there could not be a 409 response | |
| 14:06:40 | edleafe | If you've gotten a 409, the consumer exists. You can still be in danger of overwriting | |
| 14:06:45 | jaypipes | edleafe: no consumer_generation in POST /allocations means "I think this is a new consumer" | |
| 14:06:54 | edleafe | jaypipes: that makes no sense | |
| 14:07:08 | efried | Shrug, it's a coin-toss between that and sending null. | |
| 14:07:19 | jaypipes | edleafe: sure it does. think about the existing use case of POST /allocations (the resize/migrate case) | |
| 14:07:21 | edleafe | You just said that POST would be used *after* a conflict was detected. Ergo, there *is* a consumer | |
| 14:07:26 | efried | ...it's just not what we landed on yesterday. | |
| 14:07:48 | efried | With jaypipes' suggestion, PUT is only for create, but POST is for create *or* modify. | |
| 14:07:56 | purplerbot | <jaypipes> edleafe: the second one gets a 409 Conflict when trying to do the PUT /allocations/{consumer}. It then does a GET /allocations/{consumer} and merges its needed resources into a call to POST /allocations [2018-04-03 14:04:39.482469] [n 4bj1] | |
| 14:07:56 | edleafe | [t 4bj1] | |
| 14:08:18 | efried | With things as we left them yesterday, either one can be used for either create or modify. | |
| 14:08:31 | jaypipes | edleafe: when POST /allocations is used to reconcile after a 409 Conflict is received from the PUT /allocations/{consumer_uuid}, yes, the consumer_generation would be expected in the request. But POST /allocations is used for migrate/resize, and in the case of that, the migration UUID would be expected as a new consumer. | |
| 14:08:44 | edleafe | efried: how would modify be guaranteed not to race w/o the consumer gen? | |
| 14:08:55 | cdent | I need to do something else for awhile, can someone be sure this gets summarized to the spec, I've got more to say, but it sounds like this needs to play out a bit | |
| 14:09:16 | jaypipes | edleafe, efried: a hangout perchance? | |
| 14:09:35 | efried | edleafe: consumer_generation omitted would behave exactly the same as consumer_generation=null. Either one works to signify "I think the consumer doesn't exist yet". | |
| 14:09:36 | edleafe | jaypipes: well, that just feels really wrong. POST shouldn't behave one way sometimes, and another way others | |
| 14:09:41 | efried | hangout fine by me. | |
| 14:10:13 | edleafe | efried: so then placement would reject it, for the exact same reason it rejected the consumer gen-less PUT | |
| 14:10:24 | jaypipes | https://hangouts.google.com/call/7cb33WR2UowcbcI_8EdLAAEE | |
| 14:10:24 | efried | edleafe: Yes. | |
| 14:10:42 | edleafe | efried: why limit it to 2 actors? What about 3? Nova, cinder and neutron all allocating resources | |
| 14:11:13 | efried | it's not limited edleafe. Are you joining? | |
| 14:11:53 | sean-k-mooney[m] | jaypipes: why would you do post to /allocations on migrate instead of PUT | |
| 14:12:29 | sean-k-mooney[m] | jaypipes: sorry for resize we use post be cause we are using a migration uuid instead of the instance uuid never mind | |
| 14:15:06 | sean-k-mooney | jaypipes: efried edleafe so i was wondering why i did not get any responces to my messages for the last 5 mins. aprently my riot.im client never sent them to irc... | |
| 14:15:46 | sean-k-mooney | if ye get a bunch of out of context messages form sean-k-mooney[m] in then next few minuts thats why | |
| 14:39:54 | edleafe | sean-k-mooney: to answer your question, the POST to allocations was added for the migration case, where we needed a set of allocations for multiple consumers to be changed atomically | |
| 14:48:58 | openstackgerrit | Simon Dodsley proposed openstack/nova master: Add enhanced KVM storage QoS quotas https://review.openstack.org/558530 | |
| 15:04:37 | bauzas | artom: *cough cough* +Wd https://review.openstack.org/#/c/552722/12 ;à | |
| 15:04:38 | bauzas | ;) | |
| 15:13:46 | jaypipes | cdent, edleafe, efried: k, summary sent to ML. | |
| 15:13:59 | efried | jaypipes: Thanks for doing that. | |
| 15:14:01 | cdent | thanks jaypipes | |
| 15:14:03 | jaypipes | np | |
| 15:16:19 | openstackgerrit | Merged openstack/nova master: Scheduling Optimization: Remove cell0 from the list of candidates https://review.openstack.org/556821 | |
| 15:18:42 | openstackgerrit | Merged openstack/nova-specs master: NUMA-aware live migration https://review.openstack.org/552722 | |
| 15:28:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660 | |
| 15:28:56 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472 | |