Re: [openstack-dev] [tc][all][designate] The way forward for Designate
It would be nice to record this discussion/summary on an etherpad or somewhere, because it's not just the problem for Designate, IMHO, many other big tent projects are facing the same issue. Thanks. On 22/02/17 09:25, Hayes, Graham wrote: > For those that are interested, we will have an hour discussion about > how designate can move forward tomorrow (wed 22nd) at the PTG. > > We will be in Savannah 3 @ 11:00 for an hour. > > Thanks, > > Graham > > On 09/02/2017 14:22, Hayes, Graham wrote: >> The HTML version of this is here: >> http://graham.hayes.ie/posts/openstack-designate-where-we-are/ >> >> I have been asked a few times recently "What is the state of the Designate >> project?", "How is Designate getting on?", and by people who know what is >> happening "What are you going to do about Designate?". >> >> Needless to say, all of this is depressing to me, and the people that I have >> worked with for the last number of years to make Designate a truly useful, >> feature rich project. >> >> *TL;DR;* for this - Designate is not in a sustainable place. >> >> To start out - Designate has always been a small project. DNS does not have >> massive *cool* appeal - its not shiny, pretty, or something you see on the >> front page of HackerNews (unless it breaks - then oh boy do people >> become DNS >> experts). >> >> A line a previous PTL for the project used to use, and I have happily >> robbed is >> "DNS is like plumbing, no one cares about it until it breaks, and then >> you are >> standing knee deep in $expletive". (As an aside, that was the reason we >> chose >> the crocodile as our mascot - its basically a dinosaur, old as dirt, and >> when >> it bites it causes some serious complications). >> >> Unfortunately that comes over into the development of DNS products >> sometimes. >> DNSaaS is a check box on a tender response, an assumption. >> >> We were lucky in the beginning - we had 2 large(ish) public clouds that >> needed >> DNS services, and nothing currently existed in the eco-system, so we got >> funding for a team from a few sources. >> >> We got a ton done in that period - we moved from a v1 API which was >> synchronous to a new v2 async API, we massively increased the amount of DNS >> servers we supported, and added new features. >> >> Unfortunately, this didn't last. Internal priorities within companies >> sponsoring the development changed, and we started to shed contributors, >> which >> happens, however disappointing. Usually when this happens if a project is >> important enough the community will pick up where the previous group >> left off. >> >> We have yet to see many (meaningful) commits from the community though. We >> have some great deployers who will file bugs, and if they can put up patch >> sets - but they are (incredibly valuable and appreciated) tactical >> contributions. A project cannot survive on them, and we are no exception. >> >> So where does that leave us? Let have a look at how many actual commits we >> have had: >> >> Commits per cycle >> >> +--+-+ >> | Havana | 172 | >> +--+-+ >> | Icehouse | 165 | >> +--+-+ >> | Juno | 254 | >> +--+-+ >> | Kilo | 340 | >> +--+-+ >> | Liberty | 327 | >> +--+-+ >> | Mitaka | 246 | >> +--+-+ >> | Newton | 299 | >> +--+-+ >> | Ocata| 98 | >> +--+-+ >> >> Next cycle, we are going to have 2 community goals: >> >> * Control Plane API endpoints deployment via WSGI >> * Python 3.5 functional testing >> >> We would have been actually OK for the tempest one - we were one of the >> first >> external repo based plug-ins with `designate-tempest-plugin`_ >> >> For WSGI based APIs, this will be a chunk of work - due to our internal code >> structure splitting out the API is going to be ... an issue. (and I think it >> will be harder than most people expect - anyone using olso.service has >> eventlet imported - I am not sure how that affects running in a WSGI server) >> >> Python 3.5 - I have no idea. We can't even run all our unit tests on python >> 3.5, so I suspect getting functional testing may be an issue. And, >> convincing >> management that re-factoring parts of the code base due to "community goals" >> or a future potential pay-off can be more difficult than it should. >> >> http://graham.hayes.ie/images/oct-2016-projects-prod.jpg >> >> We now have a situation where the largest "non-core" project [1]_ in the >> tent >> has a tiny number of developers working on it. 42% of deployers are >> evaluating >> Designate, so we should see this start to increase. >> >> How did this happen? >> >> >> Like most situations, there is no single cause. >> >> Certainly there may have been fault on
[openstack-dev] [tc][all][designate] The way forward for Designate
For those that are interested, we will have an hour discussion about how designate can move forward tomorrow (wed 22nd) at the PTG. We will be in Savannah 3 @ 11:00 for an hour. Thanks, Graham On 09/02/2017 14:22, Hayes, Graham wrote: > The HTML version of this is here: > http://graham.hayes.ie/posts/openstack-designate-where-we-are/ > > I have been asked a few times recently "What is the state of the Designate > project?", "How is Designate getting on?", and by people who know what is > happening "What are you going to do about Designate?". > > Needless to say, all of this is depressing to me, and the people that I have > worked with for the last number of years to make Designate a truly useful, > feature rich project. > > *TL;DR;* for this - Designate is not in a sustainable place. > > To start out - Designate has always been a small project. DNS does not have > massive *cool* appeal - its not shiny, pretty, or something you see on the > front page of HackerNews (unless it breaks - then oh boy do people > become DNS > experts). > > A line a previous PTL for the project used to use, and I have happily > robbed is > "DNS is like plumbing, no one cares about it until it breaks, and then > you are > standing knee deep in $expletive". (As an aside, that was the reason we > chose > the crocodile as our mascot - its basically a dinosaur, old as dirt, and > when > it bites it causes some serious complications). > > Unfortunately that comes over into the development of DNS products > sometimes. > DNSaaS is a check box on a tender response, an assumption. > > We were lucky in the beginning - we had 2 large(ish) public clouds that > needed > DNS services, and nothing currently existed in the eco-system, so we got > funding for a team from a few sources. > > We got a ton done in that period - we moved from a v1 API which was > synchronous to a new v2 async API, we massively increased the amount of DNS > servers we supported, and added new features. > > Unfortunately, this didn't last. Internal priorities within companies > sponsoring the development changed, and we started to shed contributors, > which > happens, however disappointing. Usually when this happens if a project is > important enough the community will pick up where the previous group > left off. > > We have yet to see many (meaningful) commits from the community though. We > have some great deployers who will file bugs, and if they can put up patch > sets - but they are (incredibly valuable and appreciated) tactical > contributions. A project cannot survive on them, and we are no exception. > > So where does that leave us? Let have a look at how many actual commits we > have had: > > Commits per cycle > > +--+-+ > | Havana | 172 | > +--+-+ > | Icehouse | 165 | > +--+-+ > | Juno | 254 | > +--+-+ > | Kilo | 340 | > +--+-+ > | Liberty | 327 | > +--+-+ > | Mitaka | 246 | > +--+-+ > | Newton | 299 | > +--+-+ > | Ocata| 98 | > +--+-+ > > Next cycle, we are going to have 2 community goals: > > * Control Plane API endpoints deployment via WSGI > * Python 3.5 functional testing > > We would have been actually OK for the tempest one - we were one of the > first > external repo based plug-ins with `designate-tempest-plugin`_ > > For WSGI based APIs, this will be a chunk of work - due to our internal code > structure splitting out the API is going to be ... an issue. (and I think it > will be harder than most people expect - anyone using olso.service has > eventlet imported - I am not sure how that affects running in a WSGI server) > > Python 3.5 - I have no idea. We can't even run all our unit tests on python > 3.5, so I suspect getting functional testing may be an issue. And, > convincing > management that re-factoring parts of the code base due to "community goals" > or a future potential pay-off can be more difficult than it should. > > http://graham.hayes.ie/images/oct-2016-projects-prod.jpg > > We now have a situation where the largest "non-core" project [1]_ in the > tent > has a tiny number of developers working on it. 42% of deployers are > evaluating > Designate, so we should see this start to increase. > > How did this happen? > > > Like most situations, there is no single cause. > > Certainly there may have been fault on the side of the Designate leadership. > We had started out as a small team, and had built a huge amount of trust and > respect based on in person interactions over a few years, which meant that > there was a fair bit of "tribal knowledge" in the heads of a few people, and > that new people had a hard time becoming part of the group. > > Also, due to volume of work
