I've run into quite a few separate folks doing Ansible things with OpenStack.
I figured this thread might be good for introductions and to get those
isolated people connected. Would an ansible-openstack repo for some
mutually developed playbooks make sense?
If this did make sense, is it still appropriate to target Folsom or
should we just have a go at Grizzly?
What do people want to accomplish?
I'm happy to have a go at organizing some, and we'll be able to lend a
hand as well.
I think we have clearly the easiest tool to automate OpenStack-ey
things, and it's not really as complicated as everyone makes it out to
be -- as proved at least in part by the content Lorin has already
published.
I've run into quite a few separate folks doing Ansible things with
OpenStack.
I figured this thread might be good for introductions and to get those
isolated people connected. Would an ansible-openstack repo for some
mutually developed playbooks make sense?
If this did make sense, is it still appropriate to target Folsom or
should we just have a go at Grizzly?
What do people want to accomplish?
I'm happy to have a go at organizing some, and we'll be able to lend a
hand as well.
I think we have clearly the easiest tool to automate OpenStack-ey
things, and it's not really as complicated as everyone makes it out to
be -- as proved at least in part by the content Lorin has already
published.
I have deployed a small eight node production openstack cluster using
ansible, partly based on what Lorin has done (though months ago now) and
also the Hastexo general blog post on installing Essex. I still don't have
a great grasp of ansible best practices though, or actually openstack best
practices either. So it would be great to see what real knowledgeable users
of both do.
I agree that deploying openstack isn't the big issue people tend to make it
out to be. Certainly running a large production system isn't easy, but I've
had no problems with a small specific essex deployment.
I would be very interested in working with the latest version of openstack
and ansible and especially in a development environment, ie. running
several small virtual machines via vagrant or fusion on osx or kvm on
linux. It would be great to grab one github repo and deploy a small
openstack cluster using vagrant and ansible in a couple commands.
Also I think deploying ceph with ansible would be a good project to work on
as well, though I haven't looked if anyone has already done this.
We've had a pull request for a Ceph Facts module, which while probably
a bit niche for core, could easily be kept in this repo.
Can you put your OpenStack content on github somewhere so we can start
comparing and starting a common repo? If we have to keep seperate
Folsom and Essex directories I think that would be reasonable -- they
are quite different beasts
Jimmy Tang from Trinity College Dublin's HPC group is the one to talk
to about Ceph -- he should be on list.
We've had a pull request for a Ceph Facts module, which while probably
a bit niche for core, could easily be kept in this repo.
Can you put your OpenStack content on github somewhere so we can start
comparing and starting a common repo? If we have to keep seperate
Folsom and Essex directories I think that would be reasonable -- they
are quite different beasts
Neat, its a good starting place. I think targeting the current stable openstack release on either ubuntu or rhel6 (or centos or sl) with a set of tasks and templates to setup a small 2-3 node environment with vagrant is probably the best thing to do.
I would be interested in seeing how a more advanced ansible user would template up some of the configuration if one were to deploy lots of storage nodes or compute nodes.
Curtis do you want to setup a new repo for say something like “ansible-openstack”? if no one wants to take on the initial repo, I’d volunteer, only i’m not familar with openstack as it’s not something that we’re currently using in work.
Also there was an idea about ripping out the puppet components for packstack, but i think doing a specific ansible-openstack repo full of tasks and playbooks is more desirable.
Actually, just to skip the discussion on what to setup and how, lets just wing it for now and see what happens. Here’s a start of a repo with a vagrant file which will boot up a controller and compute vm - currently has no provisioning at all in it. It’s at least a start for pulling things together, testing and development.
It should be a generic OpenStack config where you specify the host file.
If someone wants to use Vagrant, they *can* (and just put things in
the host file), but our goal here if we want to collaborate should be
for real deployments.
It should be a generic OpenStack config where you specify the host file.
If someone wants to use Vagrant, they *can* (and just put things in
the host file), but our goal here if we want to collaborate should be
for real deployments.
What is a real deployment?
Sure, vagrant on the side, but I think being a part of the repo in some
fashion would be nice. I'll deploy many, perhaps hundreds, of times to a
virtual environment vs a small number of "real deployments" (assuming that
means hardware). My two cents anyways.
It should be a generic OpenStack config where you specify the host file.
If someone wants to use Vagrant, they *can* (and just put things in
the host file), but our goal here if we want to collaborate should be
for real deployments.
What is a real deployment?
Sure, vagrant on the side, but I think being a part of the repo in some
fashion would be nice. I'll deploy many, perhaps hundreds, of times to a
virtual environment vs a small number of "real deployments" (assuming that
means hardware). My two cents anyways.
Being part of the repo is ok, but personally I use Vmware fusion and
KVM a HECK of a lot more than VirtualBox.
I just made some of the suggested changes, the top level repo doesn't
have any vagrant stuff at all. All the vagrant related stuff for
devel/testing is inside the hacking directory.
Sourcing the hacking/env-setup bash script sets up the hosts file and
aliases ansible and ansible-playbook so that it uses the vagrant keys
and user name. The assumption is that anyone who wants to test/develop
the scripts will want to do it with vagrant. devs can choose to not
use it and do their own thing, prefer to use vagrant myself as it
keeps gives me a repeatable way of deploying a test system.
heh, yea, i just wanted to get a base system going first before i
start (or anyone else) plugging stuff in. My lack of understanding of
openstack will mean it will be a slow start.
one of the things I liked about packstack is that folks working on that
are also actively working on openstack. So, in terms of deploying
openstack they really know what they're doing. (not saying y'all don't,
of course). The idea was puppet is, imo, an extremely poor fit for
multi-system orchestration - and since packstack was already in python
I figured grafting ansible into it in place of puppet modules wouldn't
be very hard and would end up producing an output quicker.
That was the whole crux of suggesting it.
I may pursue it on my own - but I thought I'd mention it nevertheless.
I think that this is a great idea. I have built a single node OpenStack setup for Centos 6 with EPEL that mostly works (still working on understanding Quantum) which I am willing to contribute.
One thing I did is build modules to configure various OpenStack services if not already set up. However, it will not recognize if an option has changed just whether the component is present or absent. Here is an example usage:
I have attached this very rough module. I have modules for keystone_user, keystone_service, keystone_endpoint, quantum_net, quantum_subnet, quantum_router, and glance_image. Let me know if folks want it and I will clean them up and create a pull request. However it might be a while due to pressing work commitments that have drawn me away from this personal project.
I also wrote a simple openstack_config as the ini_file module did not like the DEFAULTS section in most OpenStack ini files. Its sample usage is:
name: folsom and later glance-registry config to use keystone
tags:
I just got a large chunk of the basic configuration done for a folsom controller node, i can at least go to the web interface in my test vm. I think I might let it sit for a day or so to figure out how to do the network in my test environment first. There are some choices to be made, which aren’t really a problem of ansibles; but its a question of taste and available hardware/software for setting up openstack.
