Open Stack

Dear OpenStack Dev Team:
                I am resending this "OpenStack Designate DNSaaS" e-mail once again after my registration.
                The original message is at the bottom of this thread and was sent on Tuesday, June 17, 2014 03:26 PM.

                Thanks in advance for your feedback.

P.K. Eswaran
AT&T Information Technology Operations
Middletown, NJ
Room C1-2B06
pk.eswaran at att.com<mailto:pk.eswaran at att.com>
pe3476 at att.com<mailto:pe3476 at att.com>
(732) 420-2175
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-----Original Message-----
From: Hayes, Graham [mailto:graham.hayes at hp.com]
Sent: Tuesday, June 17, 2014 05:38 PM
To: MIDGLEY, BRAD
Cc: ESWARAN, PK; openstack-dev at lists.openstack.org; Mac Innes, Kiall; PACHECO, RODOLFO J; JALLI, RANDEEP; O'CONNELL, MATT; MICHALEK, KEN; BISHOP, JAMES; 'raymond.horn at accenture.com' (raymond.horn at accenture.com); BOEHMER, JEFF; SCOLLARD, JAMES; SHANGHAVI, PRAFUL B
Subject: RE: OpenStack Designate DNSaaS



Unfortunately #1 is not a real option - designate needs the storage layer to operate.



I would guess #2 or #3 would be the more feasible options.



Graham


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



"MIDGLEY, BRAD" <bm903k at att.com<mailto:bm903k at att.com>> wrote:







PK,



I'd agree with pursuing #1 or with a simple reference implementation like minidns if ripping it out is disruptive.



Brad

From: ESWARAN, PK
Sent: Tuesday, June 17, 2014 03:26 PM
To: openstack-dev at lists.openstack.org; Graham Hayes (graham.hayes at hp.com); Kiall Mac Innes (kiall at hp.com)
Cc: PACHECO, RODOLFO J; JALLI, RANDEEP; O'CONNELL, MATT; MICHALEK, KEN; MIDGLEY, BRAD; BISHOP, JAMES; 'raymond.horn at accenture.com' (raymond.horn at accenture.com); BOEHMER, JEFF; SCOLLARD, JAMES; SHANGHAVI, PRAFUL B
Subject: OpenStack Designate DNSaaS

Dear OpenStack Dev Team:
        I exchanged a few thoughts on Designate DNSaaS with Graham Hayes of HP and he advised me to send this out to a larger DEV audience. Your feedback will help the Designte DNSaaS project and also the AT&T Cloud group.

AT&T Cloud group is investigating "Designate DNSaaS" and we would like to indulge in this emerging technology. We could embrace and also participate into this new OpenStack technology. I am also copying a few of the AT&T team members.

In AT&T in the near term, we would like to use Designate DNSaaS as a frontend while retaining the current AT&T backend DNS infrastructure in place. The main issue in this is the role of "Designate Database" as MASTER database of record for all Designate DNS provisioning. This Designate role is useful when there is a deployment of new DNS system and auth servers. But ....

In AT&T, we already have a "DNS bind provisioner and a database of record" that keeps our DNS authoritative servers updated. Having a dual DNS Master Databases of record will be a synchronizing nightmare and it will be a difficult, time consuming process to reposition our existing BIND auth servers DIRECTLY under Designate.

        Please also note that the exisitng AT&T "DNS bind provisioner and a database of record" handles multiple services and multiple customers within each service while validating the rightful ownership prior to any DNS manipulations.

        In the near term we would like to engage in a LESS-THAN-fork-lift effort so that we can enjoy the major functions of "Designate API", "Designate Central" and "Designate Sink".

        So the question is what are our alternatives without a fork-lift effort?

        Knowing that the Designate storage layer is pluggable, I was looking at the following possibilities and your feedback could help us. Thank you in advance.

  1.  Disable the storage layer entirely while keeping it for minimal essential Designate functions.
  2.  Writing a storage plugin to our existing DB may be one consideration, but this would require a fork-lift effort since the current system supports multiple services and customers. This would take a longer timeframe than what we want to ensure that things are OK.
  3.  Writing a storage-plugin-backend to a system-process that in turn will manage our existing DB, seems to be a good possibility but this is not yet clear.
  4.  ?? Possibly other with your feedback. Thanks.

P.K. Eswaran
AT&T Information Technology Operations
Middletown, NJ
Room C1-2B06
pk.eswaran at att.com<mailto:pk.eswaran at att.com>
pe3476 at att.com<mailto:pe3476 at att.com>
(732) 420-2175



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/d78e31b7/attachment.html>