Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-05
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
00:50:01 alex_xu gmann: that isn't backward-compatible?
00:50:26 alex_xu gmann: I remember there are some validation in the python code for the limits, that should check the non-negative value also
00:51:06 gmann alex_xu, humm
00:51:15 gmann alex_xu, i found the flow like this
00:51:16 gmann 1. https://github.com/openstack/nova/blob/dbfde14978d4e4374c1fc1085c7f061b2a22d2c6/nova/api/openstack/common.py#L189
00:51:30 gmann 2. https://github.com/openstack/nova/blob/dbfde14978d4e4374c1fc1085c7f061b2a22d2c6/nova/api/openstack/common.py#L202
00:52:10 gmann 3. https://github.com/openstack/nova/blob/dbfde14978d4e4374c1fc1085c7f061b2a22d2c6/nova/utils.py#L883

Earlier   Later