[openstack-dev] [designate] Status of the project

Hayes, Graham graham.hayes at hpe.com
Fri Feb 10 19:28:32 UTC 2017


On 10/02/17 19:11, Joshua Harlow wrote:
> Fox, Kevin M wrote:
>> I'd say kube-dns and designate are very different technologies.
>>
>> kube-dns is a service discovery mechanism for kubernetes intend to provide internal k8s resolution. The fact it uses dns to implement service discovery is kind of an implementation detail, not its primary purpose. There's no need for private dns management, scaling past the size of the k8s cluster itself, etc. A much easier problem to solve at the moment.
>>
>> Designate really is a multitenant dns as a service implementation. While it can be used for service discovery, its not its primary purpose.
>>
>> I see no reason they couldn't share some common pieces, but care should be given not to just say, lets throw out one for the other, as they really are different animals.
>>
> 
> Arg, the idea wasn't meant to be that (abandon one for the other), but 
> just to investigate the larger world and maybe we have to adapt our 
> model of `multitenant dns as a service implementation` to be slightly 
> different; so what..., if it means we get to keep contributors and grow 
> a larger community (and partner with others and learn new things and 
> adopt new strategies/designs and push the limits of tech and ...) by 
> doing so then that's IMHO good.
> 

Sure - we are always open to changing out outlook.

There are however huge differences in the problem set between running
authoritative DNS, and service discovery DNS.

In service discovery, you want instant and consistant updates of
records, and is a single user environment - only one user will ever
query those DNS servers. As a result, you are not as resource
constrained when writing the DNS server, and can use slower data
storage systems (like etcd).

Authoritative DNS is accessed by multiple users, and resources per
request really do matter (this is part of the reason we do not have
a user facing DNS server as part of Designate).

The vast majority (all?) of the new DNS projects (especially in the
CNCF) are focused on Service Discovery. It is usually assumed the IaaS
underneath (AWS, Azure etc) have an auth DNS service available to use
(much like VMs are).

Because of this, I do not see a huge amount we can leverage from others,
or a huge amount we can offer others.

>> Thanks,
>> Kevin
>> ________________________________________
>> From: Jay Pipes [jaypipes at gmail.com]
>> Sent: Friday, February 10, 2017 9:50 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [designate] Status of the project
>>
>> On 02/10/2017 12:21 PM, 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).
>>>
>>> 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).
>>>
>>> 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)?
>>
>> This is already basically what Designate *is today*.
>>
>> http://docs.openstack.org/developer/designate/support-matrix.html
>>
>> Just because something is written in Golang and uses etcd for storage
>> doesn't make it "better" or not NIH.
>>
>> For the record, the equivalent to Designate in k8s land is Kube2Sky, the
>> real difference being that Designate has a whole lot more options when
>> it comes to the DNS drivers and Designate integrates with OpenStack
>> services like Keystone.
>>
>> Also, there's more to cloud DNS services than service discovery, which
>> is what SkyDNS was written for.
>>
>> best,
>> -jay
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list