SkyDNS support for etcd version 3?
fbdlampayan opened this issue · 15 comments
Hi!
Does skyDNS currently support etcdv3?
If it doesn't... Would it be possible to have an optional parameter passed during its startup?
That way, say, by default it supports the original etcd backend, but with the additional parameter it would support the new etcd version 3.
@fbdlampayan basically if we support etcd v3, we will support both etcd v3 and v2.
Hi!
@adohe Yes that is true.
As far as I understood, etcdv3 storage "coexists" with v2, in a paralllel but separate manner.
So does skyDNS now support etcd v3?
[ Quoting notifications@github.com in "Re: [skynetservices/skydns] SkyDNS ..." ]
Hi!
@adohe Yes that is true.
As far as I understood, etcdv3 storage "coexists" with v2, in a paralllel but separate manner.So does skyDNS now support etcd v3?
don't know about etcd2/3 storage, but skydns uses the etcd client, so
communicating with etcd should work regardless of v2/v3
hi
the interface towards etcd changed between v2 and v3, so new backend is needed if v3 etcd was to be supported.
Is such change planned, or can be proposed for skydns?
thanks
gergo
[ Quoting notifications@github.com in "Re: [skynetservices/skydns] SkyDNS ..." ]
hi
the interface towards etcd changed between v2 and v3, so new backend is needed if v3 etcd was to be supported.Is such change planned, or can be proposed for skydns?
Nothing is planned, but sure, v3 support should be added to skydns.
/Miek
Miek Gieben
[ Quoting notifications@github.com in "Re: [skynetservices/skydns] SkyDNS ..." ]
hi
the interface towards etcd changed between v2 and v3, so new backend is needed if v3 etcd was to be supported.Is such change planned, or can be proposed for skydns?
doesn't sound hard though: https://github.com/coreos/etcd/blob/master/Documentation/op-guide/v2-migration.md
Might take some work to neatly integrate it all.
/Miek
Miek Gieben
@miekg actually etcd v2/v3 use different wire protocol, so we may need a backend storage factory, thus we can support both v2 and v3.
our initial idea was to have a parameter to define which version to use, so skydns once started, would only support one api version.
sthing like an additional parameter at startup would define the etcd api version to be used, based on which the v2 or v3 etcd client and backend would be instantiated
the backend would implement the new v3 api.
another issue is that unfortunatelly new etcd release is needed for the ttl retrieval, so we need to wait this release: etcd-io/etcd#6321
how could this dependency ( from etcd version), be handled in skydns ( meaning skydns etcd v3 backend can be used only with this given etcd version) ?
@GergoBota I understand what you mean, adding an additional parameter to determine the storage version. I will open a PR asap.
hi, ok thanks.
i imagine "storage version" will mean using coreos/etcd/clientv3 in backends, and thus have full v3 support in skydsn
Getting ttl, lease time from etcd will not be available until the mentionned etcd fix, how do you plan to handle that? is it ok to have maybe a hardcoded default value, than when etcd support is there, this part will be adjusted?
thanks
hi @adohe
we might also have a solution for this, not sure what are the plans about your PR, when it could be published or if we could, should we propose our solution; what do you think? thanks
If I am reading this correctly, skydns will not work with etcd +v3.0 and v2.3 should be used instead at least until #308 is merged?
I just tried with a v3 setup and this didn't work. Entries would not get registered in etcd.