> On Oct 1, 2013, at 3:37 PM, Michael Basnight <mbasni...@gmail.com> wrote: > >> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov <isviri...@mirantis.com> wrote: >> >> >>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson <tim.simp...@rackspace.com> >>> wrote: >>> Hi fellow Trove devs, >>> >>> With the Designate project ramping up, its time to refactor the ancient DNS >>> code that's in Trove to work with Designate. >>> >>> The good news is since the beginning, it has been possible to add new >>> drivers for DNS in order to use different services. Right now we only have >>> a driver for the Rackspace DNS API, but it should be possible to write one >>> for Designate as well. >> >> How it corelates with Trove dirrection to use HEAT for all provisioning and >> managing cloud resources? >> There are BPs for Designate resource >> (https://blueprints.launchpad.net/heat/+spec/designate-resource) and >> Rackspace DNS (https://blueprints.launchpad.net/heat/+spec/rax-dns-resource) >> as well and it looks logically to use the HEAT for that. >> >> Currently Trove has logic for provisioning instances, dns driver, creation >> of security group, but with switching to HEAT way, we have duplication of >> the same functionality we have to support. > > +1 to using heat for this. However, as people are working on heat support > right now to make it more sound, if there is a group that wants/needs DNS > refactoring now, I'd say lets add it in. If no one is in need of changing > what's existing until we get better heat support, then we should just abandon > the review and leave the existing DNS code as is. > > I would prefer, if there is no one in need, to abandon the exiting review and > add it to heat support. >
I would hate to wait til we have full Heat integration before getting Designate support, considering Heat does not yet have Designate support. My vote is to move forward with a DNS driver in trove that can be deprecated once everything works with Heat. As far as supporting only Designate, I would be fine with a driver interface that could potentially wrap Designate as well as Rax DNS. Given that both will be somewhat temporary, I don't see a reason why we have to rip out rsdns at this point. >> >>> >>> However, there's a bigger topic here. In a gist sent to me recently by >>> Dennis M. with his thoughts on how this work should proceed, he included >>> the comment that Trove should *only* support Designate: >>> https://gist.github.com/crazymac/6705456/raw/2a16c7a249e73b3e42d98f5319db167f8d09abe0/gistfile1.txt >>> >>> I disagree. I have been waiting for a canonical DNS solution such as >>> Designate to enter the Openstack umbrella for years now, and am looking >>> forward to having Trove consume it. However, changing all the code so that >>> nothing else works is premature. >> >> All non mainstream resources like cloud provider specific can be implemented >> as HEAT plugins (https://wiki.openstack.org/wiki/Heat/Plugins) >> >>> >>> Instead, let's start work to play well with Designate now, using the open >>> interface that has always existed. In the future after Designate enters >>> integration status we can then make the code closed and only support >>> Designate. >> >> Do we really need playing with Designate and then replace it? I expect >> designate resource will come together with designate or even earlier. >> >> With best regards, >> Ilya Sviridov >> >>> >>> Denis also had some other comments about the DNS code, such as not passing >>> a single object as a parameter because it could be None. I think this is in >>> reference to passing around a DNS entry which gets formed by the DNS >>> instance entry factory. I see how someone might think this is brittle, but >>> in actuality it has worked for several years so if anything changing it >>> would introduce bugs. The interface was also written to use a full object >>> in order to be flexible; a full object should make it easier to work with >>> different types of DnsDriver implementations, as well as allowing more >>> options to be set from the DnsInstanceEntryFactory. This later class >>> creates a DnsEntry from an instance_id. It is possible that two deployments >>> of Trove, even if they are using Designate, might opt for different >>> DnsInstanceEntryFactory implementations in order to give the DNS entries >>> associated to databases different patterns. If the DNS entry is created at >>> this point its easier to further customize and tailor it. This will hold >>> true even when Designate is ready to become the only DNS option we support >>> (if such a thing is desirable). >>> >>> Thanks, >>> >>> Tim >>> >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
