Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-12
15:33:44 openstackgerrit Chris Dent proposed openstack/nova master: Isolate config parse_args for placement https://review.openstack.org/543495
15:35:46 AJaeger mriedem, the novaclient reviews I mentioned earlier are: review https://review.openstack.org/543115 , https://review.openstack.org/#/c/543114, https://review.openstack.org/#/c/541370/ - the first two are needed to fix the jobs, the third is needed for Zuul v3.
15:37:59 openstackgerrit Sylvain Bauza proposed openstack/nova master: doc: BFV instances and IsolatedHostsFilter https://review.openstack.org/543494
15:38:16 bauzas mriedem: just made a first try for doc ^
15:40:41 AJaeger thanks, mriedem
15:41:26 bauzas stephenfin: sahid: do you have any idea why the NUMATopologyFilter needs to set some limits for CPU and RAM ? https://github.com/openstack/nova/blob/master/nova/scheduler/filters/numa_topology_filter.py#L92-L93
15:41:33 bauzas context is https://bugs.launchpad.net/nova/+bug/1748858
15:41:34 openstack Launchpad bug 1748858 in OpenStack Compute (nova) "allocation_ratio set by aggregate metadata don't work in NUMATopologyFilter" [Undecided,New] - Assigned to yangjie (yang.jie)
15:42:13 bauzas stephenfin: sahid: the NUMATopologyFilter should only care in my opinion to enforce the numa limits, not any other resource usage
15:42:34 stephenfin bauzas: Not off the top of my head, no. That whole 'NUMATopologyLimits' object is a weird one I've yet to grasp properly. Hopefully sahid knows more
15:49:19 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix typo in NUMATopologyFilter docs https://review.openstack.org/543505
15:56:17 mriedem bauzas: fwiw, the image properties are stored on the volume's volume_image_metadata dict: http://paste.openstack.org/show/670139/
15:56:27 mriedem i add foo=bar to the image i used to create that bootable volume
15:56:52 mriedem so AggregateImagePropertiesIsolation would only be as good as how accurate that metadata is
15:56:58 bauzas mriedem: are you persuing me to look up the volume if BFV ?
15:57:05 mriedem since nova doesn't re-fetch the image to get the latest meta
15:57:17 mriedem persuing you how?
15:57:43 bauzas the fact is that filters don't lookup the volume image metadata, right?
15:57:49 bauzas they just assume every instance has an image
15:58:10 bauzas well, they rather assume every RequestSpec has an image
15:58:18 mriedem the filter assumes the request spec image has the details from when the api created the request spec
15:58:22 mriedem yes that
15:58:48 mriedem and the request spec for a volume-backed instance will have the image meta stored in the volume from the time the volume was created
15:59:10 bauzas mriedem: if we create a fake image based on that, right?
15:59:13 mriedem but my point is, i could create a volume with some image, then change properties on that image, and then create a server from the volume and the image meta in the volume would be stale
15:59:21 bauzas I agre
15:59:24 bauzas I got your point
15:59:52 bauzas if we want to support BFV instances correctly, we would necessarly have to lazy-load things on the fly if we need to access the "image"
16:00:18 bauzas hence the "are you persuing me to lookup the volume"
16:00:42 mriedem no i'm not suggesting that,
16:01:05 mriedem i was saying, if we cared, we could get the image_id from the volume meta, and lookup the image at server create time to get the current image meta from glance
16:01:10 mriedem rather than the possibly stale image meta from the volume
16:01:27 mriedem but, i'm not suggesting we do that either
16:01:41 mriedem i guess we should just assume that the image meta with the volume is like a snapshot
16:01:55 mriedem if the image meta is changed after the volume is created, meh
16:02:25 mriedem if it was changed in such a substantial way that it would impact nova scheduling for the instance, then it should probably be a different image
16:03:48 bauzas that looks like the best, indeed
16:07:26 bauzas mriedem: https://bugs.launchpad.net/nova/+bug/1748858
16:07:28 openstack Launchpad bug 1748858 in OpenStack Compute (nova) "allocation_ratio set by aggregate metadata don't work in NUMATopologyFilter" [Undecided,Won't fix] - Assigned to yangjie (yang.jie)
16:07:56 bauzas mriedem: we can clarify the doc, but I don't feel we should open a can of worms about aggregate ratios
16:10:49 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Snapshot https://review.openstack.org/543023
16:12:15 mriedem bauzas: i don't either
16:13:19 openstackgerrit Merged openstack/nova-specs master: Fix the names on some specs https://review.openstack.org/542504
16:15:13 openstackgerrit Merged openstack/nova-specs master: Move queens implemented specs https://review.openstack.org/542505
16:18:00 openstackgerrit Eric Berglund proposed openstack/nova master: Use dict.get() when accessing capabilities dict https://review.openstack.org/539715
16:38:57 openstackgerrit Bence Romsics proposed openstack/osc-placement master: PUT dict format to /allocations (v1.11, v1.12) https://review.openstack.org/542819
16:40:13 openstackgerrit sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008
16:46:28 openstackgerrit sahid proposed openstack/nova master: hardware: only take into account small pages https://review.openstack.org/532168
16:55:15 gibi mriedem: Would it be OK with you cancelling the next 3 notification subteam meeting? This week I don't feel we have things to talk about and next week I will already travelling to Dublin and then there will be PTG week.
16:56:07 mriedem gibi: works for me
16:56:46 gibi mriedem: OK, cool
17:04:37 mgariepy is there a way to set a flavor to set the kvm=off option or i really need to pass the key from glance image ?
17:05:16 mgariepy referring to : https://review.openstack.org/#/c/459753
17:06:04 openstackgerrit Matt Riedemann proposed openstack/nova master: Move the nova-next job in-tree and update it https://review.openstack.org/541474
17:06:04 openstackgerrit Matt Riedemann proposed openstack/nova master: Test websocketproxy with TLS in the nova-next job https://review.openstack.org/513160
17:06:48 mriedem mgariepy: looking at the code https://review.openstack.org/#/c/459753/18/nova/virt/libvirt/driver.py@4184 it only checks the image meta, not flavor extra specs
17:07:39 mgariepy thanks mriedem i'll add the key to an image would it be a lot of work to add that to flavor extra specs ?
17:08:35 mriedem probably not a lot of work, no, but generally i think we prefer image meta since those are standardized and flavor extra specs are not
17:09:33 mriedem i guess the flavor extra spec could maybe make sense in this case if you're using a GPU trait on the flavor or something
17:09:51 mriedem https://docs.openstack.org/nova/latest/admin/virtual-gpu.html#configure-a-flavor-controller
17:10:12 mriedem this is getting dangerously into bauzas territory though
17:12:16 mgariepy i define my flavor to have the gpus via pci_passthrough:alias would have liked to have the hidden kvm stuff on that flavor as well.
17:12:30 mgariepy but as long as it works i guess i'll use the workaround.
17:13:24 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Do not attempt volume swap when guest is stopped/suspended https://review.openstack.org/533733
17:15:11 mriedem mgariepy: ok, i guess it's unclear to me if that's only an issue for windows guests as the commit message implies
17:15:33 mgariepy i need that for linux guest as well.
17:15:33 mriedem in that case it makes sense to me to be tied to the image
17:15:37 mriedem oh
17:15:56 mgariepy nvidia driver don't like kvm guest.
17:16:47 mriedem i'm just amazed the thing is documented https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html
17:16:52 jaypipes efried: where is that Numbered Request Group Affinity spec?
17:17:17 efried jaypipes: It's not a spec... yet. It's a subsection under Alternatives.
17:17:39 efried jaypipes: I'm considering writing a spec for it, though. It would be largely the same as the one you're looking at.
17:57:19 openstackgerrit Merged openstack/nova-specs master: Granular Resource Request Syntax (Rocky) https://review.openstack.org/540179
17:58:34 edleafe jaypipes: Did we ever answer the question about whether we need "distance" to be continuous or binary? IOW, do we need "at least 2 away" or "closer than 5", or do we just need "is/isn't in the same grouping"?
17:58:52 edleafe jaypipes: you mentioned some HA use cases that I'm not familiar with
18:08:14 openstackgerrit Merged openstack/nova master: Add regression test for BFV+IsolatedHostsFilter failure https://review.openstack.org/543257
18:08:31 openstackgerrit Merged openstack/nova master: Handle volume-backed instances in IsolatedHostsFilter https://review.openstack.org/543263
18:08:56 openstackgerrit Merged openstack/nova master: Fix docs for IsolatedHostsFilter https://review.openstack.org/543264
18:13:22 jaypipes edleafe: well, the HA use cases are more about anti-affinity... i.e. "make sure the three nodes of my cluster are running in separate failure domains (or groups, or racks, or whatever)"
18:14:57 edleafe jaypipes: thanks. Are there any cases that you know of that don't boil down to yes/no? Like, are X and Y in the same "thing" (rack, row, etc.) or aren't they
18:15:36 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: libvirt: Block swap_volume attempts with encrypted volumes https://review.openstack.org/543569
18:17:38 jaypipes edleafe: yeah. the whole "soft affinity" is what those use cases are about.
18:17:52 jaypipes edleafe: in "soft affinity", it's a preference vs. yes/no
18:18:22 jaypipes edleafe: i.e. "place these things *as near to each other* as possible" or "place these related things as far away as possible"
18:18:51 jaypipes edleafe: in the soft affinity cases, the distance being relative and not yes/no enables that sorting of potential destinations
18:19:59 edleafe jaypipes: how widespread is that need? IOW, 20% of use cases? 1%?
18:20:14 jaypipes edleafe: the soft affinity thing?
18:20:57 edleafe jaypipes: yeah. It seems like overkill to build all our affinity/anti stuff to handle these types of things
18:21:09 jaypipes edleafe: BTW, the "soft" stuff is also interpreted as "if the strict condition doesn't hold, then just get me the thing that closest matches my condition" -- i.e. sorting..
18:21:25 edleafe jaypipes: when the vast majority just want yes/no
18:21:28 jaypipes edleafe: it may indeed be overkill. but it's what we currently have.
18:21:43 edleafe jaypipes: where do we have it?
18:22:24 jaypipes edleafe: the soft affinity "filters" are implemented as weighers.
18:22:28 openstackgerrit Matthew Edmonds proposed openstack/nova master: improve support matrix notes https://review.openstack.org/540534
18:22:38 jaypipes edleafe: https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py
18:24:01 edleafe jaypipes: that doesn't use any sort of "distance" concept. It just favors those things that meet (anti)affinity
18:24:39 jaypipes edleafe: correct.
18:26:10 jaypipes edleafe: the distance thing is something we need in order to understand the difference between various failure domain sizes. it's also necessary for informing placement about the different "levels" of affinity. right now, Nova only knows one level (the compute *host* (note: *not* the compute *node*). In other words, Ironic can't use the existing affinity filters/weights in Nova.
18:26:31 jaypipes edleafe: this is partly to address that issue: https://review.openstack.org/#/c/529135/

Earlier   Later