Ossipee started off as OS-IPA. As it morphed into a tool for building development clusters,I realized it was more useful to split the building of the cluster from the Install and configuration of the application on that cluster. To install IPA and OpenStack, and integrate them together, we now use an ansible-playbook called Rippowam.

Ossipee generates an inventory file, populated with two hostgroups, with one host apiece, and a set of variables necessary for installing IPA and OpenStack.

Rippowam is an Ansible playbook that picks up where Ossipee leaves off.

Here is an overview of the process that Rippowman performs.

1. Install an interal Yum Repo and upgrade all packages to their latest
2. Install IPA, including the DNS backend, KRA, and Ipsilon
3. Register the Openstack Control Node as an IPA client
4. Install RDO via packstack with the QPid backend for oslo-messaging
5. SSH enable all of the services via HTTPD configuration for Horizon and Keystone, and HA Proxy for the rest.
6. Enable Kerberos and SSSD Federation for Keystone and enable token validation via Kerberos
7. Fetch Keytabs for all of the services and convert them to validate tokens via Kerberos and Modify the service configuration files to use the V3 Keystone API
8. Enable SAML Federation (via Ipsilon) for Keystone
9. Enabled WebSSO via both mechansims for Horizon
10. Enable Kerberos for Authorization from all services to MySQL. We tried Encryption here, too, but there is a bug.
11. Upgrade Oslo Messaging to use Proton and AMQP 1.0 via the Proton Driver.
    Enable Kerberos for authorization and encryption of the oslo-messaging Broker, to include setting ACLs that only the services can communicate via the broker.

Click on the links to see the Ansible code that implements each of these features.

The ability to execute it was linked in with Ossipee. A user could either run:

./ossipee-create --section os1 rippowam

or execute the playbook directly like this:

ansible-playbook -i ~/.ossipee/deployments/ayoung.demorack/inventory.ini ~/devel/rippowam/site.yml

One thing you will notice that we don’t do is to enable the LDAP backend for Keystone to use the IPA server. The Federated services are backend by IPA. This prevents users from attempting to pass their passwords to the Keystone server; Kerberos is enabled for all authentications.

Once the deployment is up and running, end user can take advantage of IPA integration. Tow things we built upon this demo to show:

1. A Virtual machine launched via Nova gets automatically registered with the IPA server and put into a corresponding Hostgroup
2. Volumes can be encrypted with keys managed by the KRA

This was the code that set up our demonstration at the OpenStack summit in Tokyo. This is a work-in-progress.

This has been a huge team effort: Contributors were:

Jamie Lennox: Atlas, carrying the weight of this on his shoulders. A huge part of the Ansible work, master of all things with the openstack clients.
Ade Lee: Barbican
Rich Megginson: Puppet support and autoregistration of IPA clients
Robbie Harwood: Kerberos support in MySQL and an assit on QPid
Andrew Sticher: Kerberos Support in the Proton Driver
Ken Giusti: AMPQ Driver for Oslo Messaging to include Kerberos support
Rob Crittenden and John Dennis both helped clear technical hurdles while making Ipsilon work.
Nalin Dahyabhai for guidance and trouble shooting on X509, Certmonger, and Kerberos issues.

Me. I was involved in a little of each of these.

Nate Kinder, our Fearless leader and group manager that kept the engines running, including the most critical of managerial tasks: deflecting distractors.

Don’t expect to be able to run this just yet. Rippowam still uses repositories that are internal to Red Hat, both for RHEL and for OpenStack. While we were developing it, RHEL was in nightly build status. Now that it is GA, you could change the RHEL repo to one that is valid for you. I’ll update the base OS once CentOS 7.2 is GA. The OpenStack deploy is based on RDO. Again, since this was in part a QA effort, it uses repositories that are internal to make sure we were working with the specific versions of the packages that we are going to support. That said, there is nothing proprietary about where it is headed: all the code that Rippowam is already publicly available. Rippowam is confirmation of our configuration.

Rippowam is based on Packstack. While this is fine for a proof of concept deployment, the goal is to now make this work with an RDO Manager based install.