| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-17 | |||
| 14:41:59 | cdent | seems a reasonable practice, although I've always assumed that while placement would always be independent, it would have as clients lots of different "things that do filtering" (including nova-scheduler) | |
| 14:42:33 | edleafe | cdent: oh definitely for placement, since we got to create it separately | |
| 14:42:53 | bauzas | edleafe: no, we clearly said during Forum that while placement could be eventually independent, scheduler is a nova-ism | |
| 14:42:55 | edleafe | I'm wondering if we're giving up on the notion of the scheduler ever being useful for anything besides nova | |
| 14:43:19 | bauzas | edleafe: at least jay told that in his presentations | |
| 14:43:50 | cdent | I think maintaining a strong contractual boundary is always good | |
| 14:43:55 | edleafe | so it was decided that every service that needs scheduling will create its own? | |
| 14:44:16 | sean-k-mooney | sfinucan: can you look at https://review.openstack.org/#/c/451049/9 the os-vif requirements file on master has conflicting with the global requirement for a while so we should probably merge this | |
| 14:44:18 | edleafe | or just that nova doesn't want to waste cycles on making that happen | |
| 14:44:23 | cdent | so I would think that the answer to your original question is "yes, we should be explicit" | |
| 14:44:30 | sfinucan | sean-k-mooney: on it | |
| 14:44:47 | bauzas | edleafe: every service could be using Placement differently | |
| 14:45:02 | edleafe | bauzas: nobody's talking about placement | |
| 14:45:03 | bauzas | edleafe: and scheduler could be a library by Queens | |
| 14:45:19 | bauzas | but that's still a nova thing | |
| 14:45:19 | sean-k-mooney | sfinucan: cool thanks, just going true my review queue which is always fun :) | |
| 14:45:43 | edleafe | I'm talking about making a change that ties the scheduler closer to nova | |
| 14:46:14 | edleafe | that we will decide to undo in N cycles because the winds have changed direction | |
| 14:50:12 | dansmith | edleafe: I think we've been on a path to keep scheduler closely tied to nova and split out placement as the generic thing, ever since placement was a thing | |
| 14:50:25 | dansmith | that's been my understanding | |
| 14:53:23 | edleafe | dansmith: so it's OK to add more things to tie them together? | |
| 14:53:56 | dansmith | to tie nova and the scheduler together? | |
| 14:54:03 | dansmith | or nova and "nova's scheduler" I should say | |
| 14:54:19 | edleafe | I think you've answered my question | |
| 14:54:23 | dansmith | heh | |
| 14:54:28 | edleafe | bleh | |
| 14:54:36 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Scheduler returning alternatives per destination https://review.openstack.org/465175 | |
| 14:54:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455 | |
| 14:54:37 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Delete existing allocations when retrying https://review.openstack.org/460433 | |
| 14:54:39 | dansmith | making the claim in the scheduler is tying them closer together right? | |
| 14:54:46 | edleafe | no | |
| 14:55:01 | dansmith | hmm, okay :) | |
| 14:55:19 | bauzas | dansmith: edleafe: just in case you're interested in, I just updated my series | |
| 14:55:39 | dansmith | bauzas: cool | |
| 14:55:40 | bauzas | working now back on the conductor change now that we have the alternatives | |
| 14:55:44 | edleafe | assuming an independent scheduler, if a service requests some resources, the scheduler would make a selection, claim the resources to ensure that nothing else uses them, and then returns the selected RP | |
| 14:56:05 | edleafe | Nothing nova-y about it | |
| 14:56:29 | bauzas | edleafe: again, like I said, we plan to make scheduler a library for Queens | |
| 14:56:44 | bauzas | so it would eventually be possible for other services to use that lib | |
| 14:56:54 | edleafe | bauzas: that seems kind of silly if only Nova can use it | |
| 14:56:54 | bauzas | but for the moment, consider it as a nova-ism | |
| 14:57:06 | bauzas | baby steps at least | |
| 14:57:13 | bauzas | ie. the plan is | |
| 14:57:19 | bauzas | 1/ claims in Pike | |
| 14:57:28 | bauzas | 2/ scheduler as a lib in Queens | |
| 14:57:33 | edleafe | bauzas: baby steps forward, while taking full steps back | |
| 14:57:49 | bauzas | 3/ conductor uses that lib for filtering/weighting in Queens/Rocky | |
| 14:58:05 | bauzas | 4/ other services could possibly be using that scheduler lib by Rocky | |
| 14:58:24 | bauzas | (c) by dansmith for the library thing | |
| 14:58:32 | bauzas | which I totally agree with | |
| 14:58:33 | edleafe | bauzas: no they couldn't, if we start tying scheduler to nova more and more | |
| 14:59:26 | edleafe | instead of getting rid of a nova-ism and making it part of the interface, we're now making scheduler more dependent on that nova-ism | |
| 14:59:38 | bauzas | edleafe: that's a truism, and I don't disagree with your statement | |
| 14:59:41 | dansmith | bauzas: no, it was johnthetubaguy's idea, I just fell in love with it | |
| 14:59:48 | edleafe | making it even less likely that any other service will ever use scheduler | |
| 14:59:58 | bauzas | what I disagree is with you saying that we go into that direction | |
| 15:00:15 | bauzas | dansmith: oops, hail to johnthetubaguy then :) | |
| 15:00:29 | edleafe | dansmith: that contradicts what you were saying earlier: that the scheduler is nova's scheduler | |
| 15:00:50 | bauzas | anyway, back to work for updating the conductor now | |
| 15:00:59 | edleafe | why do any of those steps if the end goal isn't to make it useful for other services? | |
| 15:01:01 | dansmith | edleafe: I don't want it as a library for other projects to use, I want it to be nothing but code in nova (i.e. not a service) | |
| 15:01:15 | dansmith | edleafe: because placement is the generic thing useful for other services | |
| 15:01:22 | johnthetubaguy | placement is for everyone right, and +1 what dansmith just said | |
| 15:01:48 | edleafe | ok, then let's tie scheduler to nova ever more tightly | |
| 15:02:16 | cdent | library is a bit of a misnomer, I guess? We mean something more like "module"? | |
| 15:02:21 | dansmith | cdent: yeah | |
| 15:02:37 | edleafe | cdent: yeah, "library" means generally useful | |
| 15:02:52 | cdent | library would be fun, but seems unlikely. Also, why would we replicate that confusing mass? | |
| 15:03:23 | johnthetubaguy | my think was, stop making RPC API calls to it, since it the process is no longer special, but thats a different thing | |
| 15:03:26 | edleafe | cdent: because the concept of choosing one RP over another is rather generic | |
| 15:03:29 | dansmith | edleafe: I think we've been on this "keep scheduler in nova, split out placement" path for quite a while, but I'm not sure the distinction was made explicit and given the "split the scheduler" talk before that, you're probably not the only one confused by the "plan" | |
| 15:03:45 | cdent | there could be a library for things that filter resource providers that is implemented outside of nova, using more clear techniques | |
| 15:04:02 | cdent | I think that would be useful | |
| 15:04:06 | edleafe | cdent: sure, but there was never any work even considered for that | |
| 15:04:06 | dansmith | could be, | |
| 15:04:17 | johnthetubaguy | cdent: yeah, thats a sepearate, quite interesting thing, that is a library | |
| 15:04:24 | dansmith | and you could also build a generic scheduling library that makes it clear we should dump much of what nova's scheduler does | |
| 15:04:32 | dansmith | and when you guys build that, we can evaluate :) | |
| 15:04:40 | edleafe | cdent: whereas we've spent a lot of effort on cleaning up the interface between nova and the scheduler | |
| 15:05:11 | cdent | edleafe: I still think that interface should be kept as clean and explicit as possible. That's simply good practice. | |
| 15:05:30 | edleafe | cdent: and if the scheduler were an independent library, it could be cleaned up radically, as long as the interface contract was maintained | |
| 15:05:50 | edleafe | cdent: well, that's why I started this conversation. | |
| 15:06:01 | edleafe | We're making the interface dirtier | |
| 15:06:10 | cdent | can someone point me at this dirtying? | |
| 15:06:13 | johnthetubaguy | edleafe: where? | |
| 15:06:23 | edleafe | basing the number of returned hosts on max_attempts | |
| 15:06:37 | edleafe | which is a nova-ism that we've discussed removing in the past | |
| 15:06:45 | bauzas | I would certainly appreciate reviews on my changes | |
| 15:07:17 | edleafe | IOW, any other potential user of scheduler would now get back the number of hosts that nova wants | |
| 15:07:51 | edleafe | IMO, it would be cleaner to make the number of hosts to return per request explicit | |
| 15:08:11 | edleafe | and move max_attempts out of the scheduler config | |
| 15:08:14 | johnthetubaguy | edleafe: so the retry configuration needs to be set by the operator where? | |
| 15:08:45 | edleafe | johnthetubaguy: somewhere in nova's config, not in scheduler's config | |
| 15:08:59 | johnthetubaguy | scheduler config is nova config right now, and there is no plan to change that right? | |
| 15:09:02 | edleafe | johnthetubaguy: Unless, of course, we are deciding to keep the two locked together | |
| 15:09:08 | johnthetubaguy | placement config is a totally different thing | |
| 15:09:25 | edleafe | johnthetubaguy: no plan, correct. It's been pointed out several times as something we need to change | |
| 15:09:38 | edleafe | if we want an independent scheduler | |
| 15:09:53 | cdent | fwiw, edleafe, I agree with you: the config of attempts should be outside of the nova-scheduler's domain, it should accept an arg | |
| 15:10:06 | cdent | _even_ if that code never becomes a lib | |