No change in the last two weeks, just sent code for review. https://reviews.apache.org/r/24611/
Regards, -- Daniel Simões Time Evolução Infra - Globo.com E-mail: daniel.sim...@corp.globo.com Tel.: +55 21 2483-6977 2014-07-30 11:04 GMT-03:00 Daniel Vega Simões <daniel.sim...@corp.globo.com> : > 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 >>> >> >>> > >>> > >>> >>> >>> >> >
