| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-15 | |||
| 15:44:41 | mriedem | dansmith: i'm assuming the pre-placement filters would also be pluggable? | |
| 15:45:01 | dansmith | mriedem: modular, like our scheduler filters, not necessarily pluggable | |
| 15:45:06 | bauzas | if we're about to introduce a new hook for cheating placement to only return the subset we want, chances are that in the future ops will come with solid use-cases | |
| 15:45:24 | dansmith | bauzas: cheating placement? I can't understand how this is that :) | |
| 15:45:30 | bauzas | and at the end of the day, we'd just introduce more and more complexity to placement | |
| 15:45:39 | dansmith | this doesn't change placement at all | |
| 15:45:41 | dansmith | not a single bit | |
| 15:45:48 | mriedem | these pre-placement filters are restricted to what placement api supports | |
| 15:45:55 | bauzas | dansmith: for your proposal, I agree | |
| 15:45:56 | mriedem | which is resource classes, traits and aggregates | |
| 15:46:00 | dansmith | they operate on request spec | |
| 15:46:20 | bauzas | dansmith: again, I'm not opposed to *your* use case which is tenant filtering | |
| 15:46:41 | mriedem | i also have a use case for this | |
| 15:46:46 | mriedem | if you care | |
| 15:46:49 | bauzas | that said, we could do that without using aggregateds | |
| 15:46:54 | bauzas | I guess | |
| 15:46:56 | bauzas | anyway | |
| 15:47:07 | bauzas | finding use-cases is not the thing I'm worried | |
| 15:47:15 | bauzas | I'm more worried by how big it can become | |
| 15:47:46 | mriedem | we knew we wanted to move filters in sql via placement as much as possible since the beginning right? | |
| 15:47:48 | dansmith | I think I need a more concrete argument than that to understand the concern :) | |
| 15:48:07 | bauzas | dansmith: hence why I'm discussing over IRC | |
| 15:48:19 | bauzas | FUD isn't a valid argument and I respect that | |
| 15:48:27 | dansmith | IMHO, this is the natural evolution of us asking placement for hosts based on resources (which it deals with) and then traits (which it deals with) and now aggregates (which it deals with) | |
| 15:48:31 | bauzas | I just need to understand the context | |
| 15:49:16 | dansmith | bauzas: why don't you want to hear mriedem's use case? | |
| 15:49:29 | bauzas | dansmith: I'm open to his use-case | |
| 15:49:52 | dansmith | bauzas: I also had a BFV use case in the first rev of the spec, | |
| 15:50:15 | dansmith | but removed it because it was distracting to some people | |
| 15:50:16 | bauzas | the limitation thing is certainly a valid argument | |
| 15:50:29 | bauzas | because we need to get all the corresponding hosts from placement | |
| 15:50:40 | bauzas | if we say we won't allow pluggability, I think I'd be okay | |
| 15:50:53 | dansmith | personally I don't want this to be pluggable, just modular | |
| 15:51:01 | dansmith | (brb) | |
| 15:51:02 | bauzas | then okay | |
| 15:51:14 | bauzas | if we're all clear that we will never open that to ops | |
| 15:51:16 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Update Provider Tree https://review.openstack.org/540111 | |
| 15:51:18 | mriedem | bauzas: what i want to use this for is making sure we can pick a host that supports multiattach volumes for bfv, and tagged attach during bfv | |
| 15:51:26 | efried | edleafe, jaypipes, cdent: There's that reword ^ | |
| 15:51:36 | mriedem | bauzas: because today that's just luck of the host and we don't reschedule on failed volume attaching during bfv | |
| 15:51:51 | bauzas | mriedem: you could achieve that with a filter, right? | |
| 15:52:12 | bauzas | atm, we have two placing mechanisms | |
| 15:52:16 | bauzas | #1 is placement | |
| 15:52:20 | bauzas | #2 is filters | |
| 15:52:29 | mriedem | do we have a filter that actually has the driver.capabilities information exposed to it? | |
| 15:52:33 | bauzas | I agree with both of you to try to make #1 prioritary | |
| 15:52:38 | cdent | efried: good, thanks | |
| 15:52:57 | efried | bauzas: IMO we should do any filtering that's possible/practical to do in placement, in placement. Cause that'll be more efficient. | |
| 15:52:58 | bauzas | mriedem: we have one caring about the compute capabilities themselves | |
| 15:53:08 | mriedem | bauzas: but i'm not sure if that filter actually gets that data | |
| 15:53:24 | bauzas | efried: yeah, hence my | |
| 15:53:25 | bauzas | (16:52:33) bauzas: I agree with both of you to try to make #1 prioritary | |
| 15:53:38 | efried | cool | |
| 15:53:39 | bauzas | okay, looks like I'm settling down | |
| 15:53:58 | mriedem | i have a hard time even grokking the code in the compute capabilities filter | |
| 15:53:58 | bauzas | #1 scheduling (placement) shouldn't never be open to operators | |
| 15:54:18 | bauzas | #2 scheduling (filters) would eventually only be custom | |
| 15:54:27 | bauzas | if we could | |
| 15:54:48 | bauzas | looks like a deal then | |
| 15:54:49 | mriedem | the ComputeCapabilitiesFilter works on the HostState.stats right? | |
| 15:56:07 | mriedem | anyway, it would be easy to make one of these pre-placement filters that sees, 'oh you're doing bfv with a multiattach volume, let me add required trait CUSTOM_COMPUTE_SUPPORTS_MULTIATTACH to the request to placement for filtering' | |
| 15:56:11 | efried | bauzas: Not sure I agree that ops don't affect placement-level scheduling. They do so via traits etc. | |
| 15:56:37 | efried | mriedem: ++, assuming the compute got tagged with that trait somehow | |
| 15:56:40 | jaypipes | efried: +2 | |
| 15:56:47 | mriedem | efried: that's https://review.openstack.org/#/c/538498/ | |
| 15:56:56 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2018-January/126653.html | |
| 15:56:58 | mnaser | mriedem: left some comments about the change .. to the best of my knowledge | |
| 15:57:00 | bauzas | efried: no, I meant custom code modifying behaviour of placement | |
| 15:58:13 | bauzas | mriedem: IIRC, the ComputeCapabilitiesFilter matches any HostState field | |
| 15:58:15 | bauzas | that's magic | |
| 15:58:21 | cdent | yes, definitely custom code should not happen to placement | |
| 15:58:31 | dansmith | cdent: that's not what he's saying here htough | |
| 15:59:12 | bauzas | dansmith: so, modularity is good, provided we don't open the entry points | |
| 15:59:24 | dansmith | cdent: nobody is talking about touching placement at all, he's talking about in this code that we use to query placement | |
| 15:59:26 | bauzas | dansmith: a big fat comment in the code would be fine for me | |
| 15:59:48 | dansmith | bauzas: we don't comment code that isn't pluggable so I don't see why this would be any different :) | |
| 15:59:49 | bauzas | yeah, what dansmith said | |
| 15:59:52 | cdent | ah, sorry, I misinterpreted "I meant custom code modifying behaviour of placement" | |
| 16:00:16 | dansmith | bauzas: I will have to say, that scheduler filters and these pre-filters would be the _best_ place to introduce custom behavior if I was an operator | |
| 16:00:21 | bauzas | dansmith: you surely imagine the creativity of people using our code :) | |
| 16:00:36 | cdent | presumably the only way to modify placement is by sending different queries and creating various entities. in which case it's not "custom" is it? | |
| 16:00:39 | dansmith | because placement is a solid interface and all this is doing is augmenting how we call it | |
| 16:00:42 | cdent | it's what it's for | |
| 16:00:47 | dansmith | cdent: exactly my point | |
| 16:00:50 | bauzas | the scheduler base filter is an external interface | |
| 16:01:01 | cdent | yay, agreeing with dan is fun | |
| 16:01:27 | bauzas | what would be the base pre-filter isn't an external interface and I'd vote -2 on any change that would open that | |
| 16:01:57 | dansmith | bauzas: why do you think the scheduler filters are an external interface? | |
| 16:02:09 | bauzas | dansmith: because it's pluggable :) | |
| 16:02:28 | bauzas | shit, meeting | |
| 16:02:29 | dansmith | bauzas: we don't load them externally anymore right? | |
| 16:02:46 | bauzas | oh hell, we still do that alot | |
| 16:02:54 | bauzas | unless I missed the bus | |
| 16:03:09 | bauzas | and cutting that flexibility would be a huge thing | |
| 16:03:11 | dansmith | where is the loading code for that? | |
| 16:03:37 | bauzas | sec | |
| 16:04:13 | dansmith | either way, the spec says I'm not even adding a list of pre-filters, but making each one a semantic config toggle | |
| 16:04:14 | dansmith | so it should be pretty clear we're not adding a new external interface here :) | |
| 16:04:57 | bauzas | dansmith: https://docs.openstack.org/nova/latest/user/filter-scheduler.html?#writing-your-own-filter | |
| 16:05:39 | dansmith | ah, I thought we removed the classloading from available_filters | |