Open Stack

Sorry for the confusion..

I have moved the wiki page to:
https://wiki.openstack.org/wiki/InstanceGroupApiExtension
and the blue print to:
https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension

Thanks,
Senhua


On May 8, 2013, at 3:07 PM, Matthew Sherborne <msherborne at gmail.com<mailto:msherborne at gmail.com>> wrote:

I think it should be renamed 'instance groups' or 'instance aggregates' to be more explicit.

When I started reading I was thinking 'group of users' :)


On Wed, May 8, 2013 at 6:30 AM, Senhua Huang (senhuang) <senhuang at cisco.com<mailto:senhuang at cisco.com>> wrote:
The wiki page for this proposal:
https://wiki.openstack.org/wiki/GroupApiExtension

It is almost a direct copy of the Google Doc.

Feel free to edit it.

Thanks,
Senhua

On May 7, 2013, at 10:46 AM, Senhua Huang (senhuang) <senhuang at cisco.com<mailto:senhuang at cisco.com>> wrote:

Hi all,

At the summit a few weeks ago, we (Gary Kotton, Gilad Zlotkin, Alex Glikson, I and a few other Nova developers) were talking about group scheduling, cross-project scheduling and so on. As a first step towards these long term goals, we have been working on an API extension to Nova that achieves the following goals:

  *   to allow tenants to create a "group", which defines the desired relationship among all the members within this group
  *   to allow tenants to add VM instances to an existing group
  *   to allow tenants to remove a VM instance from an existing group
  *   to allow tenants to specify policies (e.g., anti-affinity, network-proximity, rack-aware) that apply to the group
  *   to allow tenants to view/list/describe a particular group
  *   to allow tenants to remove a group

In essence, "group" defines the relationship among individual instances. You can think of it as the hyper edge with properties in a hyper graph in the most abstract manner. There are several benefits of introducing this additional construct:

  *   it is more intuitive to use than padding various hints to every related instance creation call (now the relationship among these instances are handled by "group"
  *   it makes easier to add scheduling algorithms that attempt to place a set of VM instances to achieve failure resilience, redundancy, topology-wareness and so on.

Gary, Alex, and I have put together an initial design doc on the API and how to use it for group scheduling:
https://docs.google.com/document/d/1QUThPfZh6EeOOz1Yhyvx-jFUYHQgvCw9yBAGDGc0y78/edit?usp=sharing

A related blue print is also created for Nova:
https://blueprints.launchpad.net/nova/+spec/group-api-extension

We'd appreciate your feedback on the API and blue print and in particularly whether there are interesting potential use cases that can/cannot be supported by this API extension.


Thanks,
Senhua
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/063f7aa2/attachment.html>