Hi Martin, I will provide some details according to what i have understood. Please correct me, if I'm wrong.
A group can consist of different kind of VMs which we called as cartridges in stratos. In that case, co-located affinity can be provided to VMs which are part of same group by providing a group level deployment policy. As you are already aware of, all the VMs which belong to that group will reside in the same partition where partition can be a host or zone. Apart from that, if you need to achieve anti-affinity, then you can define another group with set of other VMs and define deployment policy at the cartridge level. So that individual VM will be placed by referring to its own deployment policy rather than looking at the group level policy. AFAIU, this is the level of Affinity aware VM colocation that we supported now. Also please note that prior to write such application and cartridge group definition, the level of affinity among different types of VM has to be identified and experimented well, since stratos currently doesn't have the capability of automatically identified the affinity aware colocation VMs. If this doesn't fit with what you have asked, can you elaborate more on your perception of the Affinity aware VM colocation? Thanks, Reka On Thu, Jul 30, 2015 at 7:21 AM, Martin Eppel (meppel) <mep...@cisco.com> wrote: > Hi, > > > > As part of our original grouping design we proposed a feature to either > co-locate or not co-locate individual VMs. > > > > Quoting from the original grouping specification: > > > > Quote begin: > *Co-Location* > > *VMs within a group will be spun up based on the model of subscriptions, > deployment policies and partitions. The model needs to be extended so that:* > > > > · *It must be possible to require VMs to be co-located on a single > host.* > > · *It must be possible to require VMs to be located in separate > zones.* > > > > Quote end. > > > > As we have some immediate needs we started looking into it and would like > to get the input from the community for the requirement / implementation > (with the idea to contribute it back to the master repository eventually). > > > > The question would be what is the current support for it (stratos 4.1) and > what are the suggestions to enhance stratos to support this enhancement ? > > > > Any other ideas or considerations on how to support the enhancement ? > > > > Thanks > > > > Martin > -- Reka Thirunavukkarasu Senior Software Engineer, WSO2, Inc.:http://wso2.com, Mobile: +94776442007
