[Puppet Users] Re: Module Standards
Except foo::_files is a syntax error..
Kent
2008/9/23 Kenton Brede [EMAIL PROTECTED]:
I vote for foo::_files.
Kent
2008/9/22 Digant C Kasundra [EMAIL PROTECTED]:
When things are fairly small, it isn't an issue and certainly documentation
is key. I'm just very OCD about conventions and naming and I like having
things named in ways that it is explicit to the purpose. Generally, it is
fairly easy to tell that ssh::files would most likely be a class that deals
with the files associated with setting up ssh and not some variation of how
ssh is setup. But, in general, when I see foo::bar, I assume bar is a
subclass (ergo derivative of) foo. But since both fragments and subclasses
are useful in Puppet, for those that so feel inclined (and I think the
Puppet community has expressed interest in consistent style and practice
guides to grow the community closer), I think a naming convention to
differentiate is valuable, even if just for us OCD folks. :)
- Original Message -
From: Kenton Brede [EMAIL PROTECTED]
To: puppet-users@googlegroups.com
Sent: Tuesday, September 16, 2008 12:40:09 PM GMT -08:00 US/Canada Pacific
Subject: [Puppet Users] Re: Module Standards
2008/9/16 Digant C Kasundra [EMAIL PROTECTED]:
So my proposal is if there is need or want to break up large classes, the
fragment class (i.e. foo::files) be named specifically in a way that makes
it clear it is not a complete and functional class but only a fragment.
Such a naming convention might call for something like foo::_files or
foo::inc::files. I would like to open this topic up to discussion to the
greater community (you guys) and see what you think.
I guess I could see this if the classes were scattered throughout
/manifests/.
I approach module building the same way in terms of breaking the classes
into smaller pieces. I guess I don't see a specific need for a
fragment designation.
I usually create a class named foo in init.pp and include the sub
classes there:
class files {
# include files class groups
include files::all
include files::rhel5
# include files class hosts
include files::host1
}
In site.pp I just include foo. I document all this in the README
and comment the init.pp file. It just seems natural to me that way.
My setup isn't probably as complex as some so maybe I'm missing
something..
Kent
--
Digant C Kasundra [EMAIL PROTECTED]
Technical Lead, ITS Unix Systems and Applications, Stanford University
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Trying to gem install mysql
Thanks for the answers, but they raise more questions, if I may.
1. For puppet to make use of a .gemrc, should it be in root's homedir?
2, When Ashley states thatI can use exec to manage the install, I get it,
but that begs the question of whether Package truly can't add arguments.
Does anybody know.
I'm not a Ruby guy at all, just a sysadmin in a ruby shop, so some of this
is a bit new to me.
Thanks,
/edg
On Mon, Sep 22, 2008 at 9:42 PM, Brian Gupta [EMAIL PROTECTED] wrote:
On Mon, Sep 22, 2008 at 8:52 PM, Blake Barnett [EMAIL PROTECTED] wrote:
I'd also recommend using a .gemrc file (managed by puppet!) to add --
no-rdoc --no-ri since it's usually what everyone wants as the
default, especially in production.
-Blake
On Sep 22, 2008, at 1:46 PM, Ashley Penney wrote:
You could just do exec { gem-install-mysql: command = gem install
mysql --no-rdoc --no-ri -- --with-mysql-config=/usr/bin/mysql_config,
}
Then you can rely on require = Exec[gem-install-mysql] elsewhere.
On Mon, Sep 22, 2008 at 2:15 PM, Ed Greenberg
[EMAIL PROTECTED] wrote:
I need to do this in puppet:
gem install mysql --no-rdoc --no-ri -- --with-mysql-config=/usr/bin/
mysql_config
Not sure how to express any of the arguments to gem install in my
puppet Package stanza.
can somebody explain?,
more ~/.gemrc
update: -B 10
install: -B 10
gem: --no-ri --no-rdoc
--
- Brian Gupta
http://opensolaris.org/os/project/nycosug/
http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Using git to manage puppet manifests.
On Thu, Sep 18, 2008 at 6:56 AM, Leah [EMAIL PROTECTED] wrote: I've set up puppet and had it running, but never bothered to set up an version control. I've decided it is time to get it all in version control as the system is about to become production and I need to keep track of who is changing things and what is being changed. Good plan. I am looking at storing all my configs in Git as that seems to be the version control of choice here and it's time I learned it. I was wondering what other people do to automatically update their puppet server with the latest version from git. I was looking at using some sort of git hook, but I'm not sure how to implement it efficiently and securely with a shared repository on another server. I went looking on the wiki, but could only find information about doing this with subversion. I can't even say how bad an idea it is to automatically update from your version control system. Always make a conscious decision to push changes to production. What we do is we have several environments: one defined for each person working on puppet (2 of us for now), one staging environment, and one production environment. When we bootstrap machines, they get a puppet.conf that puts them into the production environment. The various environments point to separate directories, each of which is a working copy (we use SVN, but this is totally about process, not specific software). The developer directories are usually a checkout of a branch. The staging directory is the checkout of whatever we propose to put into production. The production directory is a checkout of a specific tag. A developer who wants to add something does development in his own environment and points his development machine(s) or VM(s) at this environment. Once he is ready he asks the release manager (me) to stage the changes. I usually merge the branch to trunk and tag it, then update the staging environment to this tag. We have a representative sample of our machines set up with a second instance of puppet, running with --noop, set to the staging environment. We wait a couple of hours (currently long enough to verify our setup, this time may grow in the future) and if we don't see anything scary in the logs from these machines we update the production environment to this tag. Otherwise, we tell the developer to keep trying and revert the change in the repository. --Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
