On Thursday, August 8, 2013 1:45:44 AM UTC+2, Jakov Sosic wrote:
On 08/06/2013 01:17 AM, Alessandro Franceschi wrote:

That's quite nice, I like the reduced verbosity of the code and
essentiality of an all in one (init.pp) location for resources.
Yeah, I don't like to partition my module if it's quite simple, as this
one is.
For better reusability I'd provide a *_template option to manage the
templates of all the different files you manage, leaving as the default
the currently hardcoded ones.
Yeah, if I decide to publish the module on forge I will for sure add
those parameters too. We need to add Debian support in the house, and
after that I will maybe publish it.

TSM is a commercial product, we have in-house RPM/DEB packages (because
IBM provided ones are total shit), so without that packages module is
kinda useful.

This was my attempt to make the 'sample' module for our team to look at
when they code their own.

Also the backup_status and archive_status arguments follow an approach
that ... erm.. was revisited in the current version of the "ongoing
Can you point me to the revisited approach? I really like the current one
Well, it makes sense to try to follow, a resource_parameter naming, where
So to manage the service status (enable/ensure), probably is more natural
to use two different parameters, like service_ensure and service_enable
rather than one like service_status.
In your case the name of the parameters could be something like
backup_service_enable archive_service_ensure (incidentally this would
reduce even more the verbosity of your module).

The "current" status of the stdmod naming proposal is still :

there has been some concern about the amount of parameters or the need of
some of them, but I think it makes sense to give standard names for
different possible cases, even if you don't necessarily need to use them.

Jakov Sosic
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 38 of 44 | next ›
Discussion Overview
grouppuppet-users @
postedJun 17, '13 at 9:37a
activeOct 13, '13 at 9:43a



site design / logo © 2021 Grokbase