[openstack-dev] [Nova] A proposal for group API extension

Matthew Sherborne msherborne at gmail.com
Wed May 8 22:07:16 UTC 2013


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>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>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/bb4e3c64/attachment.html>


More information about the OpenStack-dev mailing list