| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 14:12:12 | bauzas | mriedem: that's why I asked for questions about why people want custom drivers | |
| 14:12:17 | bauzas | mriedem: not filters | |
| 14:12:54 | bauzas | mriedem: my main point would be that nova would only pass to the scheduler driver hosts that are supported by placement | |
| 14:12:55 | mriedem | i can see it's going to take me awhile to get all of this shit off my shoe that i stepped into yesterday | |
| 14:13:12 | sean-k-mooney | mriedem: i agree with jay that placement should not make scheduling decision but instead return a list of candiates that a scheduler then claims from. the filter schedueler is a good default but it may not be smart enough to cover all usecases | |
| 14:13:26 | bauzas | mriedem: how then the scheduler driver would return a destination between all those supported hosts is possibly something custom | |
| 14:13:38 | mriedem | sean-k-mooney: what does a custom driver buy you that custom filters can't? | |
| 14:14:53 | sean-k-mooney | mriedem: the abblity to intergrate with external inventory systems in addtion to placement to make a desission. i may not like the design of ONAP but in there model they own all inventory resources which is a conclift with how nova works today | |
| 14:15:12 | bauzas | mriedem: I thought about something | |
| 14:15:28 | bauzas | mriedem: what if we would pass a new choice named 'custom' | |
| 14:15:55 | bauzas | mriedem: that would mean that if you choose 'custom', then you need to modify setup.cfg to add a 'custom' entrypoint | |
| 14:15:59 | mriedem | sean-k-mooney: still, you can't do that in a filter? | |
| 14:16:00 | sean-k-mooney | bauzas: i like the idea of tighing the contract for scheduler drivers for queens on to requried them to support placement. | |
| 14:16:17 | openstackgerrit | Sean Dague proposed openstack/nova master: Ironic: Support boot from Cinder volume https://review.openstack.org/215385 | |
| 14:16:29 | bauzas | sean-k-mooney: you can call external inventory systems within a filter | |
| 14:16:53 | bauzas | sean-k-mooney: that said, it will call N times the 3rd party system, N being the number of hosts | |
| 14:17:05 | edleafe | mriedem: sean-k-mooney: like the way that TrustedFilter can call out? | |
| 14:17:10 | bauzas | that's the only limitation of that within a filter | |
| 14:17:18 | bauzas | edleafe: shhhhhttttt | |
| 14:17:25 | mriedem | edleafe: yes that or the attestation filter | |
| 14:17:28 | mriedem | or did i just make that up | |
| 14:17:32 | bauzas | edleafe: I *really* *hate* TrustedFilter | |
| 14:17:39 | bauzas | because it's in tree | |
| 14:17:45 | edleafe | bauzas: me too, but it's "in-tree" :) | |
| 14:17:47 | sean-k-mooney | edleafe: yes that is one example where it needs to talk to an atestation server. | |
| 14:17:58 | bauzas | mriedem: attestation server = silly TrustedFilter | |
| 14:18:13 | mriedem | oh yes | |
| 14:18:23 | mriedem | trusted filter is gone in queens | |
| 14:18:26 | mriedem | so don't complain too much | |
| 14:18:29 | sean-k-mooney | mriedem: bauzas i could do most of this with a costom filter + costum weigher to update the external inventory system with the final choice | |
| 14:18:54 | mriedem | i'd argue the custom external inventory system should be pumping custom resource class information into placement | |
| 14:18:58 | mriedem | which the filter scheduler can then use | |
| 14:19:15 | edleafe | mriedem: that would be best | |
| 14:19:25 | bauzas | hangout time ? | |
| 14:19:32 | edleafe | mriedem: but not always feasible | |
| 14:19:40 | sean-k-mooney | bauzas: the trusted filter today dose not vaildate that the plathfrom trust is still present just that you labled it as such. with the atestation server it dose a mesuared boot and attest the trust is still valid | |
| 14:19:42 | bauzas | I really wanted to explain my thoughts but my brain translates too slow | |
| 14:20:02 | bauzas | so I hope my thoughts could be clearer if I would voice | |
| 14:20:09 | mriedem | i can't spend all morning on this, so if there is further discussion we should probably move it to the ML | |
| 14:20:21 | bauzas | to make it clear, thoughts are : | |
| 14:20:28 | mriedem | i'll mark that bug as rc potential though since i think we need to handle it somehow | |
| 14:20:34 | bauzas | 1/ placement for all drivers | |
| 14:20:47 | mriedem | nack to 1 | |
| 14:20:50 | mriedem | you can't enforce it | |
| 14:21:02 | bauzas | I'd love to | |
| 14:21:20 | mriedem | bauzas: just start a ML thread | |
| 14:21:22 | bauzas | placement would give to the driver which hosts to schedule | |
| 14:21:22 | sean-k-mooney | bauzas: mriedem i can support my usecase with costome filter and weighers but a custom self contaitned driver just seemed cleaner so dont block on this cleanup on my account | |
| 14:21:26 | mriedem | and we'll bikeshed to exhaustion there | |
| 14:21:39 | sean-k-mooney | dansmith: mriedem i just wanted to hilight that there may be usecase implications that would be limited | |
| 14:21:51 | sean-k-mooney | bauzas: ^ not dansmith | |
| 14:21:53 | mriedem | sean-k-mooney: honestly anyone that wants that level of custom is just going to carry a patch to revert the change to break the entrypoint anyway | |
| 14:21:59 | bauzas | how the driver is choosing between hosts (either by looping over filters or doing at once a choice) is left to the internals of the driver | |
| 14:22:36 | bauzas | like, ChanceScheduler should just random.choice() between what's passed by placement, that's it | |
| 14:22:48 | gibi | jaypipes: asking for MAGIC only leads to HTTP 500 with a stack trace: http://paste.openstack.org/show/615732/ | |
| 14:23:17 | bauzas | but having ChanceScheduler having a different list of hosts from FilterScheduler seems to me very wrong | |
| 14:23:24 | jaypipes | gibi: aha! :) that's the source of the issue I think | |
| 14:23:25 | sean-k-mooney | mriedem: ya probably but for interop reason it would be nice if they did not need too. | |
| 14:23:31 | jaypipes | gibi: cdent fixed that bug. | |
| 14:23:40 | jaypipes | gibi: one sec, grabbing link to patch for you to apply. | |
| 14:23:49 | gibi | jaypipes: thanks | |
| 14:23:55 | gibi | jaypipes: sounds good | |
| 14:24:00 | mriedem | sean-k-mooney: if you have a custom out of tree scheduler driver, there is no interop guarantee | |
| 14:24:03 | bauzas | how a scheduler driver works should be a blackbox, but inputs of that blackbox should necessarly be identical between all drivers | |
| 14:24:08 | mriedem | sean-k-mooney: so it makes no difference imo | |
| 14:24:11 | sean-k-mooney | mriedem: the other way to solve this is to allow claims against placement api resouces to be passed as part of the nova boot and have a filter that will use those claimes for the placement. | |
| 14:24:23 | jaypipes | gibi: try this out: https://review.openstack.org/#/c/484162/ | |
| 14:24:23 | bauzas | mriedem: no, you could interop if you decide between the same hosts | |
| 14:24:37 | sean-k-mooney | mriedem: yes that is true | |
| 14:24:45 | gibi | jaypipes: OK, I will report back soon | |
| 14:24:48 | jaypipes | btw, mriedem and dansmith, https://review.openstack.org/#/c/484162/ is a good fix (and important one) | |
| 14:24:53 | bauzas | mriedem: what I think people want is crazy foos of decision making based on weather or name of my pants | |
| 14:25:07 | mriedem | jaypipes: starred | |
| 14:25:14 | dansmith | bauzas: that was impressively unintelligible | |
| 14:25:39 | bauzas | dansmith: isn't the intent ? :) | |
| 14:26:04 | dansmith | bauzas: I dunno, I just saw that notification pop up and noticed not all those words belong together | |
| 14:26:11 | bauzas | everyone wants their blackbox for deciding which kid they have is the best | |
| 14:26:16 | dansmith | if that was the intent, then.. bravo :) | |
| 14:26:37 | bauzas | the real problem is that the list of kids is depending on the blackbox | |
| 14:26:52 | sean-k-mooney | bauzas: mriedem basically for the ONAP case when a host is selected and resouce allocated they need to relay that up into there own invetory system also. i think today they do that via connectin directly to the nova db. | |
| 14:27:24 | bauzas | sean-k-mooney: sure, but my point is that the input you should get should only hosts that placement agrees with | |
| 14:27:37 | sean-k-mooney | bauzas: yes i agree with that too | |
| 14:27:49 | bauzas | sean-k-mooney: like, you should never choose between hosts that don't have resources for the asked flavor | |
| 14:28:00 | sean-k-mooney | bauzas: yes | |
| 14:28:09 | bauzas | sean-k-mooney: that's how we guarantee interop | |
| 14:28:13 | bauzas | a flavor is an interop thing | |
| 14:28:49 | bauzas | so whatever the decision system is doing, you as a user will be sure that your instance will be on a host that can support X CPUs, Y RAM and Z disk | |
| 14:29:06 | bauzas | the rest is left to you | |
| 14:29:26 | sean-k-mooney | bauzas: so as i said there are way to supprot them if they need it without a costom driver. i just dont know how many people have already used the plugable interface that would be effect by the bug. | |
| 14:29:48 | bauzas | you could decide to pick host A against B and C because you're Saggitarian if you wish | |
| 14:30:07 | dims | mriedem : i had a cleanup from looking at castellan, do we want to do that now or when queens opens up? https://review.openstack.org/#/c/484036/ | |
| 14:30:10 | bauzas | that's why I turned my choice | |
| 14:31:09 | mriedem | alex_xu: i replied in https://review.openstack.org/#/c/469800/ | |
| 14:31:19 | mriedem | dims: that conflicts with a change that kfarr did | |
| 14:31:25 | mriedem | did you see that? | |
| 14:31:35 | dims | oops checking | |
| 14:31:42 | mriedem | dims https://review.openstack.org/#/c/439855/9 | |
| 14:32:10 | dims | mriedem : kfarr's works! looking deeper | |
| 14:32:43 | sean-k-mooney | jaypipes: hehe i need to figure out how to integreate weechat with spell also a git hook for same | |
| 14:33:04 | jaypipes | sean-k-mooney: :) | |