Do we need a new name for "--test"?

[Nigel Kersten]

https://projects.puppetlabs.com/issues/2476

This does seem to confuse a fair few new users.

What would be a better name for "--test"?

[Adam Nielsen]

> https://projects.puppetlabs.com/issues/2476
>
> This does seem to confuse a fair few new users.
>
> What would be a better name for "--test"?

Using Gentoo's emerge as an example, how about --oneshot?

Cheers,
Adam.

[Nigel Kersten]

It's more than that though.

--onetime
--no-daemonize
--ignorecache
--verbose
--no-usecacheonfailure

and I think I'm missing some newer additions too.

[Denmat]

I was thinking '--update' as that is what it does but then that doesn't describe the '--one-time' nature of it explicitly.

I always felt funny updating hosts with 'test' though :)

Hard one.

Den

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[Patrick]

To me, this sounds too similar to --onetime but I don't have a good suggestion.

[Daniel Pittman]

My inclination is to say that "ontime" or "verbose" have stolen the name for another concept; perhaps "interactive" covers the standard use-case well enough?

Daniel

[Dan Bode]

On Sun, Jan 23, 2011 at 3:35 PM, Daniel Pittman <dan...@puppetlabs.com> wrote:

My inclination is to say that "ontime" or "verbose" have stolen the name for another concept; perhaps "interactive" covers the standard use-case well enough?

Daniel

On Jan 23, 2011 2:45 PM, "Patrick" <kc7...@gmail.com> wrote:
>
> On Jan 23, 2011, at 1:50 PM, Adam Nielsen wrote:
>
>>> https://projects.puppetlabs.com/issues/2476
>>>
>>> This does seem to confuse a fair few new users.
>>>
>>> What would be a better name for "--test"?

maybe we could keep --test and add --noop to the list of options in sets.

 

[Nigel Kersten]

On Sun, Jan 23, 2011 at 3:38 PM, Dan Bode <d...@puppetlabs.com> wrote:
> On Sun, Jan 23, 2011 at 3:35 PM, Daniel Pittman <dan...@puppetlabs.com>
> wrote:
>>
>> My inclination is to say that "ontime" or "verbose" have stolen the name
>> for another concept; perhaps "interactive" covers the standard use-case well
>> enough?
>>
>> Daniel
>>
>> On Jan 23, 2011 2:45 PM, "Patrick" <kc7...@gmail.com> wrote:
>> >
>> > On Jan 23, 2011, at 1:50 PM, Adam Nielsen wrote:
>> >
>> >>> https://projects.puppetlabs.com/issues/2476
>> >>>
>> >>> This does seem to confuse a fair few new users.
>> >>>
>> >>> What would be a better name for "--test"?
>
> maybe we could keep --test and add --noop to the list of options in sets.

That would take away the current functionality, which is immensely useful.

You'd be required to spell out all the --onetime --no-daemonize stuff by hand.

Maybe we should just make up a word. :)

I know some people expect --noop to be implied by --test, and I have
some sympathy for that position, but before we can get there, we need
to have a name for the existing functionality that I don't want to do
away with.

[James Louis]

and what is the current functionality for the --test option?

“Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.”

– Mark Twain

[Patrick]

On Jan 23, 2011, at 4:02 PM, James Louis wrote:

> and what is the current functionality for the --test option?

To quote Nigel:

[James Louis]

that tells what options are applied when --test is used but doesn't explain the functionality of --test (i.e. --test is an option to enable the puppet agent to test it's connection to the puppet master by turning on the following options... blah blah blah)

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Stefan Schulte]

On Sun, Jan 23, 2011 at 03:48:16PM -0800, Nigel Kersten wrote:
> On Sun, Jan 23, 2011 at 3:38 PM, Dan Bode <d...@puppetlabs.com> wrote:
> > On Sun, Jan 23, 2011 at 3:35 PM, Daniel Pittman <dan...@puppetlabs.com>
> > wrote:
> >>
> >> My inclination is to say that "ontime" or "verbose" have stolen the name
> >> for another concept; perhaps "interactive" covers the standard use-case well
> >> enough?
> >>
> >> Daniel
> >>
> >> On Jan 23, 2011 2:45 PM, "Patrick" <kc7...@gmail.com> wrote:
> >> >
> >> > On Jan 23, 2011, at 1:50 PM, Adam Nielsen wrote:
> >> >
> >> >>> https://projects.puppetlabs.com/issues/2476
> >> >>>
> >> >>> This does seem to confuse a fair few new users.
> >> >>>
> >> >>> What would be a better name for "--test"?
> >
> > maybe we could keep --test and add --noop to the list of options in sets.
>
> That would take away the current functionality, which is immensely useful.
>
> You'd be required to spell out all the --onetime --no-daemonize stuff by hand.
>
> Maybe we should just make up a word. :)
>
> I know some people expect --noop to be implied by --test, and I have
> some sympathy for that position, but before we can get there, we need
> to have a name for the existing functionality that I don't want to do
> away with.
>

Maybe --test should only set options if we havent specified otherwise
(maybe it does so already). We could then say --test --no-noop to match
current behaviour.

-Stefan

[Patrick]

On Jan 23, 2011, at 4:47 PM, James Louis wrote:

> that tells what options are applied when --test is used but doesn't explain the functionality of --test (i.e. --test is an option to enable the puppet agent to test it's connection to the puppet master by turning on the following options... blah blah blah)

Ah. Basically, test doesn't do anything except turn on all those options.

[James Louis]

exactly. to what purpose?

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Nigel Kersten]

On Sun, Jan 23, 2011 at 4:53 PM, James Louis <jglo...@gmail.com> wrote:
> exactly. to what purpose?

To trigger an immediate run on a client with the common options used
when testing a real run, not a noop run.

If there was a clear word that described this functionality, we
probably wouldn't be having this discussion.

[James Louis]

so the actual changes take place, if any, during a test vs a noop which does not let the actual changes take place. So this would be used primarily for configuration testing? Or perhaps for troubleshooting? Or both?

[Nigel Kersten]

On Sun, Jan 23, 2011 at 5:34 PM, James Louis <jglo...@gmail.com> wrote:
> so the actual changes take place, if any, during a test vs a noop which does
> not let the actual changes take place. So this would be used primarily for
> configuration testing? Or perhaps for troubleshooting? Or both?

Yes, both.

Due to it being quick to type, it's become the defacto method for
interactively triggering puppet agent runs.

puppet agent -t

Maybe the right answer is to identify the chunks of functionality
people use it for, and add those as new options, deprecating --test
itself.

[eshamow]

I can tell you that for me, and for my group, it's a halfway step
between reloading Puppet and watching the logs, and a full --debug --
no-daemonize run.

So for instance, when they're troubleshooting a bug in a newly-written
or modified class, I suggest a puppetd -tv run to just output the
errors and successes...and if you see an error, you could then follow
up with the more verbose --debug to get at what Puppet was trying to
do that generated it, provided that you didn't get enough from the
former.

It might be wise to consider combining a bunch of similar options
(verbose, test, debug, etc) into a "verbose" with levels of output --
either v1, v2, v3 or vv, vvv, vvvv, etc.

-Eric


On Jan 23, 8:51 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:

> On Sun, Jan 23, 2011 at 5:34 PM, James Louis <jgloui...@gmail.com> wrote:
> > so the actual changes take place, if any, during a test vs a noop which does
> > not let the actual changes take place. So this would be used primarily for
> > configuration testing? Or perhaps for troubleshooting? Or both?
>
> Yes, both.
>
> Due to it being quick to type, it's become the defacto method for
> interactively triggering puppet agent runs.
>
> puppet agent -t
>
> Maybe the right answer is to identify the chunks of functionality
> people use it for, and add those as new options, deprecating --test
> itself.
>
>
>
>
>
>
>
>
>
> > On Sun, Jan 23, 2011 at 7:22 PM, Nigel Kersten <ni...@puppetlabs.com> wrote:
>

[James Louis]

so the purpose of having a noop is to run the same test but to not actually make any changes. do we get the same debug messages, etc?

[Patrick]

No, because sometimes making the changes causes the error.

For instance, if you are using a File resource to create a file in a read-only file-system (which isn't possible) the resource will tell you it plans to make a file when run in noop, and give you no errors.  When not run in noop it will actually try to make the change and give an error because making the change didn't work.

Note: This is an untested example.  I haven't actually tried it, but the general point works.

[Patrick]

On Jan 23, 2011, at 4:53 PM, James Louis wrote:

exactly. to what purpose?

On Sun, Jan 23, 2011 at 6:50 PM, Patrick <kc7...@gmail.com> wrote:

On Jan 23, 2011, at 4:47 PM, James Louis wrote:

> that tells what options are applied when --test is used but doesn't explain the functionality of --test (i.e. --test is an option to enable the puppet agent to test it's connection to the puppet master by turning on the following options... blah blah blah)

Ah.  Basically, test doesn't do anything except turn on all those options.

--

I personally use it a lot to try out a new manifest on a computer.

I know some people use it whenever they want "--verbose --no-daemonize --onetime".

[Patrick]

On Jan 23, 2011, at 5:58 PM, eshamow wrote:

> I can tell you that for me, and for my group, it's a halfway step
> between reloading Puppet and watching the logs, and a full --debug --
> no-daemonize run.
>
> So for instance, when they're troubleshooting a bug in a newly-written
> or modified class, I suggest a puppetd -tv run to just output the
> errors and successes...and if you see an error, you could then follow
> up with the more verbose --debug to get at what Puppet was trying to
> do that generated it, provided that you didn't get enough from the
> former.
>
> It might be wise to consider combining a bunch of similar options
> (verbose, test, debug, etc) into a "verbose" with levels of output --
> either v1, v2, v3 or vv, vvv, vvvv, etc.

Just for clarification, "--test" isn't a level of messages. It just causes "--verbose" to be added.

[Patrick]

I think this is a really bad idea because I really think Puppet has broken a lot of things recently and people use --test in automatic scripts.

This is really almost always an abuse and "--no-daemonize --onetime --verbose" would probably work better, but I really don't think breaking even more things is the right choice right now.

[Nigel Kersten]

Changing behavior like this would be done only in a major version
release, and we'd provide deprecation warnings for a whole major
version before actually changing it.

This has been standard practice in the project so far.

[Jesse Reynolds]

  --manual

?

[Stig Sandbeck Mathisen]

Patrick <kc7...@gmail.com> writes:

> I know some people use it whenever they want "--verbose --no-daemonize
> --onetime".

This is common use of the puppet agent at my site.

--
Stig Sandbeck Mathisen
Oooo, shiny!

[Stig Sandbeck Mathisen]

Jesse Reynolds <jessedr...@gmail.com> writes:

> --manual

Looks better than --interactive, since I don't assume it will start
asking me questions. :)

[Daniel Pittman]

On Sun, Jan 23, 2011 at 23:36, Stig Sandbeck Mathisen <s...@fnord.no> wrote:
> Jesse Reynolds <jessedr...@gmail.com> writes:
>
>>   --manual
>
> Looks better than --interactive, since I don't assume it will start
> asking me questions. :)

I like it too.
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <dan...@puppetlabs.com>
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons

[DEGREMONT Aurelien]

Nigel Kersten a �crit :

> On Sun, Jan 23, 2011 at 4:53 PM, James Louis <jglo...@gmail.com> wrote:
>
>> exactly. to what purpose?
>>
>
> To trigger an immediate run on a client with the common options used
> when testing a real run, not a noop run.
>
> If there was a clear word that described this functionality, we
> probably wouldn't be having this discussion.
>

Please take care that, for my site, and I think other ones,

puppetd -t

is *the* way to run puppet.
We never use puppetd in daemonized mode, and manual runs puppet when
needed with -t option.
Unfortunately, puppet guys do not really consider this aspect, that
Puppet could be (and it is) used in a CLI mode, and this is really
useful (even mandatory)

(by the way, --nodaemonize does not mean 'no daemonize', but 'no detach')

Aru�lien

[Carles Amigó]

+1

El 24/01/2011 9:13, Daniel Pittman escribió:
> On Sun, Jan 23, 2011 at 23:36, Stig Sandbeck Mathisen<s...@fnord.no> wrote:
>> Jesse Reynolds<jessedr...@gmail.com> writes:
>>
>>> --manual
>>
>> Looks better than --interactive, since I don't assume it will start
>> asking me questions. :)
>
> I like it too.
> Daniel

--
Carles Amigó
Linux System Administrator
carles...@softonic.com

http://www.softonic.com
Edificio Meridian C/ Rosselló i Porcel, 21, planta 12 - 08016 Barcelona
(SPAIN)
Tel+34 936 012 700 Fax+34 933 969 292
Award winning company Great Place to Work 2010

This e-mail (and any attached files) may contain confidential and/or
privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.

[Adam Nielsen]

>>> What would be a better name for "--test"?
>>

>> Using Gentoo's emerge as an example, how about --oneshot?
>

> It's more than that though.

>
> --onetime
> --no-daemonize
> --ignorecache
> --verbose
> --no-usecacheonfailure
>
> and I think I'm missing some newer additions too.

Hmm that's true, and it is similar to --onetime. How about --explain? The
end result is that you get a detailed explanation of what is happening.

--test could be deprecated and --dry-run (like the 'make' parameter) added to
do the same with no-op as well.

Cheers,
Adam.

[Jonathan Gazeley]

How about simply --once ? Nice and quick to type.

Jonathan

--
----------------------------
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
----------------------------

[Adam Nielsen]

>>> It's more than that though.
>>>
>>> --onetime
>>> --no-daemonize
>>> --ignorecache
>>> --verbose
>>> --no-usecacheonfailure
>>>
>>> and I think I'm missing some newer additions too.
>>
>> Hmm that's true, and it is similar to --onetime. How about --explain?
>> The end result is that you get a detailed explanation of what is happening.
>>
>

> How about simply --once ? Nice and quick to type.

I think the issue there is that it doesn't convey all the other options that
get enabled, like --ignorecache. After all, you're not just running it once,
you're running it once with a bunch of debug options active as well.

Come to that, if people are using --test in production environments, maybe
options like --ignorecache *shouldn't* be included in --test or its replacement?

Cheers,
Adam.

[Thorsten Biel]

+1

Letting --test run out slowly (over maybe 2 releases) would be a good compromise
between change and consistency, and --dry-run would more clearly convey the meaning
of what is being done.

Cheers,
Thorsten

[Felix Frank]

On 01/24/2011 11:38 AM, Carles Amigó wrote:
> +1
>
> El 24/01/2011 9:13, Daniel Pittman escribió:
>> On Sun, Jan 23, 2011 at 23:36, Stig Sandbeck Mathisen<s...@fnord.no>
>> wrote:
>>> Jesse Reynolds<jessedr...@gmail.com> writes:
>>>
>>>> --manual

Seconded (or, fourthed?)

Also, I'll outright *refuse* to install a software that contains a
"--no-noop" switch (just abominable, Stefan ;-)

Cheers,
Felix

[chris.d...@googlemail.com]

How about --apply

On Jan 23, 9:33 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:
> https://projects.puppetlabs.com/issues/2476
>
> This does seem to confuse a fair few new users.
>

[Felix Frank]

On 01/24/2011 11:48 AM, chris.d...@googlemail.com wrote:
> How about --apply

Please don't. That's begging for confusion of "puppet apply" vs. "puppet
agent --apply".

[Nigel Kersten]

On Mon, Jan 24, 2011 at 12:27 AM, DEGREMONT Aurelien
<aurelien....@cea.fr> wrote:

> Please take care that, for my site, and I think other ones,
>
> puppetd -t
>
> is *the* way to run puppet.
> We never use puppetd in daemonized mode, and manual runs puppet when needed
> with -t option.

You shouldn't be doing this. If you're running puppet agent out of
cron, you should do something like:

puppetd --onetime --no-daemonize

and not bring in all the ignoring of cache settings that --test does.

> Unfortunately, puppet guys do not really consider this aspect, that Puppet
> could be (and it is) used in a CLI mode, and this is really useful (even
> mandatory)

I don't understand what you mean. How is it that we don't consider
this aspect? Many of our deployments run in this manner, primarily due
to limitations of the underlying Ruby stack.

[Stefan Schulte]

Just for the record:
--no-noop is a valid switch. I have noop=true in my puppet.conf
(together with onetime=true and daemonize=false) and my normal puppet
invocation is »puppet agent -v«. If I want puppet to change stuff I run
with »puppet agent -v --no-noop«. Yes it looks ugly but it works fine
;-)

-Stefan

[Ashley Penney]

If we don't want --manual you could go with --watch as that's really what I'm doing - watching puppet run. :)

[R.I.Pienaar]

----- Original Message -----
> If we don't want --manual you could go with --watch as that's really
> what I'm doing - watching puppet run. :)

I like --watch too

[Patrick]

On Jan 24, 2011, at 2:38 AM, Carles Amigó wrote:

> +1
>
> El 24/01/2011 9:13, Daniel Pittman escribió:
>> On Sun, Jan 23, 2011 at 23:36, Stig Sandbeck Mathisen<s...@fnord.no> wrote:
>>> Jesse Reynolds<jessedr...@gmail.com> writes:
>>>
>>>> --manual
>>>
>>> Looks better than --interactive, since I don't assume it will start
>>> asking me questions. :)
>>
>> I like it too.
>> Daniel

I personally don't think renaming is needed, but if you are going to, I think --manual" sounds good to me.

[Patrick]

On Jan 24, 2011, at 3:00 AM, Adam Nielsen wrote:

>>>> What would be a better name for "--test"?
>>>
>>> Using Gentoo's emerge as an example, how about --oneshot?
>>
>> It's more than that though.
>>
>> --onetime
>> --no-daemonize
>> --ignorecache
>> --verbose
>> --no-usecacheonfailure
>>
>> and I think I'm missing some newer additions too.
>
> Hmm that's true, and it is similar to --onetime. How about --explain? The end result is that you get a detailed explanation of what is happening.

So me, explain is synonymous with --verbose and doesn't explain all the caching options it includes.

[Patrick]

I guess I'm good with this as long as the meaning never changes and the option just stops working.

[Patrick]

On Jan 24, 2011, at 3:01 AM, Jonathan Gazeley wrote:

> On 24/01/11 11:00, Adam Nielsen wrote:
>>>>> What would be a better name for "--test"?
>>>>
>>>> Using Gentoo's emerge as an example, how about --oneshot?
>>>
>>> It's more than that though.
>>>
>>> --onetime
>>> --no-daemonize
>>> --ignorecache
>>> --verbose
>>> --no-usecacheonfailure
>>>
>>> and I think I'm missing some newer additions too.
>>
>> Hmm that's true, and it is similar to --onetime. How about --explain?
>> The end result is that you get a detailed explanation of what is happening.
>>
>> --test could be deprecated and --dry-run (like the 'make' parameter)
>> added to do the same with no-op as well.
>>
>> Cheers,
>> Adam.
>>
>
> How about simply --once ? Nice and quick to type.

To me, the option --once would be the same as --onetime and not include everything else it does.

[Patrick]

I hope this is a joke. I really think this name is a worse fit than "--test".

[R.I.Pienaar]

I run --test when I want to log into a machine and watch it do a run
in a slightly more verbose and debug/observation friendly manner.
'watch' seems to describe this use case well, it doesnt imply that no
changes will be made for example.

I'd want to run --test when I want it to imply what --test does today
but also --noop which is what most newcomers on irc also seem to think.
The word 'test' seems to imply a dry run

--
R.I.Pienaar

[Patrick]

Well, I see where you're coming from, but I see all flags as commands given to the program meaning you're telling puppet to do that thing. So, "--no-daemonize" tells puppet not to daemonize. In this case, I'd expect "watch" to tell puppet to watch something. I really think this is a bad choice of words.

[Adam Nielsen]

> Well, I see where you're coming from, but I see all flags as commands given
> to the program meaning you're telling puppet to do that thing. So,
> "--no-daemonize" tells puppet not to daemonize. In this case, I'd expect
> "watch" to tell puppet to watch something. I really think this is a bad
> choice of words.

The problem seems to be --test does so many things you can't concisely
describe it. In many ways something like --debug or --debug-runonce would be
a little better (primarily because it implies things won't be running at
maximum efficiency), but then you're not going to get it perfect unless you
call the option something like
--verbosely-run-once-non-daemonised-with-disabled-cache-and-some-other-things,
so it's always going to be a compromise.

Cheers,
Adam.

[Adam Nielsen]

> The problem seems to be --test does so many things you can't concisely
> describe it.

On the other hand, maybe --live-test would be good, as it makes it clear
changes will be made which seems to be the biggest complaint about --test.

Cheers,
Adam.

[Patrick]

I'd be happy with --live-test, although I think that "-t" should still be associated with it.

[Felix Frank]

I was under the impression that there was consensus that the semantics
of --test should not be changed, ever, in order not to break scripts out
there in the wild.
Deprecating and loosing --test altogether seems to be less of a problem.

I concur with Patrick in that puppetd --watch is about as misleading as
--test itself. I'd expect such an invocation to allow me to monitor the
regular proceedings of the background agent. It doesn't appear to imply
a forced ad hoc action, much less the cache semantics.

I still favor --manual.

Regards,
Felix

[R.I.Pienaar]

On 25 Jan 2011, at 10:30, Felix Frank <felix...@alumni.tu-berlin.de> wrote:

> On 01/24/2011 09:39 PM, R.I.Pienaar wrote:
>>
>>
>> ----- Original Message -----
>>> On Jan 24, 2011, at 11:17 AM, R.I.Pienaar wrote:
>>>
>>>> ----- Original Message -----
>>>>> If we don't want --manual you could go with --watch as that's
>>>>> really
>>>>> what I'm doing - watching puppet run. :)
>>>>
>>>>
>>>> I like --watch too
>>>
>>> I hope this is a joke. I really think this name is a worse fit than
>>> "--test".
>>
>> I run --test when I want to log into a machine and watch it do a run
>> in a slightly more verbose and debug/observation friendly manner.
>> 'watch' seems to describe this use case well, it doesnt imply that no
>> changes will be made for example.
>>
>> I'd want to run --test when I want it to imply what --test does today
>> but also --noop which is what most newcomers on irc also seem to think.
>> The word 'test' seems to imply a dry run
>
> I was under the impression that there was consensus that the semantics
> of --test should not be changed, ever, in order not to break scripts out
> there in the wild.
> Deprecating and loosing --test altogether seems to be less of a problem.

I wasn't suggesting a change merely stating the expectation the word test creates.

>
> I concur with Patrick in that puppetd --watch is about as misleading as
> --test itself. I'd expect such an invocation to allow me to monitor the
> regular proceedings of the background agent. It doesn't appear to imply
> a forced ad hoc action, much less the cache semantics.
>
> I still favor --manual.
>
> Regards,
> Felix
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[Thomas Bellman]

Nigel Kersten wrote:

> On Mon, Jan 24, 2011 at 12:27 AM, DEGREMONT Aurelien
> <aurelien....@cea.fr> wrote:

>> We never use puppetd in daemonized mode, and manual runs puppet when needed
>> with -t option.
>
> You shouldn't be doing this. If you're running puppet agent out of
> cron, you should do something like:
>
> puppetd --onetime --no-daemonize
>
> and not bring in all the ignoring of cache settings that --test does.

Why not? I run puppetd from cron with --no-usecacheonfailure.
If I manage to insert an error into my production environment,
I prefer that it does not try to apply an outdated catalog, and
instead give me an error message.

(Although when I tried it out now and introduced a deliberate fail()
in my manifests and ran puppetd with --usecacheonfailure, I got an
error when it couldn't parse the YAML it wrote on the previous run:

err: Cached catalog for soncweb.nsc.liu.se failed: Could not parse
YAML data for catalog soncweb.nsc.liu.se: syntax error on line
1234, col 43: ` !ruby/sym line: id:3:initdefault:'

But relying on the fact that Puppet can't parse what it has written
itself doesn't feel very robust, so I think I'll continue with
--no-usecacheonfailure... [This is Puppet 0.25.5, by the way.])

/Bellman

[Felix Frank]

> err: Cached catalog for soncweb.nsc.liu.se failed: Could not parse
> YAML data for catalog soncweb.nsc.liu.se: syntax error on line
> 1234, col 43: ` !ruby/sym line: id:3:initdefault:'

Funky. I bet you use pson for master->agent serialization (good choice).

YAML breaks when any of your parameter values end in a colon. I had
tripped this once in the past but pson fixed this for me and so far I
didn't have any further issues. Guess now a bug should be filed after all...

Cheers,
Felix

[Thomas Bellman]

On 2011-01-26 09:55, Felix Frank wrote:

>> err: Cached catalog for soncweb.nsc.liu.se failed: Could not parse
>> YAML data for catalog soncweb.nsc.liu.se: syntax error on line
>> 1234, col 43: ` !ruby/sym line: id:3:initdefault:'
>
> Funky. I bet you use pson for master->agent serialization (good choice).

I have made the concious choice to use the defaults, and since I use
0.25.5 (haven't had the time to test 2.6.x) that would mean PSON as
far as I understand, yes.

> YAML breaks when any of your parameter values end in a colon. I had
> tripped this once in the past but pson fixed this for me and so far I
> didn't have any further issues. Guess now a bug should be filed after all...

Hmm, 0.24.x used YAML in its communication protocol, right? I have had
that particular resource in my manifests (applied on all nodes) for 23
months, and I didn't switch to 0.25 until half a year later. Shouldn't
all my clients have failed to parse the catalog it received from the
master then?

/Bellman

[DEGREMONT Aurelien]

Nigel Kersten a �crit :

> On Mon, Jan 24, 2011 at 12:27 AM, DEGREMONT Aurelien
> <aurelien....@cea.fr> wrote:
>
>
>> Please take care that, for my site, and I think other ones,
>>
>> puppetd -t
>>
>> is *the* way to run puppet.
>> We never use puppetd in daemonized mode, and manual runs puppet when needed
>> with -t option.
>>
>
> You shouldn't be doing this. If you're running puppet agent out of
> cron, you should do something like:
>
> puppetd --onetime --no-daemonize
>
> and not bring in all the ignoring of cache settings that --test does.
>

I do want to ignorecache.
If someone is launching a puppet run, it wants to have the current
manifest being taken in account or fail if it cannot be reached.
Local caching of catalogs for puppetd is something we really do not want
to use.
(but this is useful for other scripts we have written based on a
R.I.Pienaar's script. We should push this on a mailing list one day)

And cron is only use to run puppet checks (puppetd -t --noop). Real
apply from puppet are only run manually.

>> Unfortunately, puppet guys do not really consider this aspect, that Puppet
>> could be (and it is) used in a CLI mode, and this is really useful (even
>> mandatory)
>>
>
> I don't understand what you mean. How is it that we don't consider
> this aspect? Many of our deployments run in this manner, primarily due
> to limitations of the underlying Ruby stack

The difference here is that you are speaking of "faking" a puppet deamon
using "cron + puppetd -t".
We do not use puppet as a daemon (whatever if this is with cron or not).

All puppet changes are applied with explicit and manual "puppetd -t"
All interactions with puppet are manual and CLI based. Admin should
manual valid that changes that are being applied are ok.
This is the kind of use of puppet that I think it rarely speak about here ;)

Due to this, we are working on improving the puppet cli experience here.
We developped some small wrappers, tools to help admin in this task.
We had some tickets opened, but this was not a succes. We are quite busy
currently, but I would like to push the patches we made. (an easy one
which should not be a problem to be integrated is about filebucket)

Here is :)

Aur�lien

[Felix Frank]

>> YAML breaks when any of your parameter values end in a colon. I had
>> tripped this once in the past but pson fixed this for me and so far I
>> didn't have any further issues. Guess now a bug should be filed after all...
>
> Hmm, 0.24.x used YAML in its communication protocol, right? I have had
> that particular resource in my manifests (applied on all nodes) for 23
> months, and I didn't switch to 0.25 until half a year later. Shouldn't
> all my clients have failed to parse the catalog it received from the
> master then?

Probably. Beatse me.

But I remember running into issues during our 0.24 -> 0.25 upgrade. I
enforced YAML serialization for a test, and many catalogs couldn't be
transferred because of this issue. Those *did* work for 0.24 clients
that may or may not have used YAML.

So I'm somewhat stumped. The bug you found should probably addressed in
any case. As a matter of fact, I have some parameters in my manifests
that should trigger this, so I will try and reproduce one of these days...

Cheers,
Felix

[Patrick]

On Jan 26, 2011, at 8:27 AM, DEGREMONT Aurelien wrote:

Nigel Kersten a écrit :

On Mon, Jan 24, 2011 at 12:27 AM, DEGREMONT Aurelien

<aurelien....@cea.fr> wrote:

 

Please take care that, for my site, and I think other ones,

puppetd -t

is *the* way to run puppet.

We never use puppetd in daemonized mode, and manual runs puppet when needed

with -t option.

   

You shouldn't be doing this. If you're running puppet agent out of

cron, you should do something like:

puppetd --onetime --no-daemonize

and not bring in all the ignoring of cache settings that --test does.

 

I do want to ignorecache.
If someone is launching a puppet run, it wants to have the current manifest being taken in account or fail if it cannot be reached.
Local caching of catalogs for puppetd is something we really do not want to use.
(but this is useful for other scripts we have written based on a R.I.Pienaar's script. We should push this on a mailing list one day)

You probably want --no-usecacheonfailure instead which will do what you want, but not recopy the catalog of the version on the server is the same as what's on the client.

[Nigel Kersten]

On Wed, Jan 26, 2011 at 8:27 AM, DEGREMONT Aurelien
<aurelien....@cea.fr> wrote:
> Nigel Kersten a écrit :

"cron + puppetd -t" is not a daemon. If I gave any other impression
that wasn't intended.

> All puppet changes are applied with explicit and manual "puppetd -t"
> All interactions with puppet are manual and CLI based. Admin should manual
> valid that changes that are being applied are ok.
> This is the kind of use of puppet that I think it rarely speak about here ;)

Many many many people run like this.

> Due to this, we are working on improving the puppet cli experience here. We
> developped some small wrappers, tools to help admin in this task.
> We had some tickets opened, but this was not a succes. We are quite busy
> currently, but I would like to push the patches we made. (an easy one which
> should not be a problem to be integrated is about filebucket)

We're definitely behind in processing community patches, but we've
been reasonably clear in letting the community know this.

> Here is :)

What was the "not a success" aspect of your tickets?

[Adam Stephens]

On Jan 23, 4:33 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:
> https://projects.puppetlabs.com/issues/2476
>
> This does seem to confuse a fair few new users.
>

> What would be a better name for "--test"?

What about "--manual" ?

[DEGREMONT Aurelien]

Nigel Kersten a �crit :

>> All puppet changes are applied with explicit and manual "puppetd -t"
>> All interactions with puppet are manual and CLI based. Admin should manual
>> valid that changes that are being applied are ok.
>> This is the kind of use of puppet that I think it rarely speak about here ;)
>>
>
> Many many many people run like this.
>

I'm happy to see that, but my feeling was different.
I rarely see topics about this kind of use and I'm mostly seeing
improvement (in puppet-dev) related to puppet as a daemon, and no CLI one.

2 examples:
. puppetd --test
This will output a log of lines with fancy colors :)
This really looks like (and in fact, it is) a log mode which is directly
output to console. For admins, expecially new ones you never use Puppet
before, this output is really difficult to understand.

. object selection
When you've got a lot of object not up to date, you deciced that you can
safely apply 'file:/foo' but you do not know why package 'bar' should be
uninstalled and you will asked your collegue John about that. So you
say: I only apply file 'foo' changes.
This can only be done using tags, but 'tags' is not strict, their is not
to say: "only a file named 'foo'"

This is two examples, but we had success for other patches :)

>> Here is :)
>>
> What was the "not a success" aspect of your tickets?
>

Patch was not finished and landed or feature could not have been
developped (either by puppetlabs or us)

Thank you to hake a look to all of this :)

Aur�lien