Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-15
16:22:56 dansmith because of the method for doing so in the scheduler client, which is apparently unused as of yet
16:22:58 edleafe dansmith: I still repeated the mantra "placement aggs are not nova aggs"
16:23:14 dansmith ...which is still true :)
16:24:33 edleafe now it's "placement aggs *are* nova aggs, and then some"
16:24:35 edleafe :)
16:24:44 mriedem fwiw i never thought we were syncing nova aggs to placement aggs, or intended to do so, before yesterday
16:24:57 mriedem edleafe: but they aren't
16:25:02 mriedem placement aggs don't have metadata
16:25:07 mriedem they don't have to exist for anyone outside of nova
16:25:18 edleafe mriedem: I don't mean they are exactly the same
16:25:34 mriedem i believe jay said they'd be a superset of nova host aggregates, which i think is correct
16:25:43 edleafe mriedem: just that if a compute node is in a nova agg, it will also be a matching placement agg
16:25:48 dansmith right, a superset
16:25:51 mriedem because my compute node providers could be in an aggregate that mirror a nova host aggregate, and also in a shared storage provider aggregate with cinder
16:26:14 dansmith aggregates are a thing that placement provides for consumers to group resource providers,
16:26:17 bauzas mriedem: edleafe: if we only keep placement aggregates as a bag of a collection of hosts, I'm fine with sync'ing that to nova
16:26:24 edleafe again, I don't think that this is a bad approach
16:26:38 edleafe it was just a big surprise
16:26:40 dansmith nova is a user of placement and thus would use it to augment its grouping when placing instances,
16:26:52 bauzas what I'm not okay is if placement aggs begin to have metadata information that carries some superseding logic
16:26:58 dansmith as I would expect neutron to create aggregates to mirror is grouping constructs when it helps to place things, cinder the same
16:27:03 bauzas yeah that
16:27:06 mriedem bauzas: no one said they would, and i'm sure jaypipes' head would explode
16:27:08 mriedem if we said that
16:27:17 bauzas mriedem: just stating loud things
16:27:41 mriedem maybe i should update https://review.openstack.org/#/c/539033/
16:28:11 bauzas mriedem: please, CC'ing that change
16:28:36 bauzas since my brain is untrustable, I need to star things
16:31:00 mriedem edleafe: ^ replied in that change, see what you think
16:31:09 mriedem the point of that patch is to provide an example,
16:31:30 mriedem since mgagne correctly pointed out that the api-ref today only talks about what placement aggregates "aren't", not an example of what they "are"
16:32:56 hrw my next patch will look weird for some. There will be comments added to explain why that way
16:33:06 bauzas jaypipes: don't use Bravecto
16:33:13 bauzas on your pugs
16:33:23 openstackgerrit Merged openstack/nova master: [libvirt] Add _get_vcpu_realtime_scheduler() https://review.openstack.org/527630
16:34:04 hrw does virt/libvirt/driver.py have access to config entries from nova.conf?
16:34:16 bauzas hrw: of course
16:34:53 hrw pcie.numberofslots (int8) will be new option
16:35:10 jaypipes hrw: yes. via the global CONF variable.
16:35:34 hrw or rather libvirt.pcie.numberofslots or sth like that
16:35:53 jaypipes hrw: python doesn't have an int8. :) you're Golanging.
16:36:03 hrw so admin can set how many 'slots' VM will have
16:36:21 hrw jaypipes: int5 even ;D and I know that python is typeless
16:37:02 jaypipes hrw: it's int5 today. I'm sure a certain hardware manufacturer will change that at some point in the future...
16:38:10 hrw jaypipes: have nothing against it in real hw
16:38:26 hrw jaypipes: there are cpus with >32 pcie lines so it is (in theory) possible
16:38:47 jaypipes hrw: yup.
16:39:24 hrw jaypipes: I remember time when my arm64 machine boot was ~13 minutes due to pci bus scanning
16:40:09 mriedem mnaser: you magnificent bastard, you clarified my big sticking point in melwitt's patch,
16:40:35 mriedem the main thing is that when the instance is in cell0, instance.host is None but the vm_state is ERROR, so we don't enter that first block of code because "if not has_been_scheduled" is False
16:40:47 jaypipes hrw: I remember a time when we weren't coding hardware-defined software ;)
16:40:53 mriedem and the context is targeted at cell0 because the api code does that when we pull the instance out of cell0
16:40:59 mriedem so we can get bdms using that context too
16:41:18 mnaser mriedem: i won't take credit, i had the same train of thought, and melwitt corrected me :p
16:41:43 mriedem the has_been_scheduled variable name is confusing i think
16:41:50 mriedem but i don't have a better alternative
16:42:09 hrw jaypipes: I am not getting young as well ;D
16:42:13 mriedem has_been_scheduled_or_should_be_in_cell0_or_idk_whatever
16:48:43 hrw https://paste.fedoraproject.org/paste/A9Gtb~sliIFo2-yvA32ymw - preliminary version
16:50:54 bauzas dansmith: I left some comments but only one is blocking me from +2 on https://review.openstack.org/#/c/544585/6
16:51:17 bauzas dansmith: the fact that I wonder if we should persist the changes in the RequestSpec or not
16:51:44 dansmith bauzas: why wouldn't we?
16:51:51 bauzas maybe it's just an implementation detail, but we've seen in the past some problems with the RequestSpec fields that were badly designed whether they should be persisted or not
16:52:05 mriedem like instance groups?
16:52:05 bauzas dansmith: for the usecase you described, I agree
16:52:26 dansmith bauzas: we'll re-run the pre filters on reschedule, so persisted data could be kept, re-evaluated, updated, etc
16:52:37 bauzas dansmith: but since we'll define a modular mechanism, we could end up having cases where it's necessary and some not
16:52:49 bauzas dansmith: that answer suits me
16:53:03 dansmith yeah, each one could do a different thing with the persisted data
16:53:07 mriedem yeah we'd definitely need this for any move operations
16:53:16 bauzas dansmith: we could persist that, but we shouldn't use that value on a later reschedule but rather recalculate it
16:53:31 bauzas that being a per-filter policy
16:53:33 dansmith bauzas: depends
16:53:35 dansmith yeah
16:53:37 dansmith I will reply
16:53:41 bauzas cool
16:53:44 bauzas one last point
16:53:46 bauzas but it's a nit
16:53:54 bauzas I'm poor at wording
16:54:08 bauzas but I'm afraid the word "filter" carries a lot of context
16:54:27 bauzas so I'd prefer to use a synonym for that mechanism
16:54:33 bauzas I know it's sneaky
16:54:50 bauzas so feel free to NACK me
16:54:52 dansmith bauzas: it's not exposed as a filter to the user or admin at all
16:55:06 dansmith bauzas: so we can change it either now or later if it becomes a problem
16:55:19 bauzas yeah it's just wording
16:55:26 dansmith but, IMHO, it's not a big enough deal to rename the things I have already :)
16:55:31 bauzas like we have nova aggs and placement aggs
16:55:41 bauzas dansmith: not requiring a respin of your spec
16:55:57 bauzas dansmith: but maybe we should consider that in your series :)
16:56:13 dansmith bauzas: well feel free to take exception to it in the code if you still feel that way yeah
16:56:16 bauzas scheduler filters and request filters seem very identical to me in terms
16:56:51 bauzas again, it's maybe me overreacting on some blueprints I could see in the future
16:57:07 dansmith what word do you like better?
16:57:10 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Allow to configure amount of PCIe slots in aarch64 instance https://review.openstack.org/545034
16:57:28 hrw cna someone take a look at that patch? mriedem stephenfin bauzas?
16:57:40 bauzas dansmith: from a French folk, the Thesaurus tells me "strain"
16:57:54 dansmith lol
16:57:55 bauzas but anyway, I feel ashamed of nitpicking on that
16:58:06 dansmith that would make no sense to an english speaker

Earlier   Later