On 10/02/17 17:24, Joshua Harlow wrote: > 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). >> > > Thanks for posting this, I know it was not easy to write... > > Knowing where this is at and the issues. It makes me wonder if it is > worthwhile to start thinking about how we can start to look at 'outside > the openstack' projects for DNS. I believe there is a few that are > similar enough to designate (though I don't know well enough) for > example things like SkyDNS (or others which I believe there are a few).
SkyDNS is a mechanism for service discovery, not a DNS API. In reality there is very few (if any actually - I am struggling to think of even one) multi tenant DNS management APIs. The use of DNS in clouds is more than just having an cli to call to update DNS entries. Integration's between the cloud components are what make it useful - Heat / CloudFormation / Terraform resources that can read info from network ports, floating IPs, load balancers, etc is where the value comes in. Combined with the integration in neutron that we (finally) merged recently, I think we have a compelling case to keep Designate. Ask most AWS users how much they use route53 - this is what we should be aiming for with Designate. > Perhaps we need to start thinking outside the openstack 'box' in regards > to NIH syndrome and accept the fact that we as a community may not be > able to recreate the world successfully in all cases (the same could be > said about things like k8s and others). sure - this comes back to be "base set" of services that the Arch WG were looking at. however, having coupled services can be useful, and having a guaranteed API across clouds (one of our goals afaik) for basic services (which I would count DNS as) is a big deal. > If we got out of the mindset of openstack as a thing must have tightly > integrated components (over all else) and started thinking about how we > can be much more loosely coupled (and even say integrating non-python, > non-openstack projects) would that be beneficial (I think it would)? > > -Josh > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev