OpenStack Project Technical Lead Interview Series #7: Gabriel Hurley, OpenStack Horizon Project
August 5, 2013
This post is the seventth of a continuing series of interviews with OpenStack Project Technical Leads on our Mirantis blog. Our goal is to educate the broader tech community and help people understand how they can contribute to and benefit from OpenStack. Naturally, these are the opinions of the interviewee, not of Mirantis.
Here the interview is with Gabriel Hurley, OpenStack Horizon Project Technical Lead.
Mirantis: Can you please introduce yourself?
Q: What is your history with OpenStack? Why do you engage?
A: I was introduced to OpenStack while working at NASA, and my skills were immediately applicable to the nascent dashboard project (which became Horizon). I have a strong personal belief in open source, so this was a natural fit. Within six months I’d hopped jobs and was working full-time on OpenStack helping to build the future of this incredibly important endeavor.
Almost two years later I’ve got commits in nearly every project and I’m a core dev on both Horizon and Keystone.
Q: What are your responsibilities as the Horizon Project Technical Lead?
A: The job is threefold: the PTL maintains the direction and high-level vision for the project; the PTL manages and engages with the community both within and outside the project; and the PTL acts as a project manager by setting priorities and timelines and making sure everyone stays on track. Ideally the PTL is also one of the most active contributors and reviewers as well, but at a minimum must have a great understanding of the codebase for their project. In the case of the Horizon PTL in particular, the largest burden lies in working across all the projects to ensure that not only is each project’s featureset well-represented in the dashboard, but also that the work the Horizon team does is not hindered by incompatible or incomplete APIs. There’s a lot of work to be done to make OpenStack feel cohesive and coherent; I strive to move that goal forward.
Q: Can you explain Horizon’s role within OpenStack? Why does Horizon matter?
A: Every time I give a presentation on Horizon I start by answering that question, and there are a few key pieces to the answer:
Horizon’s role is to be the common denominator that lets everyone come to the table. Anyone can get started with Horizon. If they’re building a business around OpenStack they are welcome and encouraged to tailor their interface to their customers’ needs, but the community as a whole has to have a Horizon.
Q: What is genuinely unique & disruptive about Horizon?
A: Our aim with the Horizon project is less about disruption and more about empowerment. We’re bringing a democratic approach to OpenStack’s cloud services, allowing all parts to be equal and supporting the greatest interoperability possible. We strive to build an experience that is both functional and compelling but that’s always a work in progress. That said, we do have some interesting things planned for Havana.
Q: What has the Horizon community accomplished so far?
A: I think the dashboard speaks for itself. We live up to our mission of supporting all the core OpenStack projects. We have worked tirelessly to produce seamless integrations between services that don’t always play nice together. We participate in the broader OpenStack community to improve all the projects and each API. We were the first to push forward with internationalization in OpenStack and continue to help lead that effort.
We’ve been the only project which can boast complete version-to-version compatibility for three releases running. We’ve grown our community every release cycle. I think we’re doing pretty well.
Q: Which capabilities will Horizon provide in the OpenStack Havanna release?
A: One of the big highlights will be integration with the two newest OpenStack projects: Heat and Ceilometer. Beyond that we’ve got complete support for the Keystone v3 API, some great new data visualizations, dynamic real-time integration with the other projects, a whole slew of capabilities exposed by new extensions to Nova, Cinder, etc., and lots more that I won’t list out here. Not to mention we’re on track for almost 200 bugs fixed by the end of the cycle.
Q: What do you wish people knew about this project?
A: The main thing that is both a benefit and source of regular confusion is that the entire dashboard is built to dynamically reconfigure itself based on the services available in your OpenStack cloud. People often come asking how to enable Quantum or Swift, what setting they need, etc. but ultimately they’re looking in the wrong place. All they have to do is add it to their service catalog in Keystone and Horizon will do the rest. What’s great is this allows Horizon to work across deployments, in multiple “regions”, etc. without any reconfiguration. As long as you built your cloud properly then you’ll have a working dashboard.
Q: What are the necessary prerequisites to get Horizon up and running properly?
A: Currently Nova and Keystone are the only services required to run the OpenStack dashboard. In terms of running the server, you need Python and a fairly standard set of modules which can be installed either via pip or using your distro of choice. No database or other persistence layer is needed in the default configuration. It comes with a built-in web server for test purposes, but for production deployments it’s best practice to put it behind a “real” web server like Apache or Nginx.
Q: Whom would you like to see contributing to Horizon?
A: I would love to involve more people who are passionate about the look and feel of Horizon. People who love CSS, responsive design, and crafting great user experiences. We’ve got lots of talented developers who work on the project, and there’s a nascent movement to get a community of designers engaged, but as of right now there’s still a lot of room to give Horizon a much more stylish and recognizable look. Something that really says “this is OpenStack”.
Q: Which functionalities need to be enhanced or tested?
A: One of the aspects we’re looking at in the Havana cycle is how to more easily let people “remix” the OpenStack Dashboard. Horizon is effectively two separate pieces: the actual “horizon” module which is a framework for building dashboards, and the “openstack_dashboard” module which contains all the OpenStack-specific implementations. We’ve spent several cycles really building out the capabilities of the framework side and making that as extensible and useful as possible for people writing code for new services and features. Now we’ve reached a tipping point, though, where people are more interested in taking what we’ve already built for Nova, Glance, etc. and tweaking it. They want to rearrange things, add hooks for their company’s particular way of doing things, that type of thing. They don’t want to start from scratch or copy-paste a giant chunk of code. So that’s our task right now: to support people in remixing what we’ve done.
Q: How can people start contributing?
A: If you’re technically-minded then download devstack and start hacking. If you’re more inclined towards visual design then get engaged with the OpenStack UX community. If you just have lots of opinions then hop on Launchpad or the mailing list and let us know. Feedback is always welcome, patches are even better, and we’re always striving to improve.
Q: Thank you, Gabriel!
A: You’re welcome.