Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-26
15:43:50 dansmith because later that will be out of tree and we won't use it to communicate with our own reportclient I think
15:43:50 efried dansmith: yeah. I think the sooner we get to the list-of-tuples representation, the better. So option 2
15:43:58 dansmith mkay
15:44:12 efried dansmith: It's just because RequestGroup is used by both nova side and placement side.
15:44:26 efried on the placement side, we parse the incoming querystring into the exact same representation.
15:44:36 dansmith yeah, this seems like code sharing we should be removing so that we don't have any ties
15:44:41 efried It's like... having a serializable object without having a serializable object.
15:45:23 efried dansmith: Well, cdent is aware, and was involved in the review process (I think). I imagine there will come a time when there will be a placement_lib module that both of them will import.
15:45:58 dansmith I don't see why we'd use that to communicate between internal components of nova, unless it provides a lot of pre-calculation of things or something, which it does not do now,
15:46:22 dansmith but just be advised how hard it will be to land changes to that across both projects and update requirements and such before you can use a new thing if we go that route
15:46:34 cdent I think I expressed reservations at the time, but mostly shrugged in a "we'll figure it out" and "if it helps now, cool" kind of way.
15:46:50 dansmith this provides zero help in its current form, IMHO :)
15:47:13 efried dansmith: Well, only because we haven't closed the final switches on granular yet.
15:47:30 cdent It helps on the placement side to decode the query string, but on the nova side, dunno. I'm not paying huge amounts on the nova side as it is just too hard to keep track of _all_ things
15:47:49 cdent yeah, I think it is groundwork for stuff that was expected sooner than turned out
15:48:11 efried dansmith, cdent: On the nova side it lets us parse extra_specs; on the placement side it lets us parse the querystring. On both sides they parse into the same representation.
15:48:19 efried which is (or will be) useful).
15:48:22 efried ))
15:48:24 efried (((
15:48:25 dansmith cdent: it's just a class with a few variables righ tnow
15:48:41 dansmith anyway, I'm just pre-complaining, nothing that is going to block me right now
15:49:27 cdent dansmith: yeah, I know. I'm mostly speaking generally: I've de-prioritized my attention to the nova side of things for sake of being able to get anything done
15:55:10 openstackgerrit melissaml proposed openstack/nova master: fix a typo in service.py https://review.openstack.org/556575
15:56:00 openstackgerrit Merged openstack/nova master: Updated from global requirements https://review.openstack.org/556418
15:57:09 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option https://review.openstack.org/554688
15:57:59 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM: Add proc_units_factor conf option https://review.openstack.org/554688
16:06:24 mriedem like killing mosquitoes https://review.openstack.org/#/c/556575/
16:06:40 mriedem https://review.openstack.org/#/c/545528/
16:07:17 mriedem https://review.openstack.org/#/c/555404/
16:07:18 mriedem geez
16:07:20 mriedem yay!
16:07:36 mriedem efried: "Note that some people are opposed to typo-in-comment-or-docstring patches. It's a religious thing, I think. So don't be surprised if this gets the kibosh." heh
16:08:28 mriedem i'm not opposed to fixing documentation if it makes the documentation more clear, i am opposed to stat padding py pushing several 1-line spell check fixes across openstack at random
16:08:34 mriedem *by pushing
16:10:29 efried mriedem: I thought we didn't put enough stock in stats to make that the sole reason for rejecting things like this. IMO patches like this could be fast-approved more quickly than they can be squashed. And let the author have the stats - what difference does it really make?
16:10:36 efried Anyway, that's my 2c
16:10:49 mriedem it's not the sole reason
16:10:54 stephenfin I'd be more lenient. If it doesn't cause merge conflicts, it's good and could be conceivably fast approved. If someone's basing their employee reviews on Stackalytics, they're the fools
16:10:57 mriedem it's also noise
16:11:49 efried Meh, how much noise is it really? Are you worried about an explosion of trivial patches if you start approving these?
16:12:22 mriedem imo it encourages bad behavior
16:13:26 cdent FWIW I agree with efried
16:13:51 cdent the only thing that should matter in the end is the quality of the code
16:14:26 stephenfin cdent: With the caveat that it's trivial and doesn't cause merge conflicts. Functional changes still have to take priority
16:14:29 efried I agree there's a balance to be struck against reviewer time. In this case, it's eta/eta
16:14:59 efried (or whatever greek letter means "something really small")
16:15:11 bauzas gosh, I'm about to ragequit because of all the NUMA quirks we need to support
16:15:24 stephenfin bauzas: You're welcome :)
16:15:47 bauzas faking cpu sockets for licensing reasons => booooh
16:16:33 bauzas the question I wonder is, should https://docs.openstack.org/nova/latest/admin/cpu-topologies.html#customizing-instance-cpu-topologies be Placement-specific ?
16:16:36 bauzas my guts say no
16:16:42 bauzas stephenfin: jaypipes: thoughts on that ?
16:17:01 stephenfin What do you mean, "placement-specific"?
16:17:10 bauzas Resource classes and other things
16:17:32 bauzas IMHO, we should just provide the NUMA topology, find a node and period.
16:17:36 jaypipes bauzas: on a call... gimme a bit.
16:17:45 stephenfin bauzas: It doesn't affect what you need to claim so IMO no
16:17:55 bauzas yup, cool
16:17:57 stephenfin but jaypipes might have other ideas, once he's free
16:18:40 openstackgerrit Merged openstack/nova master: Fix api-ref: nova image-meta is deprecated from 2.39 https://review.openstack.org/554813
16:22:43 bauzas efried: question, can I ask for both a resource query on a root node *and* a child RP ?
16:23:34 efried bauzas: The only place you can ask for resources that span RPs is in the un-numbered request group.
16:23:40 bauzas ideally, I'd love to see something like MEMORY_MB on both the root RP *and* the NUMA node
16:24:01 bauzas efried: can you please explain further ?
16:24:12 efried bauzas: Are those separate blocks of memory?
16:24:17 bauzas I dunno yet
16:24:21 bauzas (tbh)
16:24:39 bauzas I'm just hardly trying to not lock all the world
16:25:03 efried IMO we should not try to do the thing where we have e.g. 2048MB of memory in each NUMA node and then represent 4096MB on the compute node which isn't really there.
16:25:05 bauzas like I'd like to provide a mechanism to select a NUMA node but huge pages could still be checked by the virt driver
16:26:02 bauzas efried: I got your point, my problem is more about trying hard to not draw a house of cards
16:26:15 efried bauzas: is there a fixed ratio between memory MB and number of huge pages?
16:26:32 bauzas efried: the solution is simple in my mind
16:26:42 bauzas that's all about traits and step_size
16:26:45 bauzas but
16:26:59 bauzas if we go decide to provide a tree of NUMA nodes
16:27:35 bauzas but we don't support yet hugepages, then we have a problem because flavors asking for hugepages would get NoValidHosts
16:28:01 bauzas we somehow still need to accept compute nodes to report their memory the old way
16:28:09 efried what's a hugepage?
16:28:17 efried (use little words)
16:28:26 bauzas https://docs.openstack.org/nova/latest/admin/huge-pages.html
16:28:39 bauzas it's a defined memory page size
16:28:48 bauzas but that's just an example
16:28:57 bauzas for the moment, placement only checks the total memory of the host, right?
16:29:12 bauzas then the scheduler filter does magic things to find a destination
16:29:40 efried Well, yeah, so this is kind of in line with what we need to do wrt bandwidth.
16:29:52 efried We represent the number of huge pages as inventory alongside the MEMORY_MB inventory.
16:29:53 efried but
16:30:12 efried if the consumer is going to include hugepages as part of their request, they *always* need to do so.
16:30:27 bauzas so, my concern is that if I'm beginning to shard the memory between NUMA nodes, then it requires the flavors to be updated to explicitly ask for a NUMA node, whereas huge pages are totally NUMA unrelated
16:30:59 efried because what we can't (or shouldn't) do is try to convert a request for MEMORY_MB:4096 into MEMORY_MB:4096,HUGEPAGES:4 (or whatever)
16:31:26 bauzas efried: I'm not trying to design now how to make placement queries for hugepages
16:31:29 efried bauzas: But does a huge page come from the same place as a MEMORY_MB or is it a separate thing?
16:31:46 bauzas efried: what I'm trying is to make sure we keep a compatible behaviour for the existing feature
16:32:05 bauzas others, later, will try to solve that design and use placement resources for that
16:32:13 bauzas like the PCPU spec
16:33:06 efried bauzas: okay, maybe we back up and I just answer your original question :)
16:33:06 bauzas but again, what I want is to make sure that if operators enable reporting of NUMA nodes using NRPs, then it can still be possible to use hugepages flavors for finding a destination
16:34:51 efried You can specify multiple resources of different classes in a request group. A numbered request group will get *all* of those resources from the *one* resource provider. The un-numbered request group will get the resources from any provider in a tree or associated sharing providers. However, even in the latter case, all resources of a specific resource *class* will still come from a single provider.
16:39:51 bauzas efried: I see, thanks

Earlier   Later