| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 16:19:35 | bauzas | we can approve a spec and amend it later based on feedback that can come from the PTG or elsewhere | |
| 16:19:54 | edleafe | bauzas: the concern was that a series of related specs came out all at once | |
| 16:20:02 | bauzas | or we can at the end of the day have a spec that is approved but leading to a dead-end, that's not a problem to me | |
| 16:20:10 | edleafe | At first I thought I missed the discussions about them | |
| 16:20:13 | dansmith | I don't think the concern is over PTG discussion, | |
| 16:20:39 | dansmith | we can't tie spec approvals to ptg discussion globally.. not everyone can or will go, nor will we have enough time for that | |
| 16:20:54 | edleafe | dansmith: agreed. | |
| 16:20:57 | bauzas | edleafe: the relationship between specs is surely a thing to consider, but which shouldn't hold an approval if that's not blocking (heh, tautology) | |
| 16:21:11 | bauzas | dansmith: sure, hence my "or elsewhere" | |
| 16:21:48 | edleafe | bauzas: it was because there were a few unstated assumptions, such as the idea that we would be syncing nova aggs to placement aggs, that were surprising | |
| 16:22:12 | dansmith | edleafe: I dunno why that is surprising, I feel like we've covered that multiple times | |
| 16:22:28 | dansmith | but that said, I'm totally cool with letting the ink dry a bit on things before they go in so all the timezones have a chance to comment | |
| 16:22:32 | edleafe | dansmith: it's possible, but I must have missed those discussions | |
| 16:22:46 | dansmith | I actually thought we already were doing that syncing, | |
| 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 | bauzas | dansmith: for the usecase you described, I agree | |
| 16:52:05 | mriedem | like instance groups? | |
| 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 | |