> > > > 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' ? :) > > Like I mentioned above, "apply" is generally going to be optional, since if you supply a filename instead of a command, "apply" will be assumed. Is that a sufficient workaround?
> > > > 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]<puppet-dev%[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]<puppet-dev%[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]<puppet-dev%[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]<puppet-dev%[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.
