Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-03
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
15:28:57 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820
15:28:57 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819
15:33:45 openstackgerrit Merged openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527
15:38:28 cfriesen anyone ever run into problems with privsep failing with a broken pipe? I'm trying to figure out what went wrong. http://paste.openstack.org/show/718307/
15:42:52 jaypipes cfriesen: sorry, never seen that :(
15:44:09 stephenfin cfriesen: I usually only see that what a process dies. Other than that, I've no idea
15:46:45 efried cfriesen: EPIPE happens when two threads are talking over RPC and the sender shuts down while the receiver is still waiting for stuff. But you probably knew that.
15:47:47 efried or... it might be vice versa. Point is, where they don't disconnect friendly-like.
15:48:07 openstackgerrit Merged openstack/nova master: Add trusted_certs to instance_extra https://review.openstack.org/537897
15:51:47 cdent cfriesen: I reckon your problem them is probably eventlet simply because if you've got a chance to blame eventlet for something, maybe you should.
15:52:02 cfriesen lol
15:52:13 zzzeek jaypipes: you should idle on #openstack-oslo :)
15:52:35 arvindn05 jaypipes: can we quickly discuss a review comment?
15:53:28 arvindn05 https://review.openstack.org/#/c/557795/ i replied to the comment on having specific field(required_traits) for traits vs using a dictofstring approach
15:54:52 openstackgerrit Merged openstack/nova master: Add trusted_certs object https://review.openstack.org/489408
15:55:04 arvindn05 i made the changes and i think its ready to merge but wanted to get your thoughts
15:58:15 bauzas FWIW, I'm now done with nova-specs and runways reviews, will work on my own spec
15:58:25 bauzas unless something urgent of course
16:07:01 arvindn05 dansmith: addressed the comment. Please provide your thoughts on one open question i had as well
16:15:28 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626
16:16:46 efried jaypipes, cdent, edleafe: We should have a (hopefully quick) chat about the question of including all provider information in provider summaries.
16:17:22 cdent efried: by "all" you mean "everything in this things tree and shared friends"?
16:18:00 efried cdent: At least "everything in this tree". I had thought the sharing would be "only sharing providers providing resource to the requests".
16:18:18 efried But even the former is in question.
16:18:30 efried We at some point decided that we wanted to return all the providers in the tree
16:18:37 efried even the ones not providing resource to the request.
16:18:40 efried Anyone remember why?
16:18:41 cdent I thought we had to do it order for weighers to work?
16:19:03 efried Yeah, weighers would be a good reason I suppose. But... more specifically?
16:19:23 efried like, in what circumstance would a weigher want to look at a provider that's not providing resource to the request?
16:19:29 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802
16:19:47 efried (Hint: future me will repeat question with "...look at a resource class that's not part of the request")
16:20:38 cdent I'm afraid I will have to defer to others as I have chosen to achieve ignorance on the details of this particular aspect of things to make room for other thoughts
16:22:03 jaypipes efried: here's an example...
16:23:31 jaypipes efried: imagine a NUMA topology weigher that looks at traits associated with NUMA nodes that are not providing resources for the allocation requests but the weigher (or even NUMA topology filter) would like to use the "intermediate" provider information in its decision-making.
16:25:04 efried Okay. So jaypipes what about resource classes? Do we show all of those?
16:25:09 efried for... similar reasons?
16:25:48 jaypipes efried: I don't see why not...
16:26:05 jaypipes efried: the reason we don't currently is mostly an implementation side-effect I think.
16:27:00 efried jaypipes: Well, I don't see why not either, other than the fact that it'll require a microversion, which is okay, but that requires a spec, which is also fine, but now we're looking at a nontrivial chunk of work, on top of an already overloaded release...
16:27:26 efried jaypipes: Anyway, I agree with you that we should do it. So at least https://review.openstack.org/#/c/558045/ and its predecessor are in the running.
16:27:39 efried and in fact intermingled with your nrp-in-alloc-cands work.
16:27:56 edleafe efried: no problem! https://www.youtube.com/watch?v=CJHoPm2d5CY
16:29:17 efried I also suspect that some of the work later on in that series - the stuff about including "anchor" providers - will overlap significantly with "make the rest of the tree show up".
16:30:30 efried jaypipes: cause that was another thing we didn't close on yesterday: what is the fate (at least in Rocky) of that series.
16:31:04 efried Last I heard, you were still going through the ML post. (You might still be. It was a lot of words. Sorry about that.)
16:31:16 jaypipes efried: the fate of the nested providers alloc candidates series?
16:31:30 efried jaypipes: No, hopefully that fate is well known.
16:31:43 efried The fate of the series starting at https://review.openstack.org/#/c/558044/
16:31:54 efried jaypipes: which is the subject of said ML post.
16:34:50 jaypipes efried: ok, I apologize, I haven't gotten to that yet. need to do the mirroring aggregates spec first.
16:49:37 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384
16:50:22 kashyap dansmith: johnthetubaguy: When you get a sec, addresesed what you requested.
17:17:41 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802
17:39:47 openstackgerrit Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057
17:39:48 jaypipes dansmith: ^^
17:40:01 jaypipes bauzas: ^^
17:45:37 openstackgerrit Arvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits https://review.openstack.org/557795
18:06:59 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757

Earlier   Later