Where should should this be integrated? I would have thought have
thought to add support in smartproxy since it handles DNS now, but now
that Foreman has (for a long time now) integrated ruby-fog, which has
native dnsmadeeasy support, might we want to make the call right from
Foreman?
Please advise.
Thanks,
Brian
In theory it'd be easiest to add it to the proxy, where you could add
Fog as a (huge) dependency I guess. Unfortunately we don't have support
for adding new DNS providers as plugins yet (#7008), only in core.
To add it in Foreman core would necessitate some refactoring to make it
possible to reconfigure domains and subnets to use some other non-proxy
backend for DNS updates… not sure what that would look like. Maybe a
Foreman core plugin would let you do it quickly, bypassing the proxy code.
–
Dominic Cleal
Red Hat Engineering
I think we could take this on, if we knew upfront that adding fog to smartproxy
was agreeable to you and the rest of the those who merge pull requests, and/or
who might have an opinion here.
Refactoring core, might be a bit much for us, but we'll take a look.
-Brian
>>> Where should should this be integrated? I would have thought have
>>> thought to add support in smartproxy since it handles DNS now, but now
>>> that Foreman has (for a long time now) integrated ruby-fog, which has
>>> native dnsmadeeasy support, might we want to make the call right from
>>> Foreman?
>>
>> In theory it'd be easiest to add it to the proxy, where you could add
>> Fog as a (huge) dependency I guess. Unfortunately we don't have support
>> for adding new DNS providers as plugins yet (#7008), only in core.
>>
>> To add it in Foreman core would necessitate some refactoring to make it
>> possible to reconfigure domains and subnets to use some other non-proxy
>> backend for DNS updates… not sure what that would look like. Maybe a
>> Foreman core plugin would let you do it quickly, bypassing the proxy code.
>
> I think we could take this on, if we knew upfront that adding fog to smartproxy
> was agreeable to you and the rest of the those who merge pull requests, and/or
> who might have an opinion here.
Yeah, I'm unsure about it being a core proxy dependency right now.
Ideally I think we'd put it in a plugin so we don't add such a large
dep, but we need to fix #7008 first so you can register a new DNS
provider from a plugin instead of just a new API.
If we added it as a core dep, we'd need to package it fully for Debian
and build a non-SCL version for EL, and it has quite a lot of dependencies.
> Refactoring core, might be a bit much for us, but we'll take a look.
Yeah, indeed, I'm not sure what it would look like either.
I'll try and follow up on #7008, as I think it's important - you're not
the only person trying to add new DNS providers and being restricted by
this problem.
If you want a shorter term fix, it'd probably be to have a core plugin
that changes or replaces the DNS orchestration.
–
Dominic Cleal
Red Hat Engineering