On 13 February 2016 at 09:57, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:

> On 02/12/2016 07:11 AM, Alex Harvey wrote:
>
>>
>> ACCEPT     tcp  --  1.1.1.1/24           0.0.0.0/0   multiport dports
>> 80,443 /* 100 allow http and https access */
>> ACCEPT     tcp  --  2.2.2.2/24           0.0.0.0/0 multiport dports
>> 80,443 /* 100 allow http and https access */
>>
>> The provider could be modified so as to represent these as:
>>
> <snip>
>
> Conceptionally, it might just work. But it would be quite hard, and create
> a maintenance nightmare. (Have you *looked* at the current provider
> instances/parsing methods? Oh my...)


Yeah, I have.  Main reason I'm leaning to (2). :)


> 2.
>>
>> Add to the firewall module (or perhaps a new Forge module) a defined type
>> that wraps around the existing firewall types/providers.  In Puppet 4, that
>> should be easy to do in the DSL using an iterator; but because I'd like to
>> support Puppet 3 as well, it's a bit trickier.  Still, quite doable.  The
>> hardest part seems to be thinking up a name for the new type.  Any
>> suggestions?
>>
>
> While naming things *is* one of the hardest problems in software, I'm sure
> we can figure something out on this one. No worries.
>
> Iterating on the DSL level is nice and all, but it will cause issues for
> users who don't purge unmanaged firewall rules (granted, that should be a
> rare issue, but then I'm willing to bet that there are people with weird
> edge cases like that.)
>
> The problem is that removing sources from the array of your multiplexer
> resource will just lead to some firewall resources not being in the catalog
> anymore. Their respective rules will remain orphaned, which is not what the
> user will expect.
>

Is this really a problem though?  The documentation for the module
recommends that users do purge the unmanaged firewall rules.  If they
choose not to, then they should understand that means they need to take
care of those manually.  It's no different to any other resource in
Puppet.  If one day I stop managing the /etc/motd file, I should understand
that Puppet won't delete the file; it'll simply leave it in whatever state
it was in.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAF0Ep4XRLZ5vo7RcMpPa4ivxfJD7hb8g%2B-O%3DxC%2BH72iP7tfwmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to