On Wed, Oct 24, 2012 at 5:19 PM, Musayev, Ilya <[email protected]> wrote: > In single datacenter/zone i have many pods and many clusters to belong to > specific business units that are segregated on multiple levels ranging from > network to storage restrictions. > > For example I have 3 independent QA envs, 3 perf envs, 2 DEV, 2 LAB and 2 > prod env Each env has it's own network, set of hypervisors and storage. > > If I follow simplified AWS like logic of creating 1 zone per datacenter, > multiple pods and clusters within - I loose the ability of being granular as > to where my instance should live. > > My env is an example of typical Corp environment with many segregated envs > for various business units. > > Creating 11+ zones and matching zone to cluster is also doable but - but i > think it's not how CS was designed to be used. Instead, we would like to have > 1 Zone per major business unit or even datacenter and have some other > allocators do VM allocation. > > Hence my question on best way of achieving this. > > Thanks > Ilya > > On Oct 24, 2012, at 4:12 PM, "David Nalley" <[email protected]> wrote: > >> On Wed, Oct 24, 2012 at 4:04 PM, Musayev, Ilya <[email protected]> wrote: >>> I need more granular ability to deploy on cluster level, as deploying on >>> the ZONE level is a bit too general in a complex environment like mine. >>> >>> My logic would be as follows for now: >>> >>> listClusters - find the cluster id I need >>> listHost - used with clusterid to get the list of the hosts and get hostid >>> deployVirtualMachine - deploy a VM and define hostid to make sure VM is >>> deployed on the desired cluster. >>> >>> >>> This is certainly doable - but as you can see - there are multiple steps I >>> need to do in order to deploy on cluster level. >>> >>> Is there a simpler approach to this? >>> >>> Has anyone used allocators and what is their purpose - a usage example of >>> allocators would be great. >>> >>> As always, any feedback is appreciated. >> >> >> I understand what you are wanting to do, but not why? >> What advantage are you trying to achieve? >> >> --David >> >
If it were me I'd use a combination of domains (zones allocated to domains) and tags. (tags the hosts - and have corresponding service offerings for those tags - and then control which accounts/domains see what service offerings.) I.e. QA folks would never see a service offering for production, and thus couldn't get a machine deployed on production hardware. In this scenario you would define all of the hosts in your production cluster with a tag that matches a production service offering. Of course if you can define your allocation logic - an allocator would like be better long term solution.
