Managing config files...

[Gavin Williams]

Morning all

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?

Thanks in advance for any suggestion...

Regards
Gavin

[1] https://groups.google.com/forum/#!searchin/puppet-users/karaf/puppet-users/dcV6Qt480cE/F_Yhj5XsJogJ
[2] https://gist.github.com/fatmcgav/684803f83e3b15118e79
[3] https://gist.github.com/fatmcgav/684803f83e3b15118e79#file-jre-properties
[4] https://gist.github.com/fatmcgav/684803f83e3b15118e79#file-wrapper-conf

[Felix Frank]

On 07/14/2014 02:49 PM, Gavin Williams wrote:

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 :)

If I'd need Puppet to manage that, I'd likely want to be able to manage each LeftHandSide/ListElement pair via ensure. I.e., I don't want to enumerate the full lists in manifest or hiera, but just want to make sure distinct elements are there ore not.

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?

I think you rather mean - how to *keep* existing values and only manage certain entries of the array.
I fear that won't work. And I concur that arrays would be a good choice here. Perhaps an alternative API that takes an index/value hash instead would be useful to some, but seems like abysimal mileage to me.

I haven't dabbled in augeasproviders yet (which is a shame), but imagine that it would be a good approach for both files (unless of course the latter can just be templated).

Cheers,
Felix

[fatmcgav]

Felik

Cheers for taking the time to reply...

I've been trying to work up a Augeas lense to support jre.properties, but dont seem to be having much luck... Seems like there's a bit of a black art to writing them...

I'm in two minds about wrapper.conf. I've got it templates currently, but like you say I'm not sure how to best handle the existing default values plus any new values that might be needed... Or perhaps I just don't support overriding existing values.. Though that feels like a bit of a short cut to me...

Anyone else?

Cheers
Gavin

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/9aFzgCU0GCo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/53C5948A.3080707%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

On 07/15/2014 11:08 PM, fatmcgav wrote:
> I've been trying to work up a Augeas lense to support jre.properties,
> but dont seem to be having much luck... Seems like there's a bit of a
> black art to writing them...

Oh, right, I forget...yes we mortals are not supposed to be able to just
create new lenses :-)

[David Schmitt]

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

[Gavin Williams]

Ah, forgot about the parsed file stuff... Good call, think that could be a good fit for the jre.properties file :)

Cheers
Gavin

[David Schmitt]

Hi,

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


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...@googlegroups.com
> <mailto:puppet-users...@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

[Felix Frank]

On 07/21/2014 09:52 AM, 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

To clarify, though - do write Ruby code that will parse files, but
refrain from basing providers on Puppet's ParsedFile provider. It looks
neat enough, but just trust me on that one ;-)

Best,
Felix