Hi,

if you really get a nice solution, please publish it on github/the forge to strengthen the community.


Regards, David

On 2014-07-21 09:52, Gavin Williams wrote:
Ah, forgot about the parsed file stuff... Good call, think that could be
a good fit for the jre.properties file :)

Cheers
Gavin

On Monday, 21 July 2014 07:17:45 UTC+1, David Schmitt wrote:

    Hi

    On 2014-07-14 14:49, Gavin Williams wrote:
     > As part of my work to create an Apache Karaf module[1] I need to
    manage
     > a number of configuration files, and I'm wondering what the best
    way to
     > go about it might be...
     > A couple of examples of the config files that need managing can
    be found
     > here[2].
     >
     > I think the 2 provided examples give different challenges.
     > /jre.properties/[3]//strikes me as the most troublesome
    initially, due
     > to the nature of the contents and the format reqs...
     > My initial thought is to provide a type that can manage the file,
    and
     > possibly use Augeas to manage the file. Happy for other suggestions
     > though :)
     >
     > /wrapper.conf/[4]//looks like it should be fairly easy to
    template. The
     > only thing I'm not sure on is how to handle the incrementing
    nature of
     > the param lines...
     > I'd like to keep the number of resource params as light as
    possible, as
     > there's no way I can expose all the possible config lines, so I'm
     > thinking maybe use an array for each 'set' of config lines, e.g.
     > 'wrapper.java.classpath' and 'wrapper.java.additional'... But
    then how
     > do I handle over-riding pre-existing config values? Is there a
    better
     > way to handle this file?

    With a little ruby, you can very easily write a parsed file
    type/provider to handle each file format. That way you can design the
    resource as you need and can even support purging of unknown values if
    you're so inclined.



    Regards, David

--
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
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/68e96c23-e24d-41af-93a9-04f99a95742a%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/68e96c23-e24d-41af-93a9-04f99a95742a%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.


--
* Always looking for people I can help with awesome projects *
G+: https://plus.google.com/+DavidSchmitt
Blog: http://club.black.co.at/log/
LinkedIn: http://at.linkedin.com/in/davidschmitt

--
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/53CCDFF5.7080706%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Reply via email to