<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 May 2016 at 19:59, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span>
So I guess its like the following (correct me if I am wrong):<br>
<br>
openstack-ansible<br>
-----------------<br>
<br>
1. Sets up LXC containers from common base on deployment hosts (ansible here to do this)<br>
2. Installs things into those containers (virtualenvs, packages, git repos, other ... more ansible)<br>
3. Connects all the things together (more more ansible).<br>
4. Decommissions existing container (if it exists) and replaces with new container (more more more ansible).<br>
5. <<profit>><br></blockquote><div><br></div><div>Almost.</div><div><br></div><div>As OpenStack-Ansible treats the LXC containers like hosts (this is why OSA supports deploying to LXC machine containers and to VM's or normal hosts) we don't replace containers - we simply deploy the new venv into a new folder, reconfigure, then restart the service to use the new venv.</div><div><br></div><div>To speed things up in large environments we pre-build the venvs on a repo server, then all hosts or containers grab them from the repo server</div><div><br></div><div>The mechanisms we use allow deployers to customise the packages built into the venvs (you might need an extra driver in the neutron/cinder venvs, for instance) and allow the OpenStack services to build directly from any git source (this means you can maintain your own fork with all the fixes you need, if you want to).</div><div><br></div><div>With OpenStack-Ansible you're also not forced to commit to the integrated build. Each service role is broken out into its own repository, so you're able to write your own Ansible playbooks to consume the roles which setup the services in any way that pleases you.</div><div><br></div><div>The advantage in our case of using the LXC containers is that if something ends up broken somehow in the binary packages (this hasn't happened yet in my experience) you're able to simply blow away the container and rebuild it.</div><div><br></div><div>I hope this helps. Feel free to ping me any more questions.</div><div><br></div><div>---</div><div>Jesse</div><div>IRC: odyssey4me</div></div>
</div></div>