Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-03
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
18:31:16 efried jaypipes: I would like to rebase series https://review.openstack.org/#/c/554529/ on master, so I can start hacking granular on top. That okay with you, or do you have local changes?
18:33:32 cdent efried: do I recall correctly that https://review.openstack.org/#/q/topic:bp/placement-api-error-handling was driving some cleanups you were hoping to do? Or was there an even more pressing concern?
18:34:26 efried cdent: The former, I believe. I can't think of anything super urgent.
18:35:10 efried cdent: e.g. https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L633
18:35:18 cdent would be nice to get it through, so it is in there waiting when we want it
18:35:35 cdent actually I can think of a thing where we will want it:
18:35:35 efried foshizzle
18:35:53 cdent we want to know when an allocation fails because of generation versus out of space
18:36:09 cdent (when consumer generations come on the scene)
18:36:35 cdent Basically the same issue as with inventories, but on the flip side
18:37:41 efried As in, "help me decide whether this conflict is because of a generation mismatch or because a resource you're requesting via the allocation is not available"?
18:39:35 cdent_ efried: yes to [t qqJ] (I got disconnectioned)
18:39:35 purplerbot <efried> As in, "help me decide whether this conflict is because of a generation mismatch or because a resource you're requesting via the allocation is not available"? [2018-04-03 18:37:41.872921] [n qqJ]
18:40:13 efried We should have some spec cores give that the ol' +A. Seems pretty straightforward to me. dansmith jaypipes care to have a swag?
18:40:37 efried Maybe they were waiting on edleafe's +1
18:54:01 jaypipes efried: go for it.
18:55:03 efried jaypipes: Staring at it some, I'm not sure I can do it until I see how you're wiring in from AllocationCandidates.get_by_requests
18:55:08 edleafe efried: was on a call. What am I supposed to be +1ing?
18:55:31 efried edleafe: The error codes from placement API spec: https://review.openstack.org/#/c/546177/
18:55:58 efried edleafe: Sorry, the spec is here: https://review.openstack.org/#/c/418393/
18:56:43 efried jaypipes: my bad, I was looking at the code when I asked you to approve the spec, which you did a week ago. Carry on.
18:56:45 edleafe efried: ack. Have another meeting, but will look ASAP
18:57:19 efried edleafe: Looks like you +1ed two patch sets ago, so should be an easy one.
19:04:53 openstackgerrit Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
19:04:54 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
19:32:17 efried ?
19:34:22 cdent you watch many horror movies efried ?
19:34:46 efried clearly not
19:35:13 efried Is it, like, when you're being watched by the guy with the bad acne and the striped shirt?
19:36:40 cdent a chill fills the room when the monster transforms, perhaps?
19:41:17 efried Hah!
19:56:18 andrewbogott I've just upgrade my nova from liberty to mitaka (that's the release that added the api_db). I've done my nova-manage api_db sync but now any nova api calls return 404
19:56:29 andrewbogott I can see the api handling these calls, it just doesn't know anything.
19:56:45 andrewbogott Has anyone thought about that migration recently enough to have suggestions for what I should be looking for?
19:57:21 andrewbogott (I wonder if e.g. every project is now under some default domain or zone or something that I need to be specifying in my API call)
20:05:41 cdent jaypipes, efried: can we pretty please get forbidden traits merged before https://review.openstack.org/#/c/554529 ?
20:06:11 efried heh
20:06:52 efried cdent: I was actually just working up granular and thinking much the same thing. Would force jaypipes to make nested work for granular, rather than me having to do the reverse :P
20:07:04 cdent 'xactly
20:09:20 cfriesen andrewbogott: see subject line for the channel. that said, did you add the [api_database]/connection information to nova.conf?
20:09:43 andrewbogott cfriesen: Yep! But, I'll try over there.
20:16:28 andrewbogott cfriesen: is there a doc you can link me to that explains what that new database actually does? Is it just a cache?
20:24:26 cdent edleafe, jaypipes: i'm pretty sure the data model in https://review.openstack.org/#/c/557958/ (consumer generation) is wrong. even if I'm wrong about being wrong, then we need to make it clear in the commit why we're doing it weirdly.
20:27:59 cdent are we trying to log generation on the allocation as a sort of historical reference? that won't work because we delete all allocations for a cosumer when they change
20:28:16 cdent efried_schoolrun: you'll also be interested in ^
20:38:56 cfriesen andrewbogott: it's related to the cellsv2 work. the nova DB became per-cell, and the nova-api DB spans the cells and has higher-level stuff
20:39:21 andrewbogott ah, that makes sense, and might be a clue. thanks.
21:16:01 jaypipes cdent: you're absolutely right. no idea why I hadn't seen that. :(
21:16:48 cdent ETOOMUCHNUMA

Earlier   Later