Puppet users - Feb 2008 - sharing module patches here?

Hi,

I sent a few patches here (probably stuck in moderation since I sent
them from my work email) regarding DavidS'' "virtual" module
(I mainly
worked on getting the module to create Xen domUs).

I think it''s a good idea to share the patches here to encourage public
development of modules, and this is not the first of my efforts in that
direction.. If it is not appropriate to do it here, please let me know
and I''ll stop. :)

Thanks,

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
                        - C. Edwin Baker
                        http://www.ad-mad.co.uk/quotes/freespeech.htm


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 15, 2008, at 11:00 AM, The Anarcat wrote:
> Hi,
>
> I sent a few patches here (probably stuck in moderation since I sent
> them from my work email) regarding DavidS'' "virtual"
module (I mainly
> worked on getting the module to create Xen domUs).
>
> I think it''s a good idea to share the patches here to encourage
public
> development of modules, and this is not the first of my efforts in  
> that
> direction.. If it is not appropriate to do it here, please let me know
> and I''ll stop. :)

Speaking as the moderator, I can''t recommend sending them from an  
unsubscribed user, because it makes work for me.  I usually just  
delete emails waiting for moderation, so it''s not a lot of work, but  
that''s probably not what you''re looking for.

I really am trying to get a module sharing site up, so we can use that  
instead of the wiki, but it''s not exactly been successful.

-- 
A classic is something that everybody wants to have read and nobody
wants to read. -- Mark Twain
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On Fri, Feb 15, 2008 at 12:34:14PM -0600, Luke Kanies
wrote:
> On Feb 15, 2008, at 11:00 AM, The Anarcat wrote:
> 
> > Hi,
> >
> > I sent a few patches here (probably stuck in moderation since I sent
> > them from my work email) regarding DavidS''
"virtual" module (I mainly
> > worked on getting the module to create Xen domUs).
> >
> > I think it''s a good idea to share the patches here to
encourage public
> > development of modules, and this is not the first of my efforts in  
> > that
> > direction.. If it is not appropriate to do it here, please let me know
> > and I''ll stop. :)
> 
> Speaking as the moderator, I can''t recommend sending them from an
> unsubscribed user, because it makes work for me. 
Of course.
> I usually just  delete emails waiting for moderation, so it''s not
a
> lot of work, but  that''s probably not what you''re looking
for.
Indeed. :)
> I really am trying to get a module sharing site up, so we can use that
> instead of the wiki, but it''s not exactly been successful.
 
Well, I don''t know exactly how the module sharing would work, but the
way I see it, even if there''s a git repo "out there", we
might still
need to throw patches around through email for people that (a) don''t
know how to use git/hg/svn/whatever SCM or (b) don''t have write access
to the repo...

So, my question remains, is this list appropriate?

A.


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

On Feb 15, 2008, at 2:14 PM, The Anarcat wrote:
>
> Well, I don''t know exactly how the module sharing would work, but
the
> way I see it, even if there''s a git repo "out there", we
might still
> need to throw patches around through email for people that (a)
don''t
> know how to use git/hg/svn/whatever SCM or (b) don''t have write
access
> to the repo...
>
> So, my question remains, is this list appropriate?

I would say no.  Maybe a puppet-modules list or something?

-- 
Getting caught is the mother of invention. --Robert Byrne
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

We could use the file-storage system in Google Groups. Tarred versions, or
something.

Alternatively I''d say a public Git repository.

Arjuna Christensen | Systems Engineer 
Maximum Internet Ltd
DDI: + 64 9 913 9683 | Ph: +64 9 915 1825 | Fax:: +64 9 300 7227
arjuna.christensen@maxnet.co.nz| www.maxnet.co.nz
-----Original Message-----
From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com]
On Behalf Of Luke Kanies
Sent: Saturday, 16 February 2008 9:21 a.m.
To: Puppet User Discussion
Subject: Re: [Puppet-users] sharing module patches here?

On Feb 15, 2008, at 2:14 PM, The Anarcat wrote:
>
> Well, I don''t know exactly how the module sharing would work, but
the
> way I see it, even if there''s a git repo "out there", we
might still
> need to throw patches around through email for people that (a)
don''t
> know how to use git/hg/svn/whatever SCM or (b) don''t have write
access
> to the repo...
>
> So, my question remains, is this list appropriate?

I would say no.  Maybe a puppet-modules list or something?

-- 
Getting caught is the mother of invention. --Robert Byrne
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Has anybody given any thoughts on how to separate module logic and
configuration?

As an example, I have an "ntpd" module that obviously takes care of
setting up ntp server and client services - this is obviously generic.
However my configuration (choosing the ntp server and assigning roles
to the various hosts clearly isn''t).

I''ve resorted to having a "config.pp" in each module that
specifies
the actual configuration details and including it from init.pp, but it
still doesn''t create proper separation between the two.

/peter

On 16/02/2008, Arjuna Christensen <arjuna.christensen@maxnet.co.nz>
wrote:
> We could use the file-storage system in Google Groups. Tarred versions, or
something.
>
> Alternatively I''d say a public Git repository.
>
> Arjuna Christensen | Systems Engineer
> Maximum Internet Ltd
> DDI: + 64 9 913 9683 | Ph: +64 9 915 1825 | Fax:: +64 9 300 7227
> arjuna.christensen@maxnet.co.nz| www.maxnet.co.nz
> -----Original Message-----
> From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies
> Sent: Saturday, 16 February 2008 9:21 a.m.
> To: Puppet User Discussion
> Subject: Re: [Puppet-users] sharing module patches here?
>
> On Feb 15, 2008, at 2:14 PM, The Anarcat wrote:
> >
> > Well, I don''t know exactly how the module sharing would work,
but the
> > way I see it, even if there''s a git repo "out
there", we might still
> > need to throw patches around through email for people that (a)
don''t
> > know how to use git/hg/svn/whatever SCM or (b) don''t have
write access
> > to the repo...
> >
> > So, my question remains, is this list appropriate?
>
>
> I would say no.  Maybe a puppet-modules list or something?
>
> --
> Getting caught is the mother of invention. --Robert Byrne
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

-- 
/peter

On Feb 18, 2008, at 9:40 AM, Peter Hoeg wrote:
> Has anybody given any thoughts on how to separate module logic and
> configuration?
>
> As an example, I have an "ntpd" module that obviously takes care
of
> setting up ntp server and client services - this is obviously generic.
> However my configuration (choosing the ntp server and assigning roles
> to the various hosts clearly isn''t).
>
> I''ve resorted to having a "config.pp" in each module
that specifies
> the actual configuration details and including it from init.pp, but it
> still doesn''t create proper separation between the two.

I''d probably have a separate module, mycompany or whatever, that  
subclassed or called as necessary.

-- 
Normal is getting dressed in clothes that you buy for work and driving
through traffic in a car that you are still paying for - in order to
get to the job you need to pay for the clothes and the car, and the
house you leave vacant all day so you can afford to live in it.
     -- Ellen DeGeneres
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

We have created some custom functions that look up things such as NTP
server from an external file (based on, say IP subnet of client say).
Is this what you have in mind?

Regards,
Derek
 

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Peter Hoeg
Sent: 18 February 2008 15:40
To: Puppet User Discussion
Subject: Re: [Puppet-users] sharing module patches here?

Has anybody given any thoughts on how to separate module logic and
configuration?

As an example, I have an "ntpd" module that obviously takes care of
setting up ntp server and client services - this is obviously generic.
However my configuration (choosing the ntp server and assigning roles to
the various hosts clearly isn''t).

I''ve resorted to having a "config.pp" in each module that
specifies the
actual configuration details and including it from init.pp, but it still
doesn''t create proper separation between the two.

/peter

------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

Le Mon, 18 Feb 2008 18:40:27 +0300, Peter Hoeg a écrit :
> Has anybody given any thoughts on how to separate module logic and
> configuration?
> 
> I've resorted to having a "config.pp" in each module that
specifies
> actual configuration details and including it from init.pp, but it still
> doesn't create proper separation between the two.
I put the commnon stuff in a class,
and the configurable stuff as a define that includes the class
(example below).

The site-specific settings go in site.pp; it is site.pp that pulls
together the complete configuration.


import "trac-common"
import "trac-webadmin"

class trac-account-manager {

        class deps {
                include trac-webadmin::plugin
        }

        class plugin {
                tracplugin { "accountmanager":
                        location =>
        "http://trac-hacks.org/svn/accountmanagerplugin/0.10/",
                        python_name => "acct_mgr",
                        enable => false, #we do it piecewise
                }

                include deps
        }

        define instance (
                #eg: "acct_mgr.http.HttpAuthStore"
                $password_store = nil,
                $trac_conf_dir = "/etc/trac"
        ) {

                trac::configlet { "$trac_conf_dir-account-manager":
                        short_name => "account-manager",
                        parent => "$trac_conf_dir",
                        contents => template("trac-account-manager/
trac.erb"),
                }

                include trac-account-manager::plugin
        }
}


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Derek,

not really.

What I am trying to achieve, is a clear separation between generic
functionality (the module) and my configuration. Let''s take an
example.

a) My generic ntpd module (modules/ntpd) consists of ntpd::base,
::client and ::server - this module should be possible to share with
everybody else who also needs ntpd functionality.

b) Let''s say I have one ntpd server at home called
"ntpd.domain.local"

c) In my "site.pp" I define a node which includes
"ntpd::server"
(master/manifests/site.pp)

d) I also need to tell all the remaining machines to use my server,
which means that I need to specify two things:

1) That my nodes include ntpd::client (easy enough in my "site.pp"}

2) The clients need to be told to talk to "ntpd.domain.local" - this
should be stored in my module (modules/ntpd) as it doesn''t apply to
anybody else. So where is the best place to put it?

If I understand Luke correctly, he advocates creating a separate
module called "my_config" and creating a class that inherits
ntpd::client and specifies the server in there - I''d imagine through a
"define".

But what does everybody else do?

On 18/02/2008, Derek.Whayman@barclayscapital.com
<Derek.Whayman@barclayscapital.com> wrote:
> We have created some custom functions that look up things such as NTP
> server from an external file (based on, say IP subnet of client say).
> Is this what you have in mind?
>
> Regards,
> Derek
>
>
> -----Original Message-----
> From: puppet-users-bounces@madstop.com
> [mailto:puppet-users-bounces@madstop.com] On Behalf Of Peter Hoeg
> Sent: 18 February 2008 15:40
> To: Puppet User Discussion
> Subject: Re: [Puppet-users] sharing module patches here?
>
> Has anybody given any thoughts on how to separate module logic and
> configuration?
>
> As an example, I have an "ntpd" module that obviously takes care
of
> setting up ntp server and client services - this is obviously generic.
> However my configuration (choosing the ntp server and assigning roles to
> the various hosts clearly isn''t).
>
> I''ve resorted to having a "config.pp" in each module
that specifies the
> actual configuration details and including it from init.pp, but it still
> doesn''t create proper separation between the two.
>
> /peter
>
> ------------------------------------------------------------------------
> For important statutory and regulatory disclosures and more information
about Barclays Capital, please visit our web site at http://www.barcap.com.
>
> Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.  Although
the Barclays Group operates anti-virus programmes, it does not accept
responsibility for any damage whatsoever that is caused by viruses being passed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of the Barclays Group.  Replies to this email may be
monitored by the Barclays Group for operational or business reasons.
>
> Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
> ------------------------------------------------------------------------
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

-- 
/peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 19 February 2008, Peter Hoeg wrote:
> Derek,
>
> not really.
>
> What I am trying to achieve, is a clear separation between generic
> functionality (the module) and my configuration. Let''s take an
> example.
You can have a look at my NTP module at 
http://git.black.co.at/?p=module-ntp;a=summary  which achieves exactly that. 
Usage looks like this:

On a local NTP client:
> include ntp
On the local NTP Servers:
 
> $ntp_servers = [ "ntp2b.mcc.ac.uk", "pluto.fips.at" ]
> include ntp
and on one server, set $ntp_local_stratum to something between 6 and 10 to 
avoid divergent clock drift when none of your servers can reach the 
$ntp_servers.

Personally, I buried most of this functionality in my own "Debian Best 
Practise" module, but that is really very site specific. 


Regards, David

- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHu++A/Pp1N6Uzh0URAssHAJ9hR6Ccg3qgyDRpI7tR+h4TmHOlCACeMu88
cMMLsTtIz2wXitIo4LBAp64=tkeY
-----END PGP SIGNATURE-----

Hi
> But what does everybody else do?
I try to do the following, but was never sure if I''m doing it the
correct way. However I think there seem to be multiple ways and more
than one best solution. But if somebody thinks my solution is bad,
please let me know.

So to my solution:

1. Modules, which are completely generic and could be reused by others.
Well some maybe not, however I try to have no specific configuration in
there, but didn''t yet reach the point to release them.

2. Specific configurations of the modules in sub-class of the module (if
this makes sense) in a file in manifests/classes/$module.pp. This could
be maybe something like that:

class sshd::global inherits sshd { #sshd the module, conaints
sshd-package and service definitions.
	sshd::sshd_config{sshd_global: allowed_users => "root" } # a
define
from the module to deploy the appropriate sshd-config.
}

3. A File called config.pp in manifests which contains plenty of the
specific config-classes and groups them together where it makes sense.
For example there is a basic config class:

class config::base {
	include sshd::global
	include someOtherClasses
}

4. and finally in the site.pp in the node sections, I just include the
specific config::* classes.

node foobar {
	include config::base
	include config::apache::foobar #config class which groups together the
different classes for the apache configuration for a foobar setup.
}

any notes on that? I''d also be interested in other solutions. Maybe we
could also setup a Wikipage about that topic, as I was really thinking a
lot and many times, what might be the best way to do it.

thanks and greets

Pete

On Wed, Feb 20, 2008 at 10:14:30AM +0100, David Schmitt
wrote:
> On Tuesday 19 February 2008, Peter Hoeg wrote:
> > Derek,
> >
> > not really.
> >
> > What I am trying to achieve, is a clear separation between generic
> > functionality (the module) and my configuration. Let''s take
an
> > example.
> 
> You can have a look at my NTP module at 
> http://git.black.co.at/?p=module-ntp;a=summary  which achieves exactly
that.
> Usage looks like this:
> 
> On a local NTP client:
> 
> > include ntp
> 
> On the local NTP Servers:
>  
> > $ntp_servers = [ "ntp2b.mcc.ac.uk",
"pluto.fips.at" ]
> > include ntp
> 
> and on one server, set $ntp_local_stratum to something between 6 and 10 to 
> avoid divergent clock drift when none of your servers can reach the 
> $ntp_servers.
> 
> Personally, I buried most of this functionality in my own "Debian Best
> Practise" module, but that is really very site specific. 
I also favour such practices, although most of my customizations are in
my site.pp ($munin_allow, for example) and my "koumbit" (the
equivalent
of your David^WDebian Best Practices) module is designed to be as
portable as possible:

https://hg.koumbit.net/module-koumbit/file/tip/manifests/init.pp

Although now looking at those 20 lines code, there are really
site-specific stuff... but the idea for me is to keep site-specific
stuff outside of the modules and isolate it in variables.

-- 
Premature optimization is the root of all evil
                        - Donald Knuth


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users