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
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
(732) 420-2175
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----Original Message-----
From: Hayes, Graham [mailto:[email protected]]
Sent: Tuesday, June 17, 2014 05:38 PM
To: MIDGLEY, BRAD
Cc: ESWARAN, PK; [email protected]; Mac Innes, Kiall; PACHECO,
RODOLFO J; JALLI, RANDEEP; O'CONNELL, MATT; MICHALEK, KEN; BISHOP, JAMES;
'[email protected]' ([email protected]); 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" <[email protected]<mailto:[email protected]>> 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: [email protected]; Graham Hayes ([email protected]);
Kiall Mac Innes ([email protected])
Cc: PACHECO, RODOLFO J; JALLI, RANDEEP; O'CONNELL, MATT; MICHALEK, KEN;
MIDGLEY, BRAD; BISHOP, JAMES; '[email protected]'
([email protected]); 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
[email protected]<mailto:[email protected]>
[email protected]<mailto:[email protected]>
(732) 420-2175
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
