You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Silvano Nogueira Buback <si...@corp.globo.com> on 2014/07/03 21:44:12 UTC

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

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 <
silvano@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> wrote:
>
>> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>> <si...@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 silvano@corp.globo.com
>> > daniel.simoes daniel.simoes@corp.globo.com
>> > lokama - lokama@gmail.com
>> >
>> > Regards,
>> >
>> > Silvano Buback
>> >
>> >
>> >
>> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <sn...@gmail.com>
>> wrote:
>> >
>> >> Of course, I forgotten my account info:
>> >> snbuback / silvano@corp.globo.com
>> >>
>>
>>
>> Done.
>>
>> --David
>>
>
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by Daniel Vega Simões <da...@corp.globo.com>.
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.simoes@corp.globo.com
Tel.: +55 21 2483-6977


2014-07-30 11:04 GMT-03:00 Daniel Vega Simões <da...@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.simoes@corp.globo.com
> Tel.: +55 21 2483-6977
>
>
> 2014-07-14 16:41 GMT-03:00 Daniel Vega Simões <
> daniel.simoes@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.simoes@corp.globo.com
>> Tel.: +55 21 2483-6977
>>
>>
>> 2014-07-14 14:20 GMT-03:00 Chiradeep Vittal <Ch...@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>>
>>> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>"
>>> <de...@cloudstack.apache.org>>
>>> Date: Friday, July 11, 2014 at 10:06 AM
>>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>>> dev@cloudstack.apache.org<ma...@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 <terbolous@gmail.com<mailto:
>>> terbolous@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" <
>>> silvano@corp.globo.com<ma...@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 <
>>> silvano@corp.globo.com<ma...@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 <david@gnsa.us<mailto:
>>> david@gnsa.us>> wrote:
>>> >
>>> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>>> >> <si...@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 silvano@corp.globo.com<ma...@corp.globo.com>
>>> >> > daniel.simoes daniel.simoes@corp.globo.com<mailto:
>>> daniel.simoes@corp.globo.com>
>>> >> > lokama - lokama@gmail.com<ma...@gmail.com>
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> > Silvano Buback
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <
>>> snbuback@gmail.com<ma...@gmail.com>>
>>> >> wrote:
>>> >> >
>>> >> >> Of course, I forgotten my account info:
>>> >> >> snbuback / silvano@corp.globo.com<ma...@corp.globo.com>
>>> >> >>
>>> >>
>>> >>
>>> >> Done.
>>> >>
>>> >> --David
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by Daniel Vega Simões <da...@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.simoes@corp.globo.com
Tel.: +55 21 2483-6977


2014-07-14 16:41 GMT-03:00 Daniel Vega Simões <da...@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.simoes@corp.globo.com
> Tel.: +55 21 2483-6977
>
>
> 2014-07-14 14:20 GMT-03:00 Chiradeep Vittal <Ch...@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>>
>> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
>> Date: Friday, July 11, 2014 at 10:06 AM
>> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
>> dev@cloudstack.apache.org<ma...@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 <terbolous@gmail.com<mailto:
>> terbolous@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" <
>> silvano@corp.globo.com<ma...@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 <
>> silvano@corp.globo.com<ma...@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 <david@gnsa.us<mailto:
>> david@gnsa.us>> wrote:
>> >
>> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>> >> <si...@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 silvano@corp.globo.com<ma...@corp.globo.com>
>> >> > daniel.simoes daniel.simoes@corp.globo.com<mailto:
>> daniel.simoes@corp.globo.com>
>> >> > lokama - lokama@gmail.com<ma...@gmail.com>
>> >> >
>> >> > Regards,
>> >> >
>> >> > Silvano Buback
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <snbuback@gmail.com
>> <ma...@gmail.com>>
>> >> wrote:
>> >> >
>> >> >> Of course, I forgotten my account info:
>> >> >> snbuback / silvano@corp.globo.com<ma...@corp.globo.com>
>> >> >>
>> >>
>> >>
>> >> Done.
>> >>
>> >> --David
>> >>
>> >
>> >
>>
>>
>>
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by Daniel Vega Simões <da...@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.simoes@corp.globo.com
Tel.: +55 21 2483-6977


2014-07-14 14:20 GMT-03:00 Chiradeep Vittal <Ch...@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>>
> Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>>
> Date: Friday, July 11, 2014 at 10:06 AM
> To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<ma...@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 <terbolous@gmail.com<mailto:
> terbolous@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" <silvano@corp.globo.com
> <ma...@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 <
> silvano@corp.globo.com<ma...@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 <david@gnsa.us<mailto:
> david@gnsa.us>> wrote:
> >
> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
> >> <si...@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 silvano@corp.globo.com<ma...@corp.globo.com>
> >> > daniel.simoes daniel.simoes@corp.globo.com<mailto:
> daniel.simoes@corp.globo.com>
> >> > lokama - lokama@gmail.com<ma...@gmail.com>
> >> >
> >> > Regards,
> >> >
> >> > Silvano Buback
> >> >
> >> >
> >> >
> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <snbuback@gmail.com
> <ma...@gmail.com>>
> >> wrote:
> >> >
> >> >> Of course, I forgotten my account info:
> >> >> snbuback / silvano@corp.globo.com<ma...@corp.globo.com>
> >> >>
> >>
> >>
> >> Done.
> >>
> >> --David
> >>
> >
> >
>
>
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by Chiradeep Vittal <Ch...@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>>
Reply-To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>
Date: Friday, July 11, 2014 at 10:06 AM
To: "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@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 <te...@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" <si...@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 <
silvano@corp.globo.com<ma...@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>> wrote:
>
>> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>> <si...@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 silvano@corp.globo.com<ma...@corp.globo.com>
>> > daniel.simoes daniel.simoes@corp.globo.com<ma...@corp.globo.com>
>> > lokama - lokama@gmail.com<ma...@gmail.com>
>> >
>> > Regards,
>> >
>> > Silvano Buback
>> >
>> >
>> >
>> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <sn...@gmail.com>>
>> wrote:
>> >
>> >> Of course, I forgotten my account info:
>> >> snbuback / silvano@corp.globo.com<ma...@corp.globo.com>
>> >>
>>
>>
>> Done.
>>
>> --David
>>
>
>



Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by David Nalley <da...@gnsa.us>.
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 <te...@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" <si...@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 <
>> silvano@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> wrote:
>> >
>> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>> >> <si...@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 silvano@corp.globo.com
>> >> > daniel.simoes daniel.simoes@corp.globo.com
>> >> > lokama - lokama@gmail.com
>> >> >
>> >> > Regards,
>> >> >
>> >> > Silvano Buback
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <sn...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> Of course, I forgotten my account info:
>> >> >> snbuback / silvano@corp.globo.com
>> >> >>
>> >>
>> >>
>> >> Done.
>> >>
>> >> --David
>> >>
>> >
>> >
>>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

Posted by Erik Weber <te...@gmail.com>.
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" <si...@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 <
> silvano@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> wrote:
> >
> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
> >> <si...@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 silvano@corp.globo.com
> >> > daniel.simoes daniel.simoes@corp.globo.com
> >> > lokama - lokama@gmail.com
> >> >
> >> > Regards,
> >> >
> >> > Silvano Buback
> >> >
> >> >
> >> >
> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback <sn...@gmail.com>
> >> wrote:
> >> >
> >> >> Of course, I forgotten my account info:
> >> >> snbuback / silvano@corp.globo.com
> >> >>
> >>
> >>
> >> Done.
> >>
> >> --David
> >>
> >
> >
>