Hi Paul! On 02/02/2016 11:49 AM, Paul Angus wrote: > Project: Trillian
Awesome! > We use Ansible to deploy > and configure all aspects of the build as this will greatly lower the > barrier to entry for independent testers. Perfect timing, just released some ansible cloudstack modules you might be interested in: * cs_pod * cs_cluster * cs_zone * cs_configuration * cs_resourcelimit These will (pretty sure) show up in Ansible 2.1. You find them here https://github.com/resmo/ansible-cloudstack for use in Ansible 2.0 Currently working on: * cs_physical_network * cs_host * cs_snapshot * cs_*_offering I would be interested in "what you need" the most to get the work done. > We use CloudStack to provision the management server and virtualised > (nested) hosts on the physical hosts. We are creating Ansible playbooks > and roles which can: > > 1. Create guest instances using Rene’s Ansible 2.0 CloudStack My 5 minutes of fame :) So you create "virtualized cloudstack hosts" by using cs_instance? Neat! > Using virtualised test environments, we can have multiple test scenarios > running concurrently. To do this we have found that it is necessary to > create pools or ranges of VLANs and IP addresses and allocate them to > environments. So for any given physical environment which will be used > for testing in, we take the total range(s) of IPs and VLANs available > and carve them into non-overlapping chunks suitable for concurrent use > as mgmt, public and guest networks. These are stored in a MariaDB > database. When a range is being used in a testing environment, that > range is marked as ‘inuse’ in the database. When creating a test > environment, Trillian looks in the database for the next available VLAN > range, the next available public IP range and so on. The returned > values are used to populate a Marvin cfg file which in turn will be used > to both build the environment and when running the Marvin testing. When > the virtualised infra is cleaned up, the database will be updated to > reflect that the used ranges are available again. Thinking a bit further (not knowing anything of your current implementation plan and work) I could image a little web service application for making the "reservations" and getting configs of vlan and networks. In combination of ansible which can just "consume" the web service's api get get all the configs in json format using built in ansible's include_vars or by --extra_vars. At the end of the playbook, a final task could "reset" the configuration on the webservice making a http request by using the "uri" module. http://docs.ansible.com/ansible/uri_module.html
