I just learned today that kafo/foreman-installer returns 2 if there are
no errors, but changes were made. I was told this is the same approach
that puppet use.
I absolutely hate that, when I issue any command on UNIX, I want to see
zero as success, any other return code for error state. If I need some
detailed error output, then let's add some extra option, but default
behavior should not surprise users.
Surprise which users? Some will be surprised if we match Puppet. Others
will be surprised if we don't. You can't please them all…
Given Kafo is a library for interacting with Puppet code, and the Foreman
Installer is a set of Puppet modules, I would expect it to follow Puppet's
return status. So I'm fine with it as it is.
···
On 1 October 2013 15:40, Lukas Zapletal wrote:
Hey,
I just learned today that kafo/foreman-installer returns 2 if there are
no errors, but changes were made. I was told this is the same approach
that puppet use.
I absolutely hate that, when I issue any command on UNIX, I want to see
zero as success, any other return code for error state. If I need some
detailed error output, then let’s add some extra option, but default
behavior should not surprise users.
> From: "Greg Sutcliffe" <greg.sutcliffe@gmail.com>
> To: "Foreman ." <foreman-dev@googlegroups.com>
> Sent: Tuesday, October 1, 2013 1:33:32 PM
> Subject: Re: [foreman-dev] Foreman installer / kafo / puppet return code
>
>
> > Hey,
> >
> > I just learned today that kafo/foreman-installer returns 2 if there are
> > no errors, but changes were made. I was told this is the same approach
> > that puppet use.
> >
> > I absolutely hate that, when I issue any command on UNIX, I want to see
> > zero as success, any other return code for error state. If I need some
> > detailed error output, then let's add some extra option, but default
> > behavior should not surprise users.
> >
>
> Surprise which users? Some will be surprised if we match Puppet. Others
> will be surprised if we don't. You can't please them all…
>
> Given Kafo is a library for interacting with Puppet code, and the Foreman
> Installer is a set of Puppet modules, I would expect it to follow Puppet's
> return status. So I'm fine with it as it is.
Agreed. Especially if people are replacing the method we used before generate_answers existed (echo'ing the module to puppet apply) then we should have the same exit codes so wrapper scripts and other things that people may have written won't need to be changed.
···
----- Original Message -----
> On 1 October 2013 15:40, Lukas Zapletal wrote:
> > > I absolutely hate that, when I issue any command on UNIX, I want to see
> > > zero as success, any other return code for error state. If I need some
> > > detailed error output, then let's add some extra option, but default
> > > behavior should not surprise users.
> > >
> > Surprise which users? Some will be surprised if we match Puppet. Others
> > will be surprised if we don't. You can't please them all…
> >
> > Given Kafo is a library for interacting with Puppet code, and the Foreman
> > Installer is a set of Puppet modules, I would expect it to follow Puppet's
> > return status. So I'm fine with it as it is.
>
> Agreed. Especially if people are replacing the method we used before generate_answers existed (echo'ing the module to puppet apply) then we should have the same exit codes so wrapper scripts and other things that people may have written won't need to be changed.
It's not the default behaviour, it's only by request when
–detailed-exitcodes is used (as kafo does). It's clearly documented in
both the puppet agent and kafo docs.
···
On 02/10/13 08:33, Lukas Zapletal wrote:
>>>> I absolutely hate that, when I issue any command on UNIX, I want to see
>>>> zero as success, any other return code for error state. If I need some
>>>> detailed error output, then let's add some extra option, but default
>>>> behavior should not surprise users.
>>>>
>>> Surprise which users? Some will be surprised if we match Puppet. Others
>>> will be surprised if we don't. You can't please them all...
>>>
>>> Given Kafo is a library for interacting with Puppet code, and the Foreman
>>> Installer is a set of Puppet modules, I would expect it to follow Puppet's
>>> return status. So I'm fine with it as it is.
>>
>> Agreed. Especially if people are replacing the method we used before generate_answers existed (echo'ing the module to puppet apply) then we should have the same exit codes so wrapper scripts and other things that people may have written won't need to be changed.
>
> This behavior of Puppet is sick...
I still prefer the detailed exit codes, though. To most people, the output
is far more important than the exit code. They will use the visible output
from RC3 to know that the run was successsful.
Exit codes only matter when scripting, and when scripting you can account
for as many numbers as you like, and can use the more detailed exitcodes to
determine how to respond in your calling script.
···
On 2 October 2013 09:13, Dominic Cleal wrote:
It’s not the default behaviour, it’s only by request when
–detailed-exitcodes is used (as kafo does). It’s clearly documented in
both the puppet agent and kafo docs.
To please everybody we might add --detailed-exitcodes option to kafo.
Currently we enforce that. But I would vote for true by default.
···
On Wednesday 02 of October 2013 10:36:51 Greg Sutcliffe wrote:
> On 2 October 2013 09:13, Dominic Cleal wrote:
> > It's not the default behaviour, it's only by request when
> > --detailed-exitcodes is used (as kafo does). It's clearly documented in
> > both the puppet agent and kafo docs.
>
> I stand corrected :)
>
> I still prefer the detailed exit codes, though. To most people, the output
> is far more important than the exit code. They will use the visible output
> from RC3 to know that the run was successsful.
>
> Exit codes only matter when scripting, and when scripting you can account
> for as many numbers as you like, and can use the more detailed exitcodes to
> determine how to respond in your calling script.
Any UNIX command that does not return 0 on success and other code for
error is just wrong. I don't change this opinion here.
Although if there is some special option that gives you more detailed
error codes, I am fine with this. But the default behavior (no options)
should fulfill what was said.
Currently if I start foreman-installer (without any special options) and
it configures without any error, it gives me 2 in some cases. This is
wrong, we should change that.
···
On Wed, Oct 02, 2013 at 12:56:41PM +0200, Marek Hulan wrote:
> To please everybody we might add --detailed-exitcodes option to kafo.
> Currently we enforce that. But I would vote for true by default.
