John Purrier wrote: > And we are back to the discussion about orchestration... Given the > flexibility of the OpenStack system and the goals of independently > horizontally scaling services I think we will need to address this head on. > #3 is the most difficult, but is also the right answer for the project as we > look forward to adding functionality/services to the mix. This is also where > we can make good use of asynchronous event publication interfaces within > services to ensure maximum efficiency.
I can see the need for a supervisor component that will make sure that all needed resources/nodes are correctly called (currently only network+compute, but potentially more with higher-level requests using extra services). In the case of #3, could you explain what would be left for the scheduler to do ? Would it just pick the supervisor node, or just the compute node, or both ? Just trying to make sure there is a real benefit in the added complexity and that #2 is really a worse option. Regards, -- 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
