Role restructuring to support target types

[ghost]

From @jonasvermeulen: ---------- Forwarded message ---------- From: Jonas Vermeulen jonas@nuagenetworks.net Date: Mon, Oct 10, 2016 at 5:28 AM Subject: Supporting different target types To: Brian Castelli brian.castelli@nuagenetworks.net, Philippe DELLAERT philippe.dellaert@nuagenetworks.net

Hi Brian,

I'm evaluating the use of metro for deploying VSD/VSC/Proxy/NSGV on top of

• OpenStack
• VMware
• AWS
• HyperV

Unfortunately I noticed the "xxxx-deploy" playbooks and associated roles have a mixture of image manipulation tasks, image deployment tasks and inside-OS installation/configuration tasks. As such, these roles cannot be reused when the target-type will be another hypervisor/cloud type.

My suggestion would be to use use pre-tasks with conditional includes to prepare the image and deployment, before calling the role. Example is at https://github.com/openstack/openstack-ansible/blob/master/playbooks/os-horizon-install.yml

Another suggestion is to

• include pre-deploy step as a pre-task
• define the actual deploy steps as a role
• include post-deploy steps as post-tasks

Philippe might have some more suggestions. At the moment it is more a structural change, not really changing any of the tasks, but it would affect the way how all files are laid out of course. So just looking to get your view, and see what you think. If you like, we can also discuss over the github Issue board so it becomes open to everyone's view.

[ghost]

from @pdellaert: ---------- Forwarded message ---------- From: Philippe DELLAERT philippe.dellaert@nuagenetworks.net Date: Mon, Oct 10, 2016 at 6:04 AM Subject: Re: Supporting different target types To: Jonas Vermeulen jonas@nuagenetworks.net Cc: Brian Castelli brian.castelli@nuagenetworks.net

For now, the first issue for image manipulation on VMware is the fact that it does not have VMware tools/Open VM tools installed, nor Cloud-init configured correctly. Resulting in an image that can not be edited easily.

I've been pressing for this with Claire and Scott, so i hope the Open VM tools get installed in R5, or at least cloud-init configured correctly for alt-cloud to be supported. With open vm tools, you can easily run command on a VM through API scripts (not sure if the vmware ansible modules support this, otherwise a simple pyvmomi script would do the trick). This seems to allow guest file operations: https://github.com/ViaSat/ansible-vsphere

With cloud-init, you have to create an ISO with a user-data.txt shell script (can be bash, python, as long as the VM has the binaries to run it), attach the iso to the cdrom of the VM (and select attach on power-on). When the VM boots, cloud-init will look for the iso, mount it and execute the script. I can provide an example script that will setup networking, hosts file, ntp, hostname, and install some basic packages (like open-vm-tools) and enable them.

Regards, Philippe Dellaert

[ghost]

My goal is to have a collection of single roles for each Nuage asset, e.g. VSD, that are smart enough to figure out the target type and deploy properly. We are currently trying to strike the correct balance between a proliferation of too many roles and the inflexibility of too few. The current compromise of using pre-, deploy, and post- roles lends itself to being able to re-run only the deploy role if there is a failure, e.g. failure to achieve ntp sync.

I don't like the current dependency on guestfish to do image manipulation. I would prefer a cloud-init solution. I have been talking to @nicolasochem about the infra team's use of cloud-init so that I can learn to use it. Any example scripts or configs that you have would be helpful.

If we follow the openstack-ansible example of using "include" for pre_tasks, how do we package the pre_task include file for delivery with the role? Put the tasks in roles/vsd/tasks alongside main.yml? Is that best practice?

[jonasvermeulen]

tags is the mechanism to limit a full playbook execution to only specific roles / tasks. It is rather straighforward, just have to be consistent. It would immediately allow you to do re-run's of a small task etc. http://docs.ansible.com/ansible/playbooks_tags.html

With respect to target_type, the biggest problem I see is that you need another Ansible module for spawning up a new VM. What I see is in the openstack-ansible project is that resource allocation is indeed done in pre_tasks. The include files are just stored in the same tasks directory, but could easily be stored in a subdirectory.

cloud-init or alike mechanisms would obviously help a lot to remove the guestfish dependency. I guess for VSD this is already nicely coming along (considering PD's comment). For VSC we should see if we can get it loaded with a standard BOF configuration. The Ansible 2.2 sros_commands will help a lot for those as well.

[pdellaert]

A very basic bash script that i have to setup the VSD image after it is booted can be found here: https://gist.github.com/pdellaert/f15479d57920d0d74172cc1424e1f8ea

This file is generated by a tool i've written quickly in bash to deploy the full Nuage stack on vSphere (3 VSD, 1 Elastic search, 2 VSC & vCenter Integration Node): http://gitlab.us.alcatel-lucent.com/pdellaer/vSphere-Deployment/blob/master/full-VSD-VSC-deployment.sh

This will deploy the VMs, configure vapp properties if appropriate, and for the VSDs (3), VCIN (1) & Elastic Search (1) vm, it generates a script like above, and creates an ISO for each VM (so 5 in total). The user has to attach these ISO's to the VMs in vCenter an boot the VMs. If Cloud-Init is enabled for Alt-Cloud, it will pickup the script, execute it and the full network, ntp and host configuration for the VMs is done. After which the master script takes over again.

Not entirely automated, but at least it helped me a lot ;)

I also heard open-vm-tools will be in the R5 release for the VSD/VCIN OVA (not yet Elastic Search), lets hope it is enabled by default, which would make it so much easier :)

[pdellaert]

Bad news, after testing both VSD OVA images (RHEL and CentOS):

• No open-vm-tools installed
• Cloud-init does not support alt-cloud

So fully automating OVA deployments is, for now, impossible

[jonasvermeulen]

Did a first re-structuring as part of #14 next step is to add VMware or OpenStack as target type.

[ghost]

With Jonas' help we have restructured. Closing this issue.