Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
+1 to Vipul On Tue, Oct 1, 2013 at 9:46 PM, Michael Basnight wrote: > On Oct 1, 2013, at 7:06 PM, Vipul Sabhaya wrote: > > > On Oct 1, 2013, at 3:37 PM, Michael Basnight > wrote: > > > >> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov > wrote: > >> > >>> > >>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson > 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. > > Sounds like we have a winner. > > ___ > 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
Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
On Oct 1, 2013, at 7:06 PM, Vipul Sabhaya wrote: > On Oct 1, 2013, at 3:37 PM, Michael Basnight wrote: > >> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov wrote: >> >>> >>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson >>> 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. Sounds like we have a winner. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
> On Oct 1, 2013, at 3:37 PM, Michael Basnight wrote: > >> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov wrote: >> >> >>> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson >>> 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/mail
Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
Ilya you make a good point. We shouldn't spend time massively change the DNS code if we'll just have to do it again so that HEAT can do everything for us. I echo Mike's comments though that if for some reason someone wants Designate support before we get HEAT integrated they should be able to add a new DNS driver. As I said before though I think that should be possible without major changes to the existing DNS code. Thanks, Tim ___ From: Michael Basnight [mailto:mbasni...@gmail.com] Sent: Tuesday, October 01, 2013 5:37 PM To: OpenStack Development Mailing List Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration. On Oct 1, 2013, at 3:06 PM, Ilya Sviridov wrote: On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson 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. 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 lis
Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
> On Oct 1, 2013, at 3:06 PM, Ilya Sviridov wrote: > > >> On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson >> 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. > >> >> 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
Re: [openstack-dev] [TROVE] Thoughts on DNS refactoring, Designate integration.
On Tue, Oct 1, 2013 at 6:45 PM, Tim Simpson 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. > > 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] [TROVE] Thoughts on DNS refactoring, Designate integration.
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. 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. 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. 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
