#Simple OpenStack Collaboration Day Recap

May 21, 2015 by Greg DeKoenigsberg

Untitled_designWe were excited to announce our Simple OpenStack Initiative earlier this week which kicked off with our Collaboration Day in Vancouver at the OpenStack Summit.

The weather, the setting and the conference overall have been just fantastic. I wanted to recap some of the discussions we had in during our collaboration day as it was the perfect jumpstart to this already great week.

We had solid participation from across the board -– networking and hardware leaders, consultants, cloud providers, etc. -- and it reinforced to me how much interest there is in Ansible, and how many angles there are to consider while trying to remain true to our mission of simplicity.

Ansible’s goal is to help everyone move faster to make OpenStack more viable. We really don’t have a horse in the race; we are not in the business of betting on who will get there first, or better.  We just want OpenStack to work, for all of us.

There were two high-level themes to the day --  undercloud and overcloud -- and lots of listening, learning and active discussions.

The Undercloud Discussion: OSAD and friends

Kevin Carter of Rackspace, PTL of the OS-Ansible-Deployment (OSAD) project, opened the day with an overview of OSAD.  

OSAD was originally built by Rackspace as the Ansible-LXC-RPC project to handle deployments of Rackspace private clouds. Over the past year, Kevin and team have done a lot over the past year to abstract out the Rackspace-isms to make the project more broadly applicable to all OpenStack users.

The raw notes from the session can be found on Etherpad.  

Some key takeaways:

  • Although OSAD was built primarily for production use at scale, it also scales down quite well; the All-In-One implementation of OSAD, which can run on a single machine, can be set up from scratch in an about an hour, and may be a viable alternative to projects like Devstack.

  • OSAD can accept a lot of variables for building a cloud, and not all of those variables are well-documented. The OSAD team will continue to document these parameters to make it easier to build highly customized clouds.

  • The OSAD model is based on thick containers using LXC. Another notable project, the Kolla project from Cisco, uses thin containers based on Docker. We discussed the differences in approach, and explored the possibility of allowing OSAD to add thin Docker containers as a deployment option. No conclusions yet, though.

  • OSAD was built to run on Ubuntu; participants want it to be capable of working with other distros. Seems like a simple lookup plugin to map package names across distros, and the Ansible team agreed to work on this plugin.

  • Networking continues to be generally challenging to set up in general, and a follow-up session is in order to figure out how Ansible can help with these issues.

  • It was agreed that more reference implementations would be broadly useful, and that these implementations could be worked on by a wide variety of participants. This could be a worthwhile focus of community activity.

  • Upgrades will be a key capability of OSAD going forward, with the ability to perform upgrades built into the Ansible playbooks themselves. The Liberty cycle will provide great opportunities to test these capabilities.

More details to come on this soon -- but it’s clear that a lot of people across a lot of organizations are already looking at OSAD as a great choice for standing up their own OpenStack clouds.

The Overcloud Discussion: Ansible OpenStack Modules

After a much needed break, Monty Taylor of HP led us into a great discussion about the Ansible modules, which are intended to help users with automation of tasks in their OpenStack clouds.

Because the Ansible modules live outside of the OpenStack system itself, one of the critical challenges is making sure that the Ansible modules for OpenStack are well tested -- so much of the discussion was about how to incorporate Ansible module testing directly into the OpenStack infrastructure project. Fortunately for us, Monty is both one of the leading developers of Ansible modules and the guy who runs a lot of OpenStack’s testing infrastructure. We quickly came up with some straightforward ideas for integrating these modules into OpenStack’s testing infrastructure, and we’ll be moving forward with these ideas in the coming weeks.

The other key issue is addressing the module backlog. Ansible includes hundreds of modules, and we take great care to ensure that these modules are as good as they can be -- but the honest truth is that we are not the experts about OpenStack. We had a productive discussion about enabling more members of the OpenStack community to contribute more directly to the maintenance of the core OpenStack modules in Ansible.  We are committed to recruiting more members of the OpenStack community to help manage the Ansible OpenStack modules. More about this soon.

It was thrilling to get together such a great crowd of collaborators for our first OpenStack Summit.  Thank you to everyone who showed up, jumped in and rolled up their sleeves.  More to come soon, but know we will be pushing out content and training over the next few months to help drive the Simple OpenStack Initiative.
Share:

Topics:
Cloud Automation


 

Greg DeKoenigsberg

Greg DeKoenigsberg Greg is the Director of Ansible Community with Red Hat, where he leads the project's relationship with the broader open source community. Greg has over a decade of open source advocacy and community leadership with projects like Fedora and One Laptop Per Child, and on the executive teams of Red Hat Ansible and of open source cloud pioneers Eucalyptus Systems. Greg lives in Durham NC and is on twitter at @gregdek.


rss-icon  RSS Feed