Open Stack

Brad,
It seems to me you have a classic migration problem on your hands.
Assuming your ideal end state is to completely migrate to Designate and
minimize customizations (which is definitely preferable for the long
term), your strategy is the real challenge.

One approach is to deploy Designate and put all new domains and or tenants
there.  Over time, migrate domains and tenants over. Your consumers will
naturally want the new benefits and hopefully facilitate the changes.

Another is to have an old fashioned ³cut over². There is considerable risk
which can be mitigated by if your domains don¹t change often and your
consumer base is aligned.

Alternatively, you can run both in parallel and sink between them at the
database layer until you can ultimately switch users over.  This approach
is only recommended if you have to support an older API on the previous
system. You can also synchronize to the same set of name servers if you
can not change them. The problem with this approach is you will write a
lot of throw-a-way code.

SOME QUESTIONS:
- Is there an API available to your current system for your consumers? If
no, that greatly simplifies things.
- Can you easily change your name servers with your registrars?
- Why bother keeping the old system around?


On 6/17/14, 4:38 PM, "Hayes, Graham" <graham.hayes at hp.com> wrote:

>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> 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 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
>
>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev