On Fri, Apr 16, 2010 at 11:50 AM, Jesse Wolfe <[email protected]> wrote: > Okay, here's my synthesis of what seems to be a reasonable approximation of > consensus. We can add aliases later if we need to, and we'll still include > the old executables for now. > bin/puppet => puppet apply > sbin/puppetmasterd => puppet master > sbin/puppetd => puppet agent
(minor nit-pick) I feel like the two most common commands I'm going to type interactively are puppet apply puppet agent Is there any way we can pick names that don't both start with 'a' ? :) > bin/puppetdoc => puppet doc > sbin/puppetca => puppet cert > sbin/puppetrun => puppet kick > bin/ralsh => puppet resource > sbin/puppetqd => puppet queue > bin/filebucket => puppet filebucket > bin/pi => puppet describe > notes: > * I don't think we're ready to change "filebucket"'s name - it's a silly > name but the feature needs to have a name that disambiguates it from other > puppet file/content/checksum subsystems. > * "describe"'s functionality might later be merged into "doc". > ~Jesse > 2010/4/15 Aurélien Degrémont <[email protected]> >> >> Le 14/04/2010 22:06, Luke Kanies a écrit : >> >> On Apr 14, 2010, at 12:16 PM, Stéphan Gorget wrote: >> >> On Wed, Apr 14, 2010 at 9:07 PM, Jesse Wolfe <[email protected]> wrote: >>> >>> the new puppet single-executable is in master, but I think the names of >>> the commands should be up for discussion. These are something that we may >>> have to live with for a long time. >>> >>> Here's what's currently in master: >>> bin/filebucket => puppet filebucket >>> bin/pi => puppet pi >>> bin/puppetdoc => puppet doc >>> sbin/puppetca => puppet ca >>> sbin/puppetmasterd => puppet server >>> sbin/puppetrun => puppet run >>> bin/puppet => puppet main >>> bin/ralsh => puppet resource >>> sbin/puppetd => puppet agent >>> sbin/puppetqd => puppet queue >>> >>> Here's my commentary: >>> bin/pi => puppet pi (what does "i" stand for, anyway?) >>> sbin/puppetmasterd => puppet server (I'd rather keep the "master" >>> jargon) >>> bin/puppet => puppet main (doesn't seem very main to me. "exec"? >>> "do"?) >>> sbin/puppetd => puppet agent (is "agent" the jargon we use in >>> training? I can't remember) >> >> Why don't we merge puppet and puppetd and use sthg like --local instead ? >> >> In general you need to provide some code for puppet to apply, which isn't >> the case with puppetd. Also, there'll basically be an assumption about >> both: puppetd will need to run as root, it'll maintain a catalog, it needs >> auth credentials, and plenty more. In contrast, puppet should always be >> able to run as a normal user, should have little if any state, and probably >> doesn't need certificates or any sense of membership to a network. >> >> Here my uses cases where I think it is not so a difference between the two >> command (puppetd and puppet) >> In our environment, we never used puppetd as a daemon, we always run it >> explictly using puppetd -t. >> For us, admin are always doing two actions: >> >> Check my machine/my manifest i just wrote: >> >> puppetd -t --noop >> >> Fix the machine configuration, i've just checked >> >> puppetd -t >> >> After that, i've got two ways to get my catalog, depending on the access I >> have to my manifests, through network and puppetmaster or direct file >> access, but the action I do is the same: i just want to check/apply my >> puppet conf, I wonder why if the source changes, the syntax changes so much: >> >> puppet /etc/puppet/production/manifests/site.pp --manifestdir >> /my/very/long/path --modulepath ... >> >> puppetd -t >> >> I would be very nice if this could be taken in account into the "single >> executable" changes. >> >> >> Aurélien >> >> >> -- >> Discovery consists of seeing what everybody has seen and thinking what >> nobody has thought. -- Albert Szent-Gyorgyi >> --------------------------------------------------------------------- >> Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/puppet-dev?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/puppet-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
