I'm working on setting up foreman for our new datacenter build and we're
using dnsmadeeasy to manage the domain we'll be using for hostnames and
such in the new datacenter. Naturally, I want to integrate the foreman
so it can automatically create records.
The redmine issue for this work is here:
http://projects.theforeman.org/issues/1224
I've run into a bit of a hurdle, however, as described in the issue.
dnsmadeeasy's API requires you to know the ID of the domain you're
modifying records in. This is fine, you can look it up by grabbing the
list of all of the domains and searching through it. Except our
dnsmadeeasy account manages a couple thousand domains, so this isn't
exactly practical.
So I thought of 2 possible solutions to this:
-
Hardcode the domain -> id mapping in the proxy's settings.yml file.
This should be fairly trivial to implement, and completely
transparent to proxy consumers.
-
Extend the foreman -> smart-proxy API to allow passing parameters
across. Then you could add the domain's dnsmadeeasy ID as a parameter
in theforeman and not have to do any looking up or logic or anything,
it Just Works.
1 is the easiest to implement, but I like 2 better, so I'm coming here
to ask which direction I should take.
I think it might not be a bad idea to have the proxy still able to do
auto-discovery of domains as well by grabbing the list from dnsmadeeasy
and figuring it out, which is the simplest way, but not overly scalable.
Thoughts?
I'd like to get started on whatever implementation route is decided
(I'll implement all of them and make PRs if that's what we need) as soon
as possible so I can get rolling on setting up foreman 
-Jeremy
Now that we have fog directly integrated in Foreman, do we still want
to use proxy for all DNS operations? IE: Fog has support for a number
of DNS providers. Or do we want to consider adding Fog to the proxy?
(Many of these APIs are fairly easy to deal with with only the
rest_client gem, but the abstraction Fog provides might make it worth
it.)
The advantages I see of adding Fog to proxy is that it would allow us
to additional providers at a lower cost, and potential have the API
call translation be easier for providing multiple providers. The cons
would be it's a huge ball of deps and we already have it in Foreman.
Having the DNS stuff in the proxy also allows a DMZed proxy
communicate with the cloud services on behalf of a firewalled foreman
server that can't directly reach the Internet.
On the flip side we already require Foreman to directly contact EC2,
would it be that much of a stretch to have Foreman directly
communicate with Route53 and dnsmadeeasy? (My sense is if we can make
it work with a simple HTTP proxy, we don't have to incorporate in
smart-proxy, for those things that are API driven already and
supported in fog.)
IE: My leanings are to have foreman directly communicate with the
dnsmadeasy api endpoint, using the fog library. (with or without an
http proxy in between).
Thanks,
Brian
···
On Tue, Jul 16, 2013 at 1:51 PM, Jeremy Kitchen wrote:
> I'm working on setting up foreman for our new datacenter build and we're
> using dnsmadeeasy to manage the domain we'll be using for hostnames and
> such in the new datacenter. Naturally, I want to integrate the foreman
> so it can automatically create records.
>
> The redmine issue for this work is here:
> http://projects.theforeman.org/issues/1224
>
> I've run into a bit of a hurdle, however, as described in the issue.
> dnsmadeeasy's API requires you to know the ID of the domain you're
> modifying records in. This is fine, you can look it up by grabbing the
> list of all of the domains and searching through it. Except our
> dnsmadeeasy account manages a couple thousand domains, so this isn't
> exactly practical.
>
> So I thought of 2 possible solutions to this:
>
> 1) Hardcode the domain -> id mapping in the proxy's settings.yml file.
> This should be fairly trivial to implement, and completely
> transparent to proxy consumers.
>
> 2) Extend the foreman -> smart-proxy API to allow passing parameters
> across. Then you could add the domain's dnsmadeeasy ID as a parameter
> in theforeman and not have to do any looking up or logic or anything,
> it Just Works.
>
> 1 is the easiest to implement, but I like 2 better, so I'm coming here
> to ask which direction I should take.
>
> I think it might not be a bad idea to have the proxy still able to do
> auto-discovery of domains as well by grabbing the list from dnsmadeeasy
> and figuring it out, which is the simplest way, but not overly scalable.
>
> Thoughts?
>
> I'd like to get started on whatever implementation route is decided
> (I'll implement all of them and make PRs if that's what we need) as soon
> as possible so I can get rolling on setting up foreman :)
I wasn't aware of fog being built directly into foreman. Is this
something new since v1.2.0? I agree with you with regard to having it be
directly from foreman, since you can always just set up a simple HTTP
proxy for fog to use rather than adding loads of deps to foreman-proxy.
-Jeremy
···
On Fri, Jul 19, 2013 at 03:09:26PM -0400, Brian Gupta wrote:
> Now that we have fog directly integrated in Foreman, do we still want
> to use proxy for all DNS operations? IE: Fog has support for a number
> of DNS providers. Or do we want to consider adding Fog to the proxy?
>
> (Many of these APIs are fairly easy to deal with with only the
> rest_client gem, but the abstraction Fog provides might make it worth
> it.)
>
> The advantages I see of adding Fog to proxy is that it would allow us
> to additional providers at a lower cost, and potential have the API
> call translation be easier for providing multiple providers. The cons
> would be it's a huge ball of deps and we already have it in Foreman.
> Having the DNS stuff in the proxy also allows a DMZed proxy
> communicate with the cloud services on behalf of a firewalled foreman
> server that can't directly reach the Internet.
>
> On the flip side we already require Foreman to directly contact EC2,
> would it be that much of a stretch to have Foreman directly
> communicate with Route53 and dnsmadeeasy? (My sense is if we can make
> it work with a simple HTTP proxy, we don't have to incorporate in
> smart-proxy, for those things that are API driven already and
> supported in fog.)
>
> IE: My leanings are to have foreman directly communicate with the
> dnsmadeasy api endpoint, using the fog library. (with or without an
> http proxy in between).
A fog is one of foreman dependency for more than one year. It was added in
http://projects.theforeman.org/projects/foreman/repository/revisions/334d0359b713936bbb63ab1ca3fabcca4d36e4ba
I'm not sure whether we should call it 'built directly into foreman' though.
···
On Friday 19 of July 2013 12:43:02 Jeremy Kitchen wrote:
> On Fri, Jul 19, 2013 at 03:09:26PM -0400, Brian Gupta wrote:
> > Now that we have fog directly integrated in Foreman, do we still want
> > to use proxy for all DNS operations? IE: Fog has support for a number
> > of DNS providers. Or do we want to consider adding Fog to the proxy?
> >
> > (Many of these APIs are fairly easy to deal with with only the
> > rest_client gem, but the abstraction Fog provides might make it worth
> > it.)
> >
> > The advantages I see of adding Fog to proxy is that it would allow us
> > to additional providers at a lower cost, and potential have the API
> > call translation be easier for providing multiple providers. The cons
> > would be it's a huge ball of deps and we already have it in Foreman.
> > Having the DNS stuff in the proxy also allows a DMZed proxy
> > communicate with the cloud services on behalf of a firewalled foreman
> > server that can't directly reach the Internet.
> >
> > On the flip side we already require Foreman to directly contact EC2,
> > would it be that much of a stretch to have Foreman directly
> > communicate with Route53 and dnsmadeeasy? (My sense is if we can make
> > it work with a simple HTTP proxy, we don't have to incorporate in
> > smart-proxy, for those things that are API driven already and
> > supported in fog.)
> >
> > IE: My leanings are to have foreman directly communicate with the
> > dnsmadeasy api endpoint, using the fog library. (with or without an
> > http proxy in between).
>
> I wasn't aware of fog being built directly into foreman. Is this
> something new since v1.2.0? I agree with you with regard to having it be
> directly from foreman, since you can always just set up a simple HTTP
> proxy for fog to use rather than adding loads of deps to foreman-proxy.
>
> -Jeremy
–
Marek
Devs,
What do people feel about allowing Foreman to provision DNS directly
through Fog, without using smart-proxy? (Assuming Fog supports the
provider?) Jeremy asked a great question and seems willing to do the
lifting to make it happen.
Thanks,
Brian
···
On Mon, Jul 22, 2013 at 2:23 AM, Marek Hulan wrote:
> On Friday 19 of July 2013 12:43:02 Jeremy Kitchen wrote:
>> On Fri, Jul 19, 2013 at 03:09:26PM -0400, Brian Gupta wrote:
>> > Now that we have fog directly integrated in Foreman, do we still want
>> > to use proxy for all DNS operations? IE: Fog has support for a number
>> > of DNS providers. Or do we want to consider adding Fog to the proxy?
>> >
>> > (Many of these APIs are fairly easy to deal with with only the
>> > rest_client gem, but the abstraction Fog provides might make it worth
>> > it.)
>> >
>> > The advantages I see of adding Fog to proxy is that it would allow us
>> > to additional providers at a lower cost, and potential have the API
>> > call translation be easier for providing multiple providers. The cons
>> > would be it's a huge ball of deps and we already have it in Foreman.
>> > Having the DNS stuff in the proxy also allows a DMZed proxy
>> > communicate with the cloud services on behalf of a firewalled foreman
>> > server that can't directly reach the Internet.
>> >
>> > On the flip side we already require Foreman to directly contact EC2,
>> > would it be that much of a stretch to have Foreman directly
>> > communicate with Route53 and dnsmadeeasy? (My sense is if we can make
>> > it work with a simple HTTP proxy, we don't have to incorporate in
>> > smart-proxy, for those things that are API driven already and
>> > supported in fog.)
>> >
>> > IE: My leanings are to have foreman directly communicate with the
>> > dnsmadeasy api endpoint, using the fog library. (with or without an
>> > http proxy in between).
>>
>> I wasn't aware of fog being built directly into foreman. Is this
>> something new since v1.2.0? I agree with you with regard to having it be
>> directly from foreman, since you can always just set up a simple HTTP
>> proxy for fog to use rather than adding loads of deps to foreman-proxy.
>>
>> -Jeremy
>
> A fog is one of foreman dependency for more than one year. It was added in
> http://projects.theforeman.org/projects/foreman/repository/revisions/334d0359b713936bbb63ab1ca3fabcca4d36e4ba
> I'm not sure whether we should call it 'built directly into foreman' though.
>
> --
> Marek
> >> > Now that we have fog directly integrated in Foreman, do we still want
> >> > to use proxy for all DNS operations? IE: Fog has support for a number
> >> > of DNS providers. Or do we want to consider adding Fog to the proxy?
> >> >
> >> > (Many of these APIs are fairly easy to deal with with only the
> >> > rest_client gem, but the abstraction Fog provides might make it worth
> >> > it.)
> >> >
> >> > The advantages I see of adding Fog to proxy is that it would allow us
> >> > to additional providers at a lower cost, and potential have the API
> >> > call translation be easier for providing multiple providers. The cons
> >> > would be it's a huge ball of deps and we already have it in Foreman.
> >> > Having the DNS stuff in the proxy also allows a DMZed proxy
> >> > communicate with the cloud services on behalf of a firewalled foreman
> >> > server that can't directly reach the Internet.
> >> >
> >> > On the flip side we already require Foreman to directly contact EC2,
> >> > would it be that much of a stretch to have Foreman directly
> >> > communicate with Route53 and dnsmadeeasy? (My sense is if we can make
> >> > it work with a simple HTTP proxy, we don't have to incorporate in
> >> > smart-proxy, for those things that are API driven already and
> >> > supported in fog.)
> >> >
> >> > IE: My leanings are to have foreman directly communicate with the
> >> > dnsmadeasy api endpoint, using the fog library. (with or without an
> >> > http proxy in between).
> >>
> >> I wasn't aware of fog being built directly into foreman. Is this
> >> something new since v1.2.0? I agree with you with regard to having it be
> >> directly from foreman, since you can always just set up a simple HTTP
> >> proxy for fog to use rather than adding loads of deps to foreman-proxy.
> >>
> >> -Jeremy
> >
> > A fog is one of foreman dependency for more than one year. It was added
> in
> >
> Revision 334d0359 - fixes #1540 added suport for provisioning on ovirt/rhvem using fog. This pat... - Foreman
> > I'm not sure whether we should call it 'built directly into foreman'
> though.
> >
> > –
> > Marek
>
> Devs,
>
> What do people feel about allowing Foreman to provision DNS directly
> through Fog, without using smart-proxy? (Assuming Fog supports the
> provider?) Jeremy asked a great question and seems willing to do the
> lifting to make it happen.
>
It doesn't make much sense to talk to third party DNS providers from the
proxy. I'm all for talking with external DNS services through fog directly
from Foreman.
···
On Sat, Aug 3, 2013 at 12:14 AM, Brian Gupta wrote:
> On Mon, Jul 22, 2013 at 2:23 AM, Marek Hulan wrote:
> > On Friday 19 of July 2013 12:43:02 Jeremy Kitchen wrote:
> >> On Fri, Jul 19, 2013 at 03:09:26PM -0400, Brian Gupta wrote:
Thanks,
Brian
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
