Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-05
22:42:23 efried jaypipes I'm probably being obtuse again, but I still don't really see how what we're talking about here doesn't still fall into that description. Placement is designed to grab resources from multiple resource providers. From a way-zoomed-out view, saying "you can only get stuff from a given resource class from a single provider" seems like an arbitrary limitation. Zoom back in, and it's one that seems imposed because we
22:42:23 efried 're having trouble expressing it under the current design, not because it inherently crosses the line to "orchestration".
22:42:47 cdent jaypipes: on line 50 it is GROUP_A on the first go round and GROUP_B on the second?
22:43:37 efried cdent Yeah; and/or L49 could be different egress bandwidth numbers
22:43:44 cdent thanks
22:44:01 jaypipes cdent: a couple reasons for that. the first is that it's difficult for me to map the concept of related sub-requests in a single REST API call (again, without resorting to some DSL-ish request payload) and b) because I suspect these types of use cases are just the tip of the iceberg and that the logic that relates various things with each other (GPUs, FPGAs, NIC HA groups, etc) will be different and not possible to cleanly express with simple
22:44:01 jaypipes query parameters.
22:44:51 jaypipes cdent: and yes, it would be GROUP_A on the first go around and GROUP_B on the second.
22:45:08 cdent jaypipes: next question: step 4 sounds like a pretty big step backwards for the goals we originally expressed for allocation_candidates
22:45:21 jaypipes cdent: could also have different amounts of egress bandwidth, different affinity policies, different all sorts of things, frnakly
22:45:32 jaypipes cdent: Yupppp!
22:45:37 cdent why can’t we have a complete allocation_requests (just to be explicit)
22:45:48 jaypipes cdent: it removes the whole opaqueness aspect of the allocation request :()
22:45:57 cdent yes much :(
22:46:07 efried Is it because the allocation request is keyed by resource class?
22:46:15 efried (haven't looked at that guy yet)
22:46:41 jaypipes cdent: we can't have a complete allocation_requests unless placement is passed all of the logic about relationship between sub-resources
22:47:03 cdent I thought that’s what nested was providing us?
22:47:04 jaypipes efried: the allocation request is not keyed by resource class, no.
22:47:23 jaypipes efried: the allocation request is essentially the request payload to PUT /allocations/{consumer_uuid}
22:47:29 openstackgerrit Michael Still proposed openstack/nova master: Add release note for requiring shred 8.22 or above. https://review.openstack.org/501022
22:48:19 cdent jaypipes: related, have you yet seen: http://lists.openstack.org/pipermail/openstack-dev/2017-September/121824.html from avolkov ?
22:48:21 efried jaypipes And it must be able to contain resources from different RPs. So why would there be a limitation that RCs therein be unique?
22:48:32 efried cdent That's what started this whole thing :)
22:48:38 cdent ah, good
22:48:50 efried cdent Back around http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-05.log.html#t2017-09-05T15:37:39
22:49:01 cdent presumably the response to option 2 is “no”
22:49:04 cdent as that’s not "real"
22:49:12 jaypipes cdent: nested resource providers allows the placement API to understand whether, say, a PF that provides some VFs is on a particular compute node. Nested providers doesn't, however, solve the problem of how do we model the *request* for resources when the user doesn't know that there is a nested relationship between things.
22:49:40 jaypipes efried: there is no such limitation. I'm not sure what you're getting at.
22:50:19 mikal mriedem: I am a bad man and realized once that shred patch had merged that it probably should have had a reno, so I've added one in https://review.openstack.org/#/c/501022/
22:51:14 efried jaypipes What you and cdent were saying about breaking opaqueness? And a step backwards for original goals of allocation_candidates. I didn't catch where that came from.
22:51:15 cdent jaypipes: I get that the request modeling is a limitation, but if were to set that aside for a moment and we could express the request well then the we could present a complete set of allocations in response, right? The limitation as described in your paste is because the current request doesn’t have all the state.
22:52:03 cdent efried: ideally it would be possible to take the first item in the allocation_request list and send that to /allocations/{consumer_uuid} without modifications to make a “claim”
22:52:23 efried cdent Why doesn't that still work in this scenario?
22:52:34 jaypipes efried: the items in the "allocation_requests" part of the HTTP response for the GET /allocation_candidates placement API call is intended to be able to pass as-is (i.e. opaquely without the caller needing to know the structure of the HTTP payload) to the PUT /allocations/{consumer_uuid} call.'
22:52:38 cdent but if you’ve used multple requests to construct the set of rps, we don’t have enough info to construction all the pieces of the allocation
22:53:09 jaypipes cdent: correct.
22:53:25 cdent feh
22:53:43 efried Okay, I don't understand that, but I'm sure it's because I haven't read everything yet.
22:54:17 cdent efried: if you haven’t got it after some cogitation, ask me again a bit later and I can try to explain it using different words
22:54:49 cdent we’re making some shortcuts in our explanations that aren’t really helping matters
22:54:53 jaypipes cdent: thus my earlier comment that "fuck it..." we will probably end up needing yet another REST API call to placement that takes as a payload some crazypants HOT template|TOSCA YAML|CloudFormation template thing that describes all the various components of the instance that the user wants Nova to atomically claim and spawn.
22:54:54 efried cdent Thanks - I don't think it's words; it's background.
22:55:25 cdent jaypipes: i believe that’s where I feel like borrowing dansmith’s gun
22:55:44 jaypipes cdent: yup. and the reason I keep bringing up that I hate Nova being an orchestrator.
22:55:46 dansmith cdent: what kind you want? semi-auto? large bore? hollow points?
22:56:04 cdent dansmith: I’m away for home, so would feel bad for making a mess
22:56:08 cdent from
22:56:14 efried Every time this happens, though, I go away and study some more, and next time I come back and read the eavesdrop or whatever, I actually get it. I'm hoping to be good enough by the PTG not to get lost when this stuff is being discussed live.
22:56:15 dansmith cdent: okay so hollow-points then
22:56:17 jaypipes dansmith: shotty. it's got a "good spread".
22:56:41 jaypipes efried: no worries, man. these conversations are important to have.
22:56:45 cfriesen__ .700 nitro express
22:56:55 openstackgerrit Dan Smith proposed openstack/nova master: Split out the core of the ironic flavor migration https://review.openstack.org/501024
22:56:56 openstackgerrit Dan Smith proposed openstack/nova master: Add nova-manage db command for ironic flavor migrations https://review.openstack.org/501025
22:57:01 dansmith mriedem: dtantsur|afk ^
22:57:07 jaypipes efried: as much as they just inevitably end up reinforcing my annoyance with orchestration.
22:57:13 dansmith needs a reno but I'm out of brain power and the smoke is cutting my oxygen supply
22:57:49 efried cdent jaypipes So what we're talking about here is that we made an architectural call to be able to take a chunk of the placement response and just blat it into a (single) allocation request; but if we've made multiple calls to placement we'll have multiple such chunks, and there's currently no semantic for "combining" them into a single allocation request.
22:58:00 efried Did I get that right?
22:59:03 cdent jaypipes: sadly, somewhere is going to have to have a model for that tosca thing for an instance doign nested rp stuff and it is going to need to land on a compute (so the instance can build correctly). we planned ourselves into this corner, is just the way the world is for now :(
22:59:40 cdent efried: yes, pretty much. we’d need to build that “reassembler” in the scheduler and in a perfect world wouldn’t have to
23:00:10 efried In practical terms, the "opaque" allocation request is just a list of things, and we would just append those lists together and be fine. We just didn't wanna have to do that.
23:00:12 cdent we now need to be smart in at least two spots
23:00:53 cdent efried: not exactly.
23:01:11 cdent If we are lisp coders and are talking about this problem, then yes, we building lists
23:01:24 cdent but the selection of pieces is not just reassambling a sequence
23:03:53 efried jaypipes cdent I gotta run. FYI, I've been assembling notes which I eventually planned to link off of the main PTG etherpad once they were in a state where they were sanely readable by someone other than me. I'm not sure if we've reached that point yet, but... https://etherpad.openstack.org/p/nova-ptg-queens-generic-device-management
23:04:21 cdent thanks for doing that efried, you want annotations in the realm of “nowish” or “laterish”?
23:06:03 efried cdent I guess any-time-ish is fine, thanks. I didn't think I was done with it for sure, but I believe I've at least removed most of my horribly-misinformed early thoughts/ideas.
23:06:22 cdent ✔
23:07:06 efried Thanks as always for talking through this with me jaypipes cdent dansmith sean-k-mooney
23:09:46 jaypipes ciao
23:28:41 gmann mriedem, +1, i overlooked
23:30:11 gmann mriedem, can we have a specless BP for index schema chages - https://review.openstack.org/#/c/500347/ https://review.openstack.org/#/c/499091/ etc
23:30:30 gmann mriedem, that will be basically continuation of this - https://blueprints.launchpad.net/nova/+spec/consistent-query-parameters-validation
23:30:54 gmann it will be easy to track and capture any accidental API changes
23:37:00 gmann mriedem, created one, check if it looks fine - https://blueprints.launchpad.net/nova/+spec/json-schema-validation-for-index-query-param
23:37:06 gmann alex_xu, ^^
23:39:02 alex_xu gmann: thanks, that's great
23:47:07 openstackgerrit Chris Dent proposed openstack/nova-specs master: Add a spec for POST /allocations in placement https://review.openstack.org/499259
23:50:22 openstackgerrit Dan Smith proposed openstack/nova master: Add nova-manage db command for ironic flavor migrations https://review.openstack.org/501025
23:51:57 openstackgerrit Merged openstack/nova master: Add recreate test for forced host evacuate not setting dest allocations https://review.openstack.org/499678
#openstack-nova - 2017-09-06
00:33:33 mriedem gmann: these don't require microversion changes, correct?
00:34:00 openstackgerrit wanghongtaozz proposed openstack/nova stable/pike: spelling error availiable change to available https://review.openstack.org/501043
00:34:58 gmann mriedem, yes. only thing i want to confirm from alex_xu about restricting the int convertible string as limit like '1' it used to be valid and converted by utils previously and now it will be 400
00:35:26 gmann i think we discussed it in original spec but i do not remember the consensus .
00:36:17 mriedem gmann: if a microversion bump is required then i think we need a spec,
00:36:22 mriedem otherwise i'm ok with specless
00:37:06 gmann mriedem, yea, if so it need spec. we will discuss it in today meeting for all cases and ll update you
00:37:22 mriedem thanks
00:38:10 openstackgerrit wanghongtaozz proposed openstack/nova stable/pike: spelling mistake availiable change to available https://review.openstack.org/501045
00:41:29 openstackgerrit wanghongtaozz proposed openstack/nova stable/pike: spelling mistake prefered change to preferred https://review.openstack.org/501046
00:43:22 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: WIP spelling error availiable change to available https://review.openstack.org/501043
00:47:27 openstackgerrit wanghongtaozz proposed openstack/nova stable/pike: spelling mistake intergration change to integration https://review.openstack.org/501047
00:47:54 alex_xu mriedem: gmann it needn't microversion, I think just just add query params validation for the exist API and keep it same behavour for the API
00:49:02 gmann alex_xu, but we are doing non negative integer for limit - https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/keypairs.py#L109
00:49:21 gmann https://github.com/openstack/nova/blob/dbfde14978d4e4374c1fc1085c7f061b2a22d2c6/nova/api/validation/parameter_types.py#L438
00:50:00 gmann alex_xu, this is only case change the behavior for 'int' 200 -> 400

Earlier   Later