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" <bm9...@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 1:26 PM
To: openstack-dev@lists.openstack.org; Graham Hayes (graham.ha...@hp.com);
Kiall Mac Innes (ki...@hp.com)
Cc: PACHECO, RODOLFO J; JALLI, RANDEEP; O'CONNELL, MATT; MICHALEK, KEN;
MIDGLEY, BRAD; BISHOP, JAMES; 'raymond.h...@accenture.com'
(raymond.h...@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.eswa...@att.com<mailto:pk.eswa...@att.com>
pe3...@att.com<mailto:pe3...@att.com>
(732) 420-2175
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
