This session will include the following subject(s):
Scheduling across nova/cinder/networking:
The goal is to be able to schedule resources across nova/cinder/networking efficiently. A simple example could be the 'boot from volume' scenario, when it would be highly desirable to make sure that the instance and the volume reside "close enough", as reflected by the underlying network topology (provided by OpenStack Networking, probably).
(Session proposed by Alex Glikson)
Unified resource placement for OpenStack:
Background:
The current Nova scheduler does not take into account the connectivity request among a bunch of VMs (bundled VMs) neither the physical topology. For example, there is no API that allows users to specify that all VMs should be placed in compute nodes that are not more than 2 hops away with at least 50Mbps residual bandwidth available on the path connecting these two VMs. Even though with current scheduler APIs, users could specify the exact hosts to place the VMs to achieve certain network affinity. But this requires very detailed physical topology information which might not be available to tenants. Another example is that the block storage manager (nova-volume or Cinder) currently selects nodes randomly. This could cause unnecessary load on network as well as latency to the application.
How to address these problem:
Ideally, a higher level manager should be developed to oversee and coordinate the compute, storage, and network manager for a more efficient resource usage. Another important benefit is that tenants now can specify their requests of compute, storage, and network in a bundled manner. They should not really care about the fine grained details on how to connect their application servers and worry about competing the network and storage resources with other tenants. There have been a lot of interests in this area (See for example https://etherpad.openstack.org/the-future-of-orch).
Goal of this session: This session should serve as a good venue to discuss the problem definition, the related blue prints, potential solutions, pitfalls we want to avoid and the timeline to implement a sound placement module for OpenStack. We should also discuss whether we should separate the workflow management from the resource (node) selection for better modularity.
