OpenStack Designate woes

The move to the more-inclusive "big tent" model for OpenStack has had some benefits for the umbrella project and many of its sub-projects. But at least one smaller project, Designate, which is a DNS as a service (DNSaaS) component, has not been thriving under that model. DNSaaS provides an API to multiple tenants in a cloud so that they can modify and update the DNS records they are using. Graham Hayes posted a lengthy message to the openstack-dev mailing list (and on his blog) that described the problems the project is having.

Hayes's "tl;dr" for the post should be worrisome to users of the component: "Designate is not in a sustainable place." The project has always been small and DNS is not seen as shiny, pretty, or cool, he said, so it doesn't necessarily attract lots of contributors. Early on, though, there were two organizations that needed DNSaaS for their public clouds, so they were willing to fund development, but things have changed:

He went on to say that one more change of corporate direction could leave Designate with no core developers who are paid to work on the project. That is a precarious state for any project, especially if no real community has built up around it as seems to be the case here. But there are other problems as well.

The big tent change, which allowed sub-projects to more easily become part of OpenStack, "was a good thing for the OpenStack project as a whole [but] it had quite a bad impact on us", he said. Effectively, much of the cross-project effort for things like documentation or QA that went into helping with integration of sub-projects prior to a release has dried up. Those teams are largely focused on the larger core sub-projects (e.g. the Nova compute component, the Neutron networking component) and simply don't have the time for the smaller projects. The Designate team had to figure out many of the pieces it needed to implement to integrate with the OpenStack-wide testing frameworks (e.g. Tempest and Grenade), which "took time from other vital things like docs, functional tests and getting designate into other tools".

Ultimately, those problems show up in the information presented in the project navigator entry for Designate, Hayes said, which makes the project less attractive to users. He ended his post with a call for help. He asked those who are using Designate in production, which is around 20% of OpenStack deployments according to user surveys, to contribute their tooling, documentation, and expertise to the project. He also would like to see more help from the cross-project teams for integrating with the other OpenStack components. The blog post also contained two photos that documented the decline of the team (from nine to four) and noted that the next project teams gathering (PTG) will only have two Designate team members present.

As might be guessed, that sparked some discussion on the list. Several thanked Hayes for posting and agreed with many of his points. Jay Pipes pointed out that the role change for the cross-project teams was anticipated by the technical committee (TC) when the big tent plan was being discussed. That meant that the focus for those teams shifted "from a 'we do this work for you' role to a 'we help you do this work for yourself' role". He also suggested that one of the best ways to help get the project back on track would be to get the documentation in good order:

Hayes, too, remembered those TC discussions, but from his perspective the "we help you" part has not really materialized. He has reached out, he said, to no avail: "[...] it can be very hard to motivate yourself to work on things when everytime you ask for help you get nothing, other than a link to the docs page you have read a 100 times". He also noted that part of the reason the Designate documentation is a mess is that the project has not figured out how to organize its documentation within the larger OpenStack documentation framework. A response from the documentation project technical lead (PTL), Alexandra Settle, seems like it may lead to a solution to the latter problem, at least.

OpenStack QA team member Andrea Frittoli noted that the team is "committed to serve every single project in [the] big tent community". The team is small, so it can't implement things for other projects, but it can help, Frittoli said. But Hayes pointed out that it is not uncommon for the QA team to simply fix problems for some of the larger project when they are encountered, while the smaller projects do not even find out about them until much later. He described an incident that happened on February 13:

The problem was caused by a bug in the Keystone authentication component, but the Designate project never heard about it until later. A simple heads-up email would have made all the difference, Hayes said. It is understandable that the QA team focuses on the core services in OpenStack, but that should not mean that the other projects in the tent get short shrift.

TC member Doug Hellmann brought up the larger issue of how to move projects from getting contributions only from interested vendors to a more sustainable community approach:

Hayes agreed with Hellmann's assessment and noted that "how we work does make things difficult for user contributors to become key contributors to a project". Just the amount of world-wide travel required to attend the PTG meetings is probably enough to put off many smaller organizations and probably all volunteers/hobbyists. That stands in contrast to other free-software projects, where an email address and a willingness to contribute can be enough to become a key player in the project.

Open-source projects that rely on a single company, or even a small set of companies, have certainly run into problems before and undoubtedly will again. For an umbrella project like OpenStack, though, that can lead to important pieces of functionality eventually falling by the wayside. There was some discussion in the thread about adopting components from other cloud projects (Kubernetes was mentioned a few times), but Hayes contends that there is no real replacement for the functionality that Designate provides. So we will have to wait and see if other users of the component will step up and provide people and resources to help the project back onto a sustainable path.