Hello everyone, A long time ago, I posted the Stanford Best Practices and I''ve gone through and updated it today. I''d like to have people go through it and see if we can strip out some Stanford specific stuff and tag this as an official best practice. I think an official best practice will be important as more and more people consider making shareable modules, etc (mostly the syntax stuffs -- file hierarchy doesn''t matter except for modules, which is already defined quite well in the Module Organization page). <http://reductivelabs.com/trac/puppet/wiki/StanfordPuppetBestPractices>
On May 7, 2007, at 6:31 PM, Digant C Kasundra wrote:> Hello everyone, > > A long time ago, I posted the Stanford Best Practices and I''ve gone > through > and updated it today. I''d like to have people go through it and > see if we > can strip out some Stanford specific stuff and tag this as an > official best > practice. I think an official best practice will be important as > more and > more people consider making shareable modules, etc (mostly the syntax > stuffs -- file hierarchy doesn''t matter except for modules, which is > already defined quite well in the Module Organization page). > > <http://reductivelabs.com/trac/puppet/wiki/ > StanfordPuppetBestPractices>I agree that a document like this can have a huge impact on the community. We should also make it more prominent, since it looks like it should be one of the first place new users should look, as it can give them a clear idea of how to organize their architecture and how to talk about the system. -- Measure with a micrometer. Mark with chalk. Cut with an axe. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On May 8, 2007 10:59:57 AM -0500 Luke Kanies <luke@madstop.com> wrote:> On May 7, 2007, at 6:31 PM, Digant C Kasundra wrote: > >> Hello everyone, >> >> A long time ago, I posted the Stanford Best Practices and I''ve gone >> through >> and updated it today. I''d like to have people go through it and >> see if we >> can strip out some Stanford specific stuff and tag this as an >> official best >> practice. I think an official best practice will be important as >> more and >> more people consider making shareable modules, etc (mostly the syntax >> stuffs -- file hierarchy doesn''t matter except for modules, which is >> already defined quite well in the Module Organization page). >> >> <http://reductivelabs.com/trac/puppet/wiki/ >> StanfordPuppetBestPractices> > > I agree that a document like this can have a huge impact on the > community. We should also make it more prominent, since it looks > like it should be one of the first place new users should look, as it > can give them a clear idea of how to organize their architecture and > how to talk about the system.Want me to add it to the Main on the right nav bar?
On May 8, 2007, at 12:26 PM, Digant C Kasundra wrote:> > Want me to add it to the Main on the right nav bar?Yeah. -- Some people are afraid of heights. I''m afraid of widths. -- Stephen Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 7 May , 2007, at 19:31, Digant C Kasundra wrote:> Hello everyone, > > A long time ago, I posted the Stanford Best Practices and I''ve gone > through > and updated it today. I''d like to have people go through it and > see if we > can strip out some Stanford specific stuff and tag this as an > official best > practice. I think an official best practice will be important as > more and > more people consider making shareable modules, etc (mostly the syntax > stuffs -- file hierarchy doesn''t matter except for modules, which is > already defined quite well in the Module Organization page). > > <http://reductivelabs.com/trac/puppet/wiki/ > StanfordPuppetBestPractices>You''ve done a great thing here, thanks. I agree, this is an essential part of successful documentation and tutorial for us. It''s definitely well worth genericizing this document for general consumption. In the absence of another volunteer, I can certainly commit to converting the document when the opportunity arises, but help is always appreciated. Thanks again, Digant.
--On May 8, 2007 2:50:23 PM -0400 "Benjamin C. Kite" <ben@reductivelabs.com> wrote:> You''ve done a great thing here, thanks. I agree, this is an > essential part of successful documentation and tutorial for us. It''s > definitely well worth genericizing this document for general > consumption. In the absence of another volunteer, I can certainly > commit to converting the document when the opportunity arises, but > help is always appreciated. > > Thanks again, Digant.I''ll take a first pass at stripping out the Stanford-esque stuff and then I figured the rest of the discussion could take place on this list and I''d stay on top of committing the decisions back to the page.
Hi, Digant C Kasundra wrote:> --On May 8, 2007 2:50:23 PM -0400 "Benjamin C. Kite" > <ben@reductivelabs.com> wrote: > >> You''ve done a great thing here, thanks. I agree, this is an >> essential part of successful documentation and tutorial for us. It''s >> definitely well worth genericizing this document for general >> consumption. In the absence of another volunteer, I can certainly >> commit to converting the document when the opportunity arises, but >> help is always appreciated. >> >> Thanks again, Digant. > > I''ll take a first pass at stripping out the Stanford-esque stuff and then I > figured the rest of the discussion could take place on this list and I''d > stay on top of committing the decisions back to the page.I''ve gone a step and a half[1] further and knocked out a script to generate the directories and rationale (documentation) for the file hierarchy. Let me know what you think, -- Bob [1] Or a half-step further for using perl where tar would be sufficient. :) At least it''s *clean* perl (passes strict, warn, perltidy, and perlcritic checks.) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 8, 2007, at 4:09 PM, Bob Apthorpe wrote:> I''ve gone a step and a half[1] further and knocked out a script to > generate the directories and rationale (documentation) for the file > hierarchy. Let me know what you think, > > -- Bob > > [1] Or a half-step further for using perl where tar would be > sufficient. > :) At least it''s *clean* perl (passes strict, warn, perltidy, and > perlcritic checks.)This could be a pretty simple Puppet manifest... -- 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
Luke Kanies wrote:> On May 8, 2007, at 4:09 PM, Bob Apthorpe wrote: > >> I''ve gone a step and a half[1] further and knocked out a script to >> generate the directories and rationale (documentation) for the file >> hierarchy. Let me know what you think, >> >> -- Bob >> >> [1] Or a half-step further for using perl where tar would be >> sufficient. >> :) At least it''s *clean* perl (passes strict, warn, perltidy, and >> perlcritic checks.) > > This could be a pretty simple Puppet manifest...True, but you''d have to already have puppet set up to make use of it :) Or would you...? -- Bob
On May 8, 2007, at 4:24 PM, Bob Apthorpe wrote:> > True, but you''d have to already have puppet set up to make use of > it :) > > Or would you...?Nope. This sets up the master so that puppetmasterd can run, but you can just use ''puppet <init.pp>'' to run the script. Really, that''s a great idea -- shipping packages with a bunch of initialization manifests that can set things up in recommended ways. It''d require packaging support, but we can make it easy outside of packaging, too. -- The Chico, California, City Council enacted a ban on nuclear weapons, setting a $500 fine for anyone detonating one within city limits. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On May 8, 2007 4:09:34 PM -0500 Bob Apthorpe <apthorpe@cynistar.net> wrote:> Hi, > > Digant C Kasundra wrote: >> --On May 8, 2007 2:50:23 PM -0400 "Benjamin C. Kite" >> <ben@reductivelabs.com> wrote: >> >>> You''ve done a great thing here, thanks. I agree, this is an >>> essential part of successful documentation and tutorial for us. It''s >>> definitely well worth genericizing this document for general >>> consumption. In the absence of another volunteer, I can certainly >>> commit to converting the document when the opportunity arises, but >>> help is always appreciated. >>> >>> Thanks again, Digant. >> >> I''ll take a first pass at stripping out the Stanford-esque stuff and >> then I figured the rest of the discussion could take place on this list >> and I''d stay on top of committing the decisions back to the page. > > I''ve gone a step and a half[1] further and knocked out a script to > generate the directories and rationale (documentation) for the file > hierarchy. Let me know what you think, > > -- Bob > > [1] Or a half-step further for using perl where tar would be sufficient. > :) At least it''s *clean* perl (passes strict, warn, perltidy, and > perlcritic checks.)Nice script. I''ve updated the page to remove our Stanford specific stuff: <http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice>
Hi all Nice timing, I am creating a SVN repository and directory structure right now so a few ideas are very useful. Having been spoiled in my formative years by this sort of thing, what I''ve created is a set of recursive Makefiles that support ''make'', ''make test'' and ''make install''. E.g. /trunk/master/Makefile common.mk /trunk/master/manifests/Makefile Etc. "make install" is a dependent upon "make test", which is just a simple "puppet --noop site.pp". Simple "make" does the Ruby and Perl syntax checks (-c) etc. It''s a way of idiot-proofing the installation of changes. We will have a large team of SAs using this eventually. I haven''t yet digested all of the PuppetBestPractices document, but what the above currently relies upon is the directory structure within the SVN/CVS working copy being the same as the manifest directory structure once installed. Is this still the case with the layout proposed? And do we have some configuration file with the correct (relative) paths in? Also good to see the modularisation of functionality (i.e. templates and manifests grouped together as per ModuleOrganisation) within the repo even if it is installed into disparate directories - even if it makes the above a little trickier. I''d prefer not to have to ''make install'' to a temporary staging area to run the syntax check on, however this may or may not conflict with the above requirement. Another thing we have to deal with the is the permanent need for Hacking/Test/Development/Production configurations. I intend to have Hacking & Test running on the same host in the lab, and Development & Prod environments "out there". This needs to be fixed into the repository somewhere, although I think that''ll be done by having different SVN branches - although I need to put in different port numbers somewhere. Finally, I see a couple of omissions from the tree * Own & 3rd party Functions * Custom Facts Any thoughts as to where these should go? Best regards, Derek ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
--On May 9, 2007 10:55:49 AM +0100 Derek.Whayman@barclayscapital.com wrote:> I haven''t yet digested all of the PuppetBestPractices document, but what > the above currently relies upon is the directory structure within the > SVN/CVS working copy being the same as the manifest directory structure > once installed. Is this still the case with the layout proposed? And > do we have some configuration file with the correct (relative) paths in?Yup. You could do an svn checkout of our Puppet trunk straight into /var/lib/puppet. The Best Practice assumes your config files are setup accordingly.> Also good to see the modularisation of functionality (i.e. templates and > manifests grouped together as per ModuleOrganisation) within the repo > even if it is installed into disparate directories - even if it makes > the above a little trickier.The trickiest part for me is having to do an import of each individual module I want to use. But I believe there was some agreement on how to remedy that which will be in a future release.> Another thing we have to deal with the is the permanent need for > Hacking/Test/Development/Production configurations. I intend to have > Hacking & Test running on the same host in the lab, and Development & > Prod environments "out there". This needs to be fixed into the > repository somewhere, although I think that''ll be done by having > different SVN branches - although I need to put in different port > numbers somewhere.Same here. This has been somewhat of a hassle. So far, what I''ve done is create a dev/test puppetmaster and all I do is add an entry into /etc/hosts for each dev/test client server to point to the dev/test master server (I refer to my master as "puppet" and so I just add an entry for "puppet" with a different ip).> > Finally, I see a couple of omissions from the tree > > * Own & 3rd party Functions > * Custom Facts > > Any thoughts as to where these should go?Nope. I was hoping for some kind of "non-standard extras" directory for Facter to search in. So far, additional facts have to go into /usr/lib/ruby/1.8/facter/ IIRC. And 3rd party functions and plugin-types need a best practice, for certain.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 May 2007, Digant C Kasundra wrote:> --On May 9, 2007 10:55:49 AM +0100 Derek.Whayman@barclayscapital.com wrote: > > Finally, I see a couple of omissions from the tree > > > > * Own & 3rd party Functions > > * Custom Facts > > > > Any thoughts as to where these should go? > > Nope. I was hoping for some kind of "non-standard extras" directory for > Facter to search in. So far, additional facts have to go into > /usr/lib/ruby/1.8/facter/ IIRC.Custom facts go to "$rubysitedir/facter". On Debian this is /usr/local/lib/site_ruby/1.8/facter/, which doesn''t conflict with packaged software due to being under /usr/local.> And 3rd party functions and plugin-types need a best practice, for certain.Those should be either transported as modules or could be also installed to $rubysitedir. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQirp/Pp1N6Uzh0URAvufAJ920OJ3NudB2OX29MvapgG1nGrR3QCggbhO 9pouwxK+gs+6sIyTxVLtSYE=0RNK -----END PGP SIGNATURE-----
On May 9, 2007, at 11:29 AM, Digant C Kasundra wrote:> --On May 9, 2007 10:55:49 AM +0100 > Derek.Whayman@barclayscapital.com wrote: >> Also good to see the modularisation of functionality (i.e. >> templates and >> manifests grouped together as per ModuleOrganisation) within the repo >> even if it is installed into disparate directories - even if it makes >> the above a little trickier. > > The trickiest part for me is having to do an import of each individual > module I want to use. But I believe there was some agreement on > how to > remedy that which will be in a future release.Indeed; that''s on the docket for elmo.>> Another thing we have to deal with the is the permanent need for >> Hacking/Test/Development/Production configurations. I intend to have >> Hacking & Test running on the same host in the lab, and Development & >> Prod environments "out there". This needs to be fixed into the >> repository somewhere, although I think that''ll be done by having >> different SVN branches - although I need to put in different port >> numbers somewhere. > > Same here. This has been somewhat of a hassle. So far, what I''ve > done is > create a dev/test puppetmaster and all I do is add an entry into / > etc/hosts > for each dev/test client server to point to the dev/test master > server (I > refer to my master as "puppet" and so I just add an entry for > "puppet" with > a different ip).We talked about this a while back, multiple times, actually, with the last thread resulting in modules, since that was half of the discussion. The other half, though, was talk of ''releases'' (to use Debian''s terms) or ''environments'' (to use terms from Rails). It seems like a good idea to me, but now that we''ve got modules, it''s less clear how this would work -- previously, I would have just had a checked out manifest set per environment. I suppose with the newly consolidated configuration files, we could have one configuration section per environment, and then make ''environment'' a fundamental trait of nodes, although I think this would only work with an external node classification tool: # puppetmasterd.conf [main] default_env = prod [prod] manifest = /etc/puppet/manifests/prod.pp modulepath = /usr/share/puppet/modules:/usr/share/puppet/prod/modules fileserverconfig = /etc/puppet/fileserver_prod.conf ... As long as the fileserver had access to the node''s environment, you shouldn''t need to specify it during file copies -- i.e., hostA gets its configuration compiled and the file server stores the fact that hostA is in ''prod'' (in a db or whatever); when hostA connects to retrieve a file, the fileserver checks the environment and translates the file appropriately. This seems pretty clear and easy now that I''m thinking about node classification as a separate problem. Do people think this is a good idea? I personally like it a lot, but I''ve gotten a less-than-enthusiastic reception on it before.>> >> Finally, I see a couple of omissions from the tree >> >> * Own & 3rd party Functions >> * Custom Facts >> >> Any thoughts as to where these should go? > > Nope. I was hoping for some kind of "non-standard extras" > directory for > Facter to search in. So far, additional facts have to go into > /usr/lib/ruby/1.8/facter/ IIRC.I can modify Facter to look in ''puppet/plugins'', so custom facts could be thrown in with the rest of the plugins. All custom stuff should go in the plugins dir, once it exists[1]. 1 - https://reductivelabs.com/trac/puppet/ticket/621 -- Barrow''s first law: Any Universe simple enough to be understood is too simple to produce a mind able to understand it. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On May 9, 2007 10:11:21 PM +0200 David Schmitt <david@schmitt.edv-bus.at> wrote:>> And 3rd party functions and plugin-types need a best practice, for >> certain. > > Those should be either transported as modules or could be also installed > to $rubysitedir.How do you transport plugin-types as modules? I was thinking that would be a good idea but didn''t know that was already supported.
--On May 9, 2007 3:40:58 PM -0500 Luke Kanies <luke@madstop.com> wrote:> I can modify Facter to look in ''puppet/plugins'', so custom facts > could be thrown in with the rest of the plugins. All custom stuff > should go in the plugins dir, once it exists[1]. > > 1 - https://reductivelabs.com/trac/puppet/ticket/621I thought that already existed. Can''t you specify a pluginpath?
On May 9, 2007, at 4:08 PM, Digant C Kasundra wrote:> --On May 9, 2007 3:40:58 PM -0500 Luke Kanies <luke@madstop.com> > wrote: > >> I can modify Facter to look in ''puppet/plugins'', so custom facts >> could be thrown in with the rest of the plugins. All custom stuff >> should go in the plugins dir, once it exists[1]. >> >> 1 - https://reductivelabs.com/trac/puppet/ticket/621 > > I thought that already existed. Can''t you specify a pluginpath?You can, but the functionality is going to change. Right now, in another horrid turn of terminology, ''plugins'' are custom types loaded from the server. This means no providers, no reports, not server functions, nothing. Instead, ''plugins'' will become a generic term, meaning anything you can load but that doesn''t ship with Puppet. It will be done akin to modules -- there''ll be a plugin path, with multiple directories supported, and the autoload.rb class, which handles all plugin loading, will automatically search through the plugin path for any file you''re trying to load (in addition to searching through $LOAD_PATH in ruby). The last step is to make it easy to copy a plugin directory from the server to the client, so clients could get new facts, providers, and types. This should be easy once Autoload knows how to look plugin directories. I expect I''ll also make a ''plugin reference'' that you can use to figure out what types of plugins can be loaded. -- The Washington Bullets are changing their name. The owners no longer want their team''s name to be associated with crime. So from now on the team will be known as The Bullets. -- Paul Harvey, quoting Argus Hamilton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 May 2007, Luke Kanies wrote:> On May 9, 2007, at 11:29 AM, Digant C Kasundra wrote: > > --On May 9, 2007 10:55:49 AM +0100 > > > > Derek.Whayman@barclayscapital.com wrote: > >> Also good to see the modularisation of functionality (i.e. > >> templates and > >> manifests grouped together as per ModuleOrganisation) within the repo > >> even if it is installed into disparate directories - even if it makes > >> the above a little trickier. > > > > The trickiest part for me is having to do an import of each individual > > module I want to use. But I believe there was some agreement on > > how to > > remedy that which will be in a future release. > > Indeed; that''s on the docket for elmo. > > >> Another thing we have to deal with the is the permanent need for > >> Hacking/Test/Development/Production configurations. I intend to have > >> Hacking & Test running on the same host in the lab, and Development & > >> Prod environments "out there". This needs to be fixed into the > >> repository somewhere, although I think that''ll be done by having > >> different SVN branches - although I need to put in different port > >> numbers somewhere. > > > > Same here. This has been somewhat of a hassle. So far, what I''ve > > done is > > create a dev/test puppetmaster and all I do is add an entry into / > > etc/hosts > > for each dev/test client server to point to the dev/test master > > server (I > > refer to my master as "puppet" and so I just add an entry for > > "puppet" with > > a different ip). > > We talked about this a while back, multiple times, actually, with the > last thread resulting in modules, since that was half of the discussion. > > The other half, though, was talk of ''releases'' (to use Debian''s > terms) or ''environments'' (to use terms from Rails). > > It seems like a good idea to me, but now that we''ve got modules, it''s > less clear how this would work -- previously, I would have just had a > checked out manifest set per environment. I suppose with the newly > consolidated configuration files, we could have one configuration > section per environment, and then make ''environment'' a fundamental > trait of nodes, although I think this would only work with an > external node classification tool: > > # puppetmasterd.conf > [main] > default_env = prod > > [prod] > manifest = /etc/puppet/manifests/prod.pp > modulepath = /usr/share/puppet/modules:/usr/share/puppet/prod/modules > fileserverconfig = /etc/puppet/fileserver_prod.conf > ... > > As long as the fileserver had access to the node''s environment, you > shouldn''t need to specify it during file copies -- i.e., hostA gets > its configuration compiled and the file server stores the fact that > hostA is in ''prod'' (in a db or whatever); when hostA connects to > retrieve a file, the fileserver checks the environment and translates > the file appropriately. > > This seems pretty clear and easy now that I''m thinking about node > classification as a separate problem. > > Do people think this is a good idea? I personally like it a lot, but > I''ve gotten a less-than-enthusiastic reception on it before.That was what I had in mind while the module stuff was hashed out. Actually, with external node configuration and modules you probably can do away with the "manifest=" parameter too, since all classes are in a module on the path. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQjpC/Pp1N6Uzh0URAvETAJ9igrh8iostlGJBbZ4JtGMJQOtYsgCeLjvC K5kq9m6f77lq7+ruWXmTsqo=1ucd -----END PGP SIGNATURE-----
--On May 9, 2007 11:16:50 PM +0200 David Schmitt <david@schmitt.edv-bus.at> wrote:> That was what I had in mind while the module stuff was hashed out. > > Actually, with external node configuration and modules you probably can > do away with the "manifest=" parameter too, since all classes are in a > module on the path.Is elmo going to require external node configuration? B/c I''m actually not interested in that at the moment. Also, is there some move to make everything module like in terms of file-layout/organization? That is certainly interesting (I''m not opposed to that just the first I''d heard of this).
On May 9, 2007, at 4:16 PM, David Schmitt wrote:> That was what I had in mind while the module stuff was hashed out. > > Actually, with external node configuration and modules you probably > can do > away with the "manifest=" parameter too, since all classes are in a > module on > the path.Yeah, that''s a good point. -- A complex system that works is invariably found to have evolved from a simple system that works. -- John Gaule --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 9, 2007, at 4:22 PM, Digant C Kasundra wrote:> Is elmo going to require external node configuration? B/c I''m > actually not > interested in that at the moment. Also, is there some move to make > everything module like in terms of file-layout/organization? That is > certainly interesting (I''m not opposed to that just the first I''d > heard of > this).The node support as it exists now will work for at least a few releases; I''m not going to be that harsh on backward compatibility. I expect that everyone will quickly want to move to the external node tool once it becomes available, simply because it will be so much better and provide so much more functionality, but I don''t expect to require it immediately. What else do you want to be organized module-like? -- It is odd, but on the infrequent occasions when I have been called upon in a formal place to play the bongo drums, the introducer never seems to find it necessary to mention that I also do theoretical physics. -- Richard Feynman --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 May 2007, Luke Kanies wrote:> On May 9, 2007, at 4:08 PM, Digant C Kasundra wrote: > > --On May 9, 2007 3:40:58 PM -0500 Luke Kanies <luke@madstop.com> > > > > wrote: > >> I can modify Facter to look in ''puppet/plugins'', so custom facts > >> could be thrown in with the rest of the plugins. All custom stuff > >> should go in the plugins dir, once it exists[1]. > >> > >> 1 - https://reductivelabs.com/trac/puppet/ticket/621 > > > > I thought that already existed. Can''t you specify a pluginpath? > > You can, but the functionality is going to change. > > Right now, in another horrid turn of terminology, ''plugins'' are > custom types loaded from the server. This means no providers, no > reports, not server functions, nothing. > > Instead, ''plugins'' will become a generic term, meaning anything you > can load but that doesn''t ship with Puppet. It will be done akin to > modules -- there''ll be a plugin path, with multiple directories > supported, and the autoload.rb class, which handles all plugin > loading, will automatically search through the plugin path for any > file you''re trying to load (in addition to searching through > $LOAD_PATH in ruby). > > The last step is to make it easy to copy a plugin directory from the > server to the client, so clients could get new facts, providers, and > types. This should be easy once Autoload knows how to look plugin > directories. > > I expect I''ll also make a ''plugin reference'' that you can use to > figure out what types of plugins can be loaded.Is there any reason not to fold this into the module stuff? I would think that this would reduce the amount of *_paths where you''d have to look at stuff and more complex modules surely will want to ship ruby and puppet code side-by-side. (Think nagios) Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQkmA/Pp1N6Uzh0URAp2XAJ0US28Gr4eoIBO5RTZxquAiMNUGtgCgpECg RFEwm6+frM5rm5u+iYW6ZOM=lrza -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 May 2007, Digant C Kasundra wrote:> --On May 9, 2007 11:16:50 PM +0200 David Schmitt <david@schmitt.edv-bus.at> > > wrote: > > That was what I had in mind while the module stuff was hashed out. > > > > Actually, with external node configuration and modules you probably can > > do away with the "manifest=" parameter too, since all classes are in a > > module on the path. > > Is elmo going to require external node configuration? B/c I''m actually not > interested in that at the moment.Of course I can''t speak for Luke, but I haven''t seen anything in the direction of making external node configuration mandatory. Luke wished to create a new syntax for more flexible node configuration, but I think this will be only after there is a possibility for ENC.> Also, is there some move to make > everything module like in terms of file-layout/organization? That is > certainly interesting (I''m not opposed to that just the first I''d heard of > this).There is not much in puppet (node configuration, ruby stuff (see my other mail)) which cannot be put into modules. So there should be nothing to hinder you to do so. I think it will be just much more comfortable to put everything into modules instead of manipulating big directories of unrelated .pp files. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGQkpw/Pp1N6Uzh0URAmqLAJ9gGIoAHEDVkCIVdTDFF11fdExP7wCeMP8R q3IE4xprCrUHTtaTXxG+l3I=iBvD -----END PGP SIGNATURE-----
--On May 9, 2007 5:09:18 PM -0500 Luke Kanies <luke@madstop.com> wrote:> On May 9, 2007, at 4:22 PM, Digant C Kasundra wrote: > >> Is elmo going to require external node configuration? B/c I''m >> actually not >> interested in that at the moment. Also, is there some move to make >> everything module like in terms of file-layout/organization? That is >> certainly interesting (I''m not opposed to that just the first I''d >> heard of >> this). > > The node support as it exists now will work for at least a few > releases; I''m not going to be that harsh on backward compatibility. > > I expect that everyone will quickly want to move to the external node > tool once it becomes available, simply because it will be so much > better and provide so much more functionality, but I don''t expect to > require it immediately.That''s good to hear. I''m not sure I find that idea all that interesting at the moment. Particularly b/c it creates a Disaster Recovery feedback loop if our directory servers require Puppet to build and Puppet requires the directory servers to work.> > What else do you want to be organized module-like?The comment about not needing the manifest directive made me think that is what was happening:> Actually, with external node configuration and modules you probably > can do > away with the "manifest=" parameter too, since all classes are in a > module on > the path.All of our classes are not in modules and there is no plan to make that the case. We have classes the define systems for our clients and services that we run. Though perhaps best practice might dictate that we should organize those as modules as well. I wouldn''t be against that idea, particular if I can point puppet at a directory and tell it any class used will be in a module defined in this directory or one of its subdirectories.
--On May 10, 2007 12:25:51 AM +0200 David Schmitt <david@schmitt.edv-bus.at> wrote:> There is not much in puppet (node configuration, ruby stuff (see my other > mail)) which cannot be put into modules. So there should be nothing to > hinder you to do so. I think it will be just much more comfortable to > put everything into modules instead of manipulating big directories of > unrelated .pp files. >Yeah, it idea is very tempting. It would mean I''d just have subdirectories of modules for the various ways we organize things. So, lots of restructuring but ultimately more maintainable.
On May 9, 2007, at 4:07 PM, Digant C Kasundra wrote:> > How do you transport plugin-types as modules? I was thinking that > would be > a good idea but didn''t know that was already supported.At this point you can''t -- there''s no facility for storing anything other than templates, manifests, and files in modules. Now that I think about it, there isn''t even a feature request open for anything else, even though we''ve talked about. Looks like we need a minor project to integrate plugins and modules. -- Never esteem anything as of advantage to you that will make you break your word or lose your self-respect. -- Marcus Aurelius Antoninus --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 9, 2007, at 5:21 PM, David Schmitt wrote:> > Is there any reason not to fold this into the module stuff? I would > think that > this would reduce the amount of *_paths where you''d have to look at > stuff and > more complex modules surely will want to ship ruby and puppet code > side-by-side. (Think nagios)I could see a ''plugins'' directory in the modules, but the problem is still there, you''ve just added other plugin sources. Each plugin would still need to be in a subdirectory -- e.g., you wouldn''t be able to mix your transaction report processors with your parser functions -- and you''d need the ability to copy some of those files (e.g., new types and providers) to the client''s plugins directory. -- The only really good place to buy lumber is at a store where the lumber has already been cut and attached together in the form of furniture, finished, and put inside boxes. --Dave Barry --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 9, 2007, at 5:37 PM, Digant C Kasundra wrote:> > That''s good to hear. I''m not sure I find that idea all that > interesting at > the moment. Particularly b/c it creates a Disaster Recovery > feedback loop > if our directory servers require Puppet to build and Puppet > requires the > directory servers to work.Well, for the record the node classing tool (I really need to come up with a name for it, so I can stop calling it that) will have a (hopefully) simple language; you''ll be able to swap it out with something like ldap or an external script, but the default will be as simple as Puppet is today but have a simple language better suited to node classification than resource specification.>> What else do you want to be organized module-like? > > The comment about not needing the manifest directive made me think > that is > what was happening:>> Actually, with external node configuration and modules you probably >> can do >> away with the "manifest=" parameter too, since all classes are in a >> module on >> the path. > > All of our classes are not in modules and there is no plan to make > that the > case. We have classes the define systems for our clients and > services that > we run. Though perhaps best practice might dictate that we should > organize > those as modules as well. I wouldn''t be against that idea, > particular if I > can point puppet at a directory and tell it any class used will be > in a > module defined in this directory or one of its subdirectories.I can''t see doing away with manifests; at most, I could see making it optional, but even that''s a ways away, I would think. -- A bore is a man who deprives you of solitude without providing you with company. -- Gian Vincenzo Gravina --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 9, 2007, at 5:25 PM, David Schmitt wrote:> > Of course I can''t speak for Luke, but I haven''t seen anything in > the direction > of making external node configuration mandatory. Luke wished to > create a new > syntax for more flexible node configuration, but I think this will > be only > after there is a possibility for ENC.I would be surprised if the existing node stuff lasted much more than a year, but that''s partially because I think people will be *much* happier with the new functionality. As an example, Puppet currently can''t reuse a node''s class membership, because it''s not cached -- you can''t restrict a file to only members of a certain class, because the fileserver has no way to know which classes a node is in. One of the main goals of the node classing system is to support this kind of reuse, both within Puppet and in external tools.> There is not much in puppet (node configuration, ruby stuff (see my > other > mail)) which cannot be put into modules. So there should be nothing > to hinder > you to do so. I think it will be just much more comfortable to put > everything > into modules instead of manipulating big directories of > unrelated .pp files.This I agree with, but I''m hesitant to view everything as solvable with modules. I''m afraid we''ll end up with 10 different directories in them, having just moved all the complexity there instead of actually eliminating it. -- Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come. --Matt Groening --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, Luke Kanies wrote:> Well, for the record the node classing tool (I really need to come up > with a name for it, so I can stop calling it that) will have [...]Nickel: (Node CLassing => NCL => Nickel) - the name doesn''t show up on freshmeat.net Bert: While Bert is technically a Muppet, he had a tendency to collect and organize mundane things. Also, it''s distinctive, short, and doesn''t follow the threadbare X*, gn*, k*, r*, py*, php*, etc. naming schemes. The reference loses something across cultural boundaries though. ''Bert'' doesn''t show up on freshmeat.net either. I help where I can, -- Bob
> # puppetmasterd.conf > [main] > default_env = prod > > [prod] > manifest = /etc/puppet/manifests/prod.pp > modulepath = /usr/share/puppet/modules:/usr/share/puppet/prod/modules > fileserverconfig = /etc/puppet/fileserver_prod.conf > ... > >quite a large part of software use .ini style file. If you include it in your parser it would be a good thing to have a fileini type to manage .ini files added. As the code will be there it should be not too hard and will provide some good toy for files like mysql my.cnf or php.ini etc... so just as a note it could be great to think about it while you code the parsing :) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Regarding: --- I think this would only work with an external node classification tool: # puppetmasterd.conf [main] default_env = prod [prod] manifest = /etc/puppet/manifests/prod.pp modulepath = /usr/share/puppet/modules:/usr/share/puppet/prod/modules fileserverconfig = /etc/puppet/fileserver_prod.conf ... ... Do people think this is a good idea? I personally like it a lot, but I''ve gotten a less-than-enthusiastic reception on it before. --- Actually I like it too. Why? Mainly because it saves the admin and running overhead of multiple puppetmasterds. I think we''ll still need to have multiple similar directory structures to make the ''dev-prod push'' simple enough to be reliable and robust, but that can''t be helped. Given we''re taken to using the Red Hat packages for Puppet, this allows us to use the stock startup scripts, etc. These kind of features are lacking from many packages - maybe it''s just banks who are ultra-conservative about controlling environments and releases? Normally we end up having to engineer something every time. So having this kind of intelligence built-in is a boon. As for requiring the External Node Classification Tool - that sounds like a good place for the classifications (amongst other things). Regards, Derek -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies Sent: 09 May 2007 21:41 To: Puppet User Discussion Subject: Re: [Puppet-users] Puppet Best Practice On May 9, 2007, at 11:29 AM, Digant C Kasundra wrote:> --On May 9, 2007 10:55:49 AM +0100 > Derek.Whayman@barclayscapital.com wrote: >> Also good to see the modularisation of functionality (i.e. >> templates and >> manifests grouped together as per ModuleOrganisation) within the repo>> even if it is installed into disparate directories - even if it makes>> the above a little trickier. > > The trickiest part for me is having to do an import of each individual> module I want to use. But I believe there was some agreement on how > to remedy that which will be in a future release.Indeed; that''s on the docket for elmo.>> Another thing we have to deal with the is the permanent need for >> Hacking/Test/Development/Production configurations. I intend to have>> Hacking & Test running on the same host in the lab, and Development &>> Prod environments "out there". This needs to be fixed into the >> repository somewhere, although I think that''ll be done by having >> different SVN branches - although I need to put in different port >> numbers somewhere. > > Same here. This has been somewhat of a hassle. So far, what I''ve > done is create a dev/test puppetmaster and all I do is add an entry > into / etc/hosts for each dev/test client server to point to the > dev/test master server (I refer to my master as "puppet" and so I just> add an entry for "puppet" with a different ip).We talked about this a while back, multiple times, actually, with the last thread resulting in modules, since that was half of the discussion. The other half, though, was talk of ''releases'' (to use Debian''s terms) or ''environments'' (to use terms from Rails). It seems like a good idea to me, but now that we''ve got modules, it''s less clear how this would work -- previously, I would have just had a checked out manifest set per environment. I suppose with the newly consolidated configuration files, we could have one configuration section per environment, and then make ''environment'' a fundamental trait of nodes, although I think this would only work with an external node classification tool: # puppetmasterd.conf [main] default_env = prod [prod] manifest = /etc/puppet/manifests/prod.pp modulepath = /usr/share/puppet/modules:/usr/share/puppet/prod/modules fileserverconfig = /etc/puppet/fileserver_prod.conf ... As long as the fileserver had access to the node''s environment, you shouldn''t need to specify it during file copies -- i.e., hostA gets its configuration compiled and the file server stores the fact that hostA is in ''prod'' (in a db or whatever); when hostA connects to retrieve a file, the fileserver checks the environment and translates the file appropriately. This seems pretty clear and easy now that I''m thinking about node classification as a separate problem. Do people think this is a good idea? I personally like it a lot, but I''ve gotten a less-than-enthusiastic reception on it before.>> >> Finally, I see a couple of omissions from the tree >> >> * Own & 3rd party Functions >> * Custom Facts >> >> Any thoughts as to where these should go? > > Nope. I was hoping for some kind of "non-standard extras" > directory for > Facter to search in. So far, additional facts have to go into > /usr/lib/ruby/1.8/facter/ IIRC.I can modify Facter to look in ''puppet/plugins'', so custom facts could be thrown in with the rest of the plugins. All custom stuff should go in the plugins dir, once it exists[1]. 1 - https://reductivelabs.com/trac/puppet/ticket/621 -- Barrow''s first law: Any Universe simple enough to be understood is too simple to produce a mind able to understand it. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
On May 9, 2007, at 11:49 PM, Bob Apthorpe wrote:> Hi, > > Luke Kanies wrote: >> Well, for the record the node classing tool (I really need to come up >> with a name for it, so I can stop calling it that) will have [...] > > Nickel: (Node CLassing => NCL => Nickel) - the name doesn''t show up on > freshmeat.netI really like this, although I would probably misspell it so it''s easier to find. I wanted to use nickle, but that''s apparently a prototyping language or something. Nickil? nikel? nikle?> Bert: While Bert is technically a Muppet, he had a tendency to collect > and organize mundane things. Also, it''s distinctive, short, and > doesn''t > follow the threadbare X*, gn*, k*, r*, py*, php*, etc. naming schemes. > The reference loses something across cultural boundaries though. > ''Bert'' > doesn''t show up on freshmeat.net either.I like a non-puppety name better than something puppetty; it should be seen as a separate tool, after all. -- Ah, but I am more perceptive than most of the universe. Especially the parts of the universe that are vacuum. -- James Alan Gardner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, Luke Kanies wrote:> On May 9, 2007, at 11:49 PM, Bob Apthorpe wrote: > >> Hi, >> >> Luke Kanies wrote: >>> Well, for the record the node classing tool (I really need to come up >>> with a name for it, so I can stop calling it that) will have [...] >> Nickel: (Node CLassing => NCL => Nickel) - the name doesn''t show up on >> freshmeat.net > > I really like this, although I would probably misspell it so it''s > easier to find. I wanted to use nickle, but that''s apparently a > prototyping language or something. Nickil? nikel? nikle?Think Web 2.0: nickl You''d have to make it shiny somehow. :) -- Bob
--On May 10, 2007 10:26:34 AM -0500 Luke Kanies <luke@madstop.com> wrote:>> Nickel: (Node CLassing => NCL => Nickel) - the name doesn''t show up on >> freshmeat.net > > I really like this, although I would probably misspell it so it''s > easier to find. I wanted to use nickle, but that''s apparently a > prototyping language or something. Nickil? nikel? nikle?You''d want to keep the C otherwise it doesn''t make sense. What about NOde CLASSing => NO-CLASS -- wait, that''s not good. Space Almonds is an anagram of Node Class Map. If I knew more of what it might do, I could come up with some acronyms to consider.
On Thu, May 10, 2007 at 09:31:12AM -0700, Digant C Kasundra wrote:> Space Almonds is an anagram of Node Class Map.My vote is for this one. After all, who can resist some nice, tasty space almonds? - Matt -- I tend to think of "solution" as just a pretentious term for "thingy". Doing that word substitution in my head makes IT marketing literature somewhat more tolerable. -- lutchann, in http://lwn.net/Articles/124703/
On May 10, 2007, at 1:20 AM, ADNET Ghislain wrote:> quite a large part of software use .ini style file. If you include > it in your parser it would be a good thing to have a fileini type > to manage .ini files added. As the code will be there it should be > not too hard and will provide some good toy for files like mysql > my.cnf or php.ini etc... so just as a note it could be great to > think about it while you code the parsing :)You mean you want Puppet to be able to directly manage INI files? That''s difficult, because most such files have a nearly infinite list of possible parameters, so we''d have to find a way to disable parameter validation, or actually code up all the valid parameters, which, given that you haven''t been interested in touching any Ruby, I expect you don''t want to do for your different INI files. These files are always going to be hard to manage, which is why I''ve taken steps to make it easier to use the same file in multiple places. I''ve spent some time trying to manage these, and, well, it''s not easy. -- Censorship, like charity, should begin at home; but, unlike charity, it should end there. --Clare Booth Luce --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 10, 2007, at 11:31 AM, Digant C Kasundra wrote:> > You''d want to keep the C otherwise it doesn''t make sense. > > What about NOde CLASSing => NO-CLASS -- wait, that''s not good. > > Space Almonds is an anagram of Node Class Map.Nice, but, um... :)> If I knew more of what it might do, I could come up with some > acronyms to > consider.Its job is to determine and maintain a list of classes and attributes for each node you manage. Inputs will be the node name and a list of attributes from the node (normally from Facter). Outputs will be a list of classes (e.g., webserver, solaris, etc.) and attributes (in addition to attributes from Facter). Essentially, this tool would do everything that the ''node'' construct does, but with a focus on that, plus the ability to cache the information and thus return it later (e.g, the fileserver could ask which classes a client is a member of, or which environment it is in) and the ability to acquire attributes along with classes. Eg., if you have per-datacenter IP spaces, you could have a ''dcX'' class that your node is a member of, and then along with that your client would get a router IP, a netmask, and some DNS resolvers. Once this list of classes and attributes is compiled, Puppet''s own compiler will use them. It will assign all of the attributes as variables in the top scope (just like Facts work now, but it adds the per-class attributes too), take the full class list and search its own list of defined classes for any matches, then evaluate any found matching classes (it''s not an error for a node to be in a class that''s not defined in Puppet). Does that make it any clearer? -- If two men agree on everything, you may be sure that one of them is doing the thinking. -- Lyndon B. Johnson --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 10, 2007, at 10:43 AM, Bob Apthorpe wrote:> > Think Web 2.0: > > nickl > > You''d have to make it shiny somehow. :)I don''t think I can go there. :) Maybe we can come up with some good puns on lab stuff. I like the idea of using elements, and nickel''s good, but I''m not too concerned about it being a meaningful acronym or whatever... I''ve also thought about something related to being a jeweller, using the idea that this tool''s job is to define a node''s facets (or classes, or aspects, or categories). Plain ''jeweller'' doesn''t seem like the best option, but just removing letters (''jewler'') seems too much like a racial slur. I also that about ''faceter'', since it''s the same basic idea, but it''s only one letter different from ''facter'', so that makes it a bad idea. -- Love truth, and pardon error. -- Voltaire --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Thinking down the line of jewelry, what about: Blinger Regalia? Since it knows everything about nodes, what about: Gossipre Just random: Betty
Privy -- because it is privy to information about all nodes.
Works in the adjective form. The noun form, however, is less than flattering. :) From http://dict.die.net/privy/ : n 1: a room equipped with toilet facilities [syn: toilet, lavatory, lav, can, john, bathroom] 2: a small outbuilding with a bench having holes through which a user can defecate [syn: outhouse, earth-closet, jakes] -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Digant C Kasundra Sent: Thursday, May 10, 2007 4:32 PM To: Puppet User Discussion Subject: Re: [Puppet-users] Naming the node classing tool Privy -- because it is privy to information about all nodes. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
what about kinship ? Kinship From Wikipedia, the free encyclopedia Jump to: navigation <http://en.wikipedia.org/wiki/Kinship#column-one>, search <http://en.wikipedia.org/wiki/Kinship#searchInput> <http://en.wikipedia.org/wiki/Image:Merge-arrow.gif> It has been suggested that this article or section be merged <http://en.wikipedia.org/wiki/Wikipedia:Merging_and_moving_pages> into /Kinship and descent <http://en.wikipedia.org/wiki/Kinship_and_descent>/. (Discuss <http://en.wikipedia.org/wiki/Talk:Kinship_and_descent>) *Kinship* is the most basic principle of organizing individuals into social groups, roles, and categories. It was originally thought to be determined by biological descent, a view that was challenged by David M. Schneider <http://en.wikipedia.org/wiki/David_M._Schneider> in his work on symbolic kinship (1984, /A Critique of The Study of Kinship/). The crux of his argument was that anthropologists had founded the domain of “kinship” on the notions of human reproduction and the biologically defined relatedness of their own Euro-American culture. Human reproduction and notions of biological relatedness cannot be presumed to structure people’s social relationships in other cultural contexts. -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 10, 2007, at 3:01 AM, <Derek.Whayman@barclayscapital.com> <Derek.Whayman@barclayscapital.com> wrote:> > Actually I like it too. Why? Mainly because it saves the admin and > running overhead of multiple puppetmasterds. I think we''ll still need > to have multiple similar directory structures to make the ''dev-prod > push'' simple enough to be reliable and robust, but that can''t be > helped. > Given we''re taken to using the Red Hat packages for Puppet, this > allows > us to use the stock startup scripts, etc.I expect the prod/dev/whatever to mostly be done with SCM branching, so you''re going to get a lot of similarity in your directory structures, but that''s more by design than anything, I''d think.> These kind of features are lacking from many packages - maybe it''s > just > banks who are ultra-conservative about controlling environments and > releases? Normally we end up having to engineer something every time. > So having this kind of intelligence built-in is a boon.Rails has it built in and everyone seems to use it. I think it''s more just that people depend on their own skill to do it, rather than relying on tools.> As for requiring the External Node Classification Tool - that sounds > like a good place for the classifications (amongst other things).The ENCT (enock? nock? I kind of like that) will definitely be responsible for setting the environment. I think it will need to have a general facility for defining enumerations of classes -- e.g., a list of data centers, operating systems, or IP spaces -- and you could make it a compile error if a given node did not define a class in that enumeration. -- Nothing is impossible for the man who doesn''t have to do it himself. -- A. H. Weiler --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 10, 2007, at 3:12 PM, Matthew Palmer wrote:> On Thu, May 10, 2007 at 09:31:12AM -0700, Digant C Kasundra wrote: >> Space Almonds is an anagram of Node Class Map. > > My vote is for this one. After all, who can resist some nice, > tasty space > almonds?I think it''s entirely hilarious, but I''m not sure it''s a very practical name... -- You''ve achieved success in your field when you don''t know whether what you''re doing is work or play. -- Warren Beatty --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 11, 2007, at 1:24 AM, ADNET Ghislain wrote:> what about kinship ?I like the basic idea, but maybe something like ''kinner'' or ''kinning''? I''m still hoping for a less common or even made-up word. -- Getting caught is the mother of invention. --Robert Byrne --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
''classer'' is freshmeat free and produces nothing significant in google... apologies if it''s already been suggested - i just realised i''d purged a chunk of this thread.> I like the basic idea, but maybe something like ''kinner'' or > ''kinning''? I''m still hoping for a less common or even made-up word. > > -
Luke Kanies a écrit :> On May 11, 2007, at 1:24 AM, ADNET Ghislain wrote: > > >> what about kinship ? >> > > I like the basic idea, but maybe something like ''kinner'' or > ''kinning''? I''m still hoping for a less common or even made-up word. > >keenship kinsheap kincheap kinchips nodebucket mightyoverzealousnodeclasifier why not theater , this is where you find the puppet (node) to be used by the puppetmaster ? => thyter or any way to spell it like we talk sorry i am not english so i have some issue doing variation on the phonetic part :) -- Cordialement, Ghislain _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
--On May 11, 2007 11:35:53 AM -0500 Luke Kanies <luke@madstop.com> wrote:> On May 11, 2007, at 1:24 AM, ADNET Ghislain wrote: > >> what about kinship ? > > I like the basic idea, but maybe something like ''kinner'' or > ''kinning''? I''m still hoping for a less common or even made-up word.Zebi Rizoque Space Almonds
--On May 11, 2007 7:10:37 PM +0200 ADNET Ghislain <gadnet@aqueos.com> wrote:> Luke Kanies a écrit : >> On May 11, 2007, at 1:24 AM, ADNET Ghislain wrote: >> >> >>> what about kinship ? >>> >> >> I like the basic idea, but maybe something like 'kinner' or >> 'kinning'? I'm still hoping for a less common or even made-up word. >> >> > keenship > kinsheap > kincheap > kinchipskinial kinses kinfervo kinna> > nodebucketNode Machine> > mightyoverzealousnodeclasifier > > why not > > theater , this is where you find the puppet (node) to be used by the > puppetmaster ? > => thyter or any way to spell it like we talkHollyNode Nodelin Hobling _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
--On May 11, 2007 7:10:37 PM +0200 ADNET Ghislain <gadnet@aqueos.com> wrote:> Luke Kanies a écrit : >> On May 11, 2007, at 1:24 AM, ADNET Ghislain wrote: >> >> >>> what about kinship ? >>> >> >> I like the basic idea, but maybe something like 'kinner' or >> 'kinning'? I'm still hoping for a less common or even made-up word. >> >> > keenship > kinsheap > kincheap > kinchipskinial kinses kinfervo kinna> > nodebucketNode Machine> > mightyoverzealousnodeclasifier > > why not > > theater , this is where you find the puppet (node) to be used by the > puppetmaster ? > => thyter or any way to spell it like we talkHollyNode Nodelin Hobling _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 11, 2007, at 1:28 PM, Digant C Kasundra wrote:>>> >>> >> keenship >> kinsheap >> kincheap >> kinchips > > kinial > kinses > kinfervo > kinnaI like kinial, but I''m leaning toward ''facetre'' -- one who facets, but misspelled. -- Honest criticism is hard to take, particularly from a relative, a friend, an acquaintance, or a stranger. -- Franklin P. Jones --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On May 11, 2007, at 4:33 PM, Luke Kanies wrote:> On May 11, 2007, at 1:28 PM, Digant C Kasundra wrote: >>>> >>>> >>> keenship >>> kinsheap >>> kincheap >>> kinchips >> >> kinial >> kinses >> kinfervo >> kinna > > I like kinial, but I''m leaning toward ''facetre'' -- one who facets, > but misspelled.Hmm. Or ''kinian''. Unless someone has some strenuous objections, I''ll use that as the project code-name, and if we can come up with something better, great. -- A conservative is a man who believes that nothing should be done for the first time. --Alfred E. Wiggam --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Friday, May 11, 2007 16:33:18 -0500 Luke Kanies <luke@madstop.com> wrote:> I like kinial, but I''m leaning toward ''facetre'' -- one who facets, > but misspelled.Facetre does seem a bit too similar to Facter. As i work with several coworkers for whom English is not their primary language, I suspect this will lead to much confusion.
On May 11, 2007, at 4:51 PM, Digant C Kasundra wrote:> > Facetre does seem a bit too similar to Facter. As i work with several > coworkers for whom English is not their primary language, I suspect > this > will lead to much confusion.Yeah, the more I looked at the word the uglier it became. Kinial, or kinian, at least as code names for now? It doesn''t make sense to commit to anything until we''ve gotten somewhere with it, but I''d like to just pick something and move on. I like the roll of kinian, but kinial has an otré feel that I also like. -- If all the world''s a stage, I want to operate the trap door. -- Paul Beatty --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Friday, May 11, 2007 16:54:32 -0500 Luke Kanies <luke@madstop.com> wrote:> Kinial, or kinian, at least as code names for now? It doesn't make > sense to commit to anything until we've gotten somewhere with it, but > I'd like to just pick something and move on. I like the roll of > kinian, but kinial has an otré feel that I also like.They both sound good. I'm just going to call it Space Almonds anyway (j/k). ;-) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Kinses, me likesesss Sorry, had me flash to gollum there for a moment. (And no, don''t think it''s a good fit, really). kinial is as good as anything. Especially as it seems there isn''t a name that everyone directly recognizes as being ''right'' for the tool. Mostly then there isn''t one, until you decide to name it something and go with it. It''ll probably grow on you. And if not, there''ll be a replacement (as everyone apparently is calling it something other than the ill-fitting name you tried to give it.. ;) gr, Thijs On 12/05/07, Digant C Kasundra <digant@stanford.edu> wrote:> > --On Friday, May 11, 2007 16:54:32 -0500 Luke Kanies <luke@madstop.com> > wrote: > > > Kinial, or kinian, at least as code names for now? It doesn''t make > > sense to commit to anything until we''ve gotten somewhere with it, but > > I''d like to just pick something and move on. I like the roll of > > kinian, but kinial has an otré feel that I also like. > > They both sound good. I''m just going to call it Space Almonds anyway > (j/k). ;-) > _______________________________________________ > 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
how about spectiv ? dave
On 5/11/07, Luke Kanies <luke@madstop.com> wrote:> > On May 10, 2007, at 3:12 PM, Matthew Palmer wrote: > > > On Thu, May 10, 2007 at 09:31:12AM -0700, Digant C Kasundra wrote: > >> Space Almonds is an anagram of Node Class Map. > > > > My vote is for this one. After all, who can resist some nice, > > tasty space > > almonds? > > I think it''s entirely hilarious, but I''m not sure it''s a very > practical name...Node Classer .... Nasser? Node Mapper ... Napper? Node Attribute and Class Hierarchy Objectifier ... Nacho? :) -Blake _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On May 11, 2007, at 7:53 PM, Thijs Oppermann wrote:> Kinses, me likesesss > > Sorry, had me flash to gollum there for a moment. (And no, don''t > think it''s a good fit, really). > > kinial is as good as anything. Especially as it seems there isn''t a > name that everyone directly recognizes as being ''right'' for the > tool. Mostly then there isn''t one, until you decide to name it > something and go with it. It''ll probably grow on you. And if not, > there''ll be a replacement (as everyone apparently is calling it > something other than the ill-fitting name you tried to give it.. ;)Yeah, I''ll consider kinial a code name until it''s time to release or we come up with a better name. -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly goes wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams, Mostly Harmless --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 5/8/07, Digant C Kasundra <digant@stanford.edu> wrote:> Nice script. I''ve updated the page to remove our Stanford specific stuff: > > <http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice> >Good document, but I wish there was something about when to use Definitions or Classes etc. For instance, when and why would somebody want to use: -- file { frienldy-name: path => "..." content => ... } -- VS -- file { "file-path": content => ... } -- That is, what level of abstraction is "best practice" for manifests. -- Perfection is just a word I use occasionally with mustard. --Atom Powers--
On Jun 22, 2007, at 4:02 PM, Atom Powers wrote:> Good document, but I wish there was something about when to use > Definitions or Classes etc. For instance, when and why would somebody > want to use: > -- > file { frienldy-name: > path => "..." > content => ... > } > -- > VS > -- > file { "file-path": > content => ... > } > -- > > That is, what level of abstraction is "best practice" for manifests.Well, in the above case, you might want to do that in order to have the same file be managed by more than one class. (Since it''s the "foo": part that puppet cares about). Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com
On Jun 22, 2007, at 6:02 PM, Atom Powers wrote:> Good document, but I wish there was something about when to use > Definitions or Classes etc. For instance, when and why would somebody > want to use: > -- > file { frienldy-name: > path => "..." > content => ... > } > -- > VS > -- > file { "file-path": > content => ... > } > -- > > That is, what level of abstraction is "best practice" for manifests.For resource titles, best practice is that if someone''s going to specify a relationship to the resource, it should be done in a cross- platform way. So, if you''re going to subscribe to that file, then use "friendlyname", otherwise it doesn''t matter. As to classes vs. definitions, classes are singletons, while definitions can be instantiated multiple times but there can be no cross-over in the instances. If someone could add that (with more detail, I expect) to the best practices doc, that''d be great. :) -- My favorite was a professor at a University I Used To Be Associated With who claimed that our requirement of a non-alphabetic character in our passwords was an abridgement of his freedom of speech. -- Jacob Haller --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jun 22, 2007, at 6:47 PM, Adam Jacob wrote:> Well, in the above case, you might want to do that in order to have > the same file be managed by more than one class. (Since it''s the > "foo": part that puppet cares about).This isn''t actually true -- Puppet will throw an error in the parser if the type/title tuple conflict, but it will still throw an error on the client if the type/name tuple conflict. -- Progress isn''t made by early risers. It''s made by lazy men trying to find easier ways to do something. --Robert Heinlein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
--On Monday, June 25, 2007 10:39 AM -0500 Luke Kanies <luke@madstop.com> wrote:> For resource titles, best practice is that if someone''s going to > specify a relationship to the resource, it should be done in a cross- > platform way. So, if you''re going to subscribe to that file, then > use "friendlyname", otherwise it doesn''t matter.Hmm. At my organization, I think people wouldn''t be happy with the inconsistency there. For instance, File is the best example. We''d probably want to always use the full path as the name, or always use a friendly name with the path attribute. But doing one sometimes and another other times would be confusing.> > As to classes vs. definitions, classes are singletons, while > definitions can be instantiated multiple times but there can be no > cross-over in the instances. > > If someone could add that (with more detail, I expect) to the best > practices doc, that''d be great. :)I should think about how best to write that up.
On Jun 27, 2007, at 1:52 AM, Digant C Kasundra wrote:> > Hmm. At my organization, I think people wouldn''t be happy with the > inconsistency there. For instance, File is the best example. We''d > probably want to always use the full path as the name, or always use a > friendly name with the path attribute. But doing one sometimes and > another > other times would be confusing.It''s not reasonable to always use the full path as the title, for portability reasons, which means you''re stuck always using a symbolic title, which I expect would get pretty old if you had to do it for every file. I''ll certainly bow to the community, though; you''re the ones using the product every day.>> As to classes vs. definitions, classes are singletons, while >> definitions can be instantiated multiple times but there can be no >> cross-over in the instances. >> >> If someone could add that (with more detail, I expect) to the best >> practices doc, that''d be great. :) > > I should think about how best to write that up.That''d be great. I''ve well-established that my way of thinking about it sounds like gibberish to everyone else. -- Yesterday upon the stair I met a man who wasn''t there. He wasn''t there again today -- I think he''s from the CIA. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
"DCK" == Digant C Kasundra <digant@stanford.edu> >> I like kinial, but I''m leaning toward ''facetre'' -- one who >> facets, but misspelled. DCK> Facetre does seem a bit too similar to Facter. As i work DCK> with several coworkers for whom English is not their DCK> primary language, I suspect this will lead to much DCK> confusion. As someone for whom English is my primary language, the slightly off spellings will almost certainly cause me some issues. (It''s hard enough keeping track of your own misspellings without having to get your head around slightly weird deliberate alternate spellings. Hooray for shell completion!) Also -- when you were trying variants on jeweler, I immediately thought of Diderot''s Encyclopedie, which has plates showing various industrial processes and details all the tools, parts, processes, and so on. Diderot might be a good source for names. (It looks like Dover has a two-volume set called _Diderot Pictorial Encyclopedia of Trades and Industry_. Hmm, I think *I* should have a copy of these....) Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc@math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jul 10, 2007, at 2:04 PM, C.M. Connelly wrote:> > As someone for whom English is my primary language, the slightly > off spellings will almost certainly cause me some issues. (It''s > hard enough keeping track of your own misspellings without having > to get your head around slightly weird deliberate alternate > spellings. Hooray for shell completion!)I agree on misspellings being non-ideal, but correct spellings of regular words are like another drop in the ocean of google. They also make it significantly less likely that we''ll have naming conflicts with an existing project.> Also -- when you were trying variants on jeweler, I immediately > thought of Diderot''s Encyclopedie, which has plates showing > various industrial processes and details all the tools, parts, > processes, and so on. Diderot might be a good source for names. > > (It looks like Dover has a two-volume set called _Diderot > Pictorial Encyclopedia of Trades and Industry_. Hmm, I think *I* > should have a copy of these....)I still like this basic direction, so if you''ve got some good ideas... -- I believe that if it were left to artists to choose their own labels, most would choose none. -- Ben Shahn --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com