We're interested in topology support in order to support placement locality (to optimize task placement in ensembles). Vish and I started talking about what would be needed a few months ago, and came up with two approaches that would work: - modelling the system as a full graph (ie rich enough topology information in order to represent orthogonal concerns, like power and network, for example) - a limited approach where location was described through a feature vector that could be used for determining group diameter, which could be in turn used to compute group affinity and dispersion.
We're also beginning to think about trying to expose network topology upwards for scheduling as well. When you are interested in full topology, you can't take any shortcuts, so I think that we're stuck with a full graph for this. It definitely makes sense to have a well maintained, flexible single definition of this data that can be used everywhere. -nld
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
