Hi guys, Since nobody was opposed to the approach suggested in the last e-mail, we went on and implemented the global option that authorizes the plugin to override record entries when they already exist in the DNS server.
We also updated the name to GloboDNS and the functional spec to reflect both changes. You can take a look at the table that summarizes the actions for the GloboDNS plugin on the wiki <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI>. Unit tests were implemented to make sure all of these cases behave as expected. Please let me know how we can move forward to integrate this in the Cloudstack repository. Cheers, -- Daniel Simões Time Evolução Infra - Globo.com E-mail: daniel.sim...@corp.globo.com Tel.: +55 21 2483-6977 2014-07-14 16:41 GMT-03:00 Daniel Vega Simões <daniel.sim...@corp.globo.com> : > Hi guys, > > @David > As Silvano mentioned earlier, our cloud-related DNS have unique names > (based on network info), so conflicts do not happen. As such, these domains > are exclusive to our cloud infrastructure and we let Cloudstack have full > authority over them. For that reason, whenever a network is deleted, the > domain associated to it is removed, along with every record in it. > > > @Chiradeep > If a domain already exists when a network is created, the plugin takes > over that domain, creating and removing records as needed. It does not > handle any records created externally. The only exception is when the > domain is removed, as explained just above. > > Secondary IPs are currently not handled by the plugin, since we understand > that once that IP is reserved by Cloudstack, routing and name resolution > should be done manually by the operator. > > As for the name, GloboDNS sounds about right :) We'll make the appropriate > changes to avoid confusion. > > > > This is what makes sense for us in this first release. Implementing every > option available to the operator might make the plugin configuration very > confusing. > > A simpler approach would be to create one single global/zone option that > allows Cloudstack to have full authority over domains/records or not. In > the case where Cloudstack does not have authority, an error could be thrown > if the domain/record already exists and domains are never removed by the > plugin itself, so an operator would need to do it manually (or by means of > another tool). > > > What do you think? > > > -- > Daniel Simões > Time Evolução Infra - Globo.com > E-mail: daniel.sim...@corp.globo.com > Tel.: +55 21 2483-6977 > > > 2014-07-14 14:20 GMT-03:00 Chiradeep Vittal <chiradeep.vit...@citrix.com>: > > I think the question is relevant to network creation as well. If I provide >> a domain that already exists, what is the result? >> >> A couple of other comments: >> - are we going to handle the case of secondary IP addresses? >> - DNSAPI sounds generic, but it actually refers to one specific API >> architected by Globo. To avoid confusion, would it make sense to rename it >> GloboDNSAPI? Alternately, give the DNSAPI project a less generic name >> (e.g., vincular) >> >> From: David Nalley <da...@gnsa.us<mailto:da...@gnsa.us>> >> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" < >> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> >> Date: Friday, July 11, 2014 at 10:06 AM >> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" < >> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> >> Subject: Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind >> (for 4.5) >> >> I tend to agree with Erik, flexibility solves the problem for more >> people, while solution 1 is likely the easiest to implement. I am not >> sure that it makes sense for most people though - and would really >> only work for greenfield deployments or clouds that had all of the DNS >> entries relating to instances in the cloud. >> >> First question; how are you intending on using it? Which of those >> solutions works for you? >> >> --David >> >> >> >> On Thu, Jul 3, 2014 at 3:49 PM, Erik Weber <terbol...@gmail.com<mailto: >> terbol...@gmail.com>> wrote: >> To push that choice over to the operator you could add it as a >> global/zone/network option. >> >> As an operator i would prefer to have my own logic to handle cleanup, but >> this varies for everyone hence the option :-) >> >> Erik >> 3. juli 2014 21:45 skrev "Silvano Nogueira Buback" < >> silv...@corp.globo.com<mailto:silv...@corp.globo.com>> >> følgende: >> >> Hi guys, >> >> I think you are busy because 4.4 release tasks, but I'm worried about >> the time to 4.5 feature freeze. I put the documentation of feature in wiki >> as requested and I hoped people read there and make some comments here. >> >> To help, I will put design issues that are in document, one by one, and we >> can discuss in this thread. After each discussion I will change the >> document. >> >> I have one question about removing DNS domain when network has been >> deleted. In my current implementation I remove DNS domain when network is >> removed. But if the DNS domain is shared with another network or maybe is >> a >> dns domain used outside ACS this can be a problem. What I can do with DNS >> domain when network is removed: >> >> 1. Keep the current implementation. Always deleted DNS domain when >> network is removed (works well if the ACS is the only manager for the >> DNS >> (one network domain per network). >> 2. Remove DNS domain only if the domain was created by ACS. This can >> be >> a problem if someone put records after ACS creation. >> 3. Remove DNS domain only if there is no more records there. Maybe DNS >> domain can stay forever there because an inconsistency that keep only >> one >> record. >> >> >> Which one is the best? >> >> []'s, >> >> Silvano Buback >> >> >> >> On Thu, Jun 26, 2014 at 11:34 AM, Silvano Nogueira Buback < >> silv...@corp.globo.com<mailto:silv...@corp.globo.com>> wrote: >> >> > Thank you David. >> > >> > I put design documents on wiki: >> > >> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI >> . >> > I create an issue https://issues.apache.org/jira/browse/CLOUDSTACK-6998 >> > too. >> > >> > I look forward to hearing your feedbacks. >> > >> > []'s, >> > >> > Silvano Buback >> > >> > >> > On Wed, Jun 25, 2014 at 5:50 PM, David Nalley <da...@gnsa.us<mailto: >> da...@gnsa.us>> wrote: >> > >> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback >> >> <silv...@corp.globo.com<mailto:silv...@corp.globo.com>> wrote: >> >> > Hi guys, >> >> > >> >> > I finish the first version of design document: >> >> > >> >> >> >> https://docs.google.com/document/d/1kbPQJrBC87ZtR-t7LwHFDzAmT436ShtjwKE84FVfByM/pub >> >> > . >> >> > >> >> > Someone could give me access to put design documents in wiki? >> Bellow >> >> the >> >> > username of people work with Cloudstack in Globo.com and need access. >> >> > >> >> > snbuback silv...@corp.globo.com<mailto:silv...@corp.globo.com> >> >> > daniel.simoes daniel.sim...@corp.globo.com<mailto: >> daniel.sim...@corp.globo.com> >> >> > lokama - lok...@gmail.com<mailto:lok...@gmail.com> >> >> > >> >> > Regards, >> >> > >> >> > Silvano Buback >> >> > >> >> > >> >> > >> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <snbub...@gmail.com >> <mailto:snbub...@gmail.com>> >> >> wrote: >> >> > >> >> >> Of course, I forgotten my account info: >> >> >> snbuback / silv...@corp.globo.com<mailto:silv...@corp.globo.com> >> >> >> >> >> >> >> >> >> Done. >> >> >> >> --David >> >> >> > >> > >> >> >> >
