Eric Day wrote: > I agree with Vish, I think the correct approach is 3. I have some > ideas on terminology and how to think about this. A "scheduler" > should not be it's own top-level service. It should instead be a > plugin point (more like auth or db). It would plug into new service > called "kernel". Another way to look at it is s/scheduler/kernel/ > and expand kernel.
I agree (and that was my point above): with a kernel/supervisor/orchestrator top-level service, you should fold the scheduler function in it. That said, if the scheduler ends up being a plugin in the kernel/supervisor and no longer it's own top-level service, it looks to me you're advocating approach 2 (scheduler is rewrapped into some sort of supervisor), rather than approach 3 (create a compute supervisor separate from scheduler) ? -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
