Autodeploy should be considered as sucessfull even if exited with WARNING
k9ert opened this issue · comments
The autodeploy-feature is implemented like this:
exec { "Run_Puppi_${name}":
command => "puppi deploy ${name} && touch ${puppi::params::archivedir}/puppirun_${name}",
path => '/bin:/sbin:/usr/sbin:/usr/bin',
creates => "${puppi::params::archivedir}/puppirun_${name}",
}
In addition, puppi has a lot precheck-tests like this:
USERS OK - 1 users currently logged in |users=1;5;10;0
DISK OK - free space: / 110338 MB (96% inode=99%); /dev 10 MB (100% inode=99%); /vagrant 179148 MB (60% inode=100%); /tmp/vagrant-puppet/modules-0 179148 MB (60% inode=100%); /tmp/vagrant-puppet/manifests 179148 MB (60% inode=100%);| /=4272MB;96521;108586;0;120652 /dev=0MB;8;9;0;10 /vagrant=116144MB;236233;265762;0;295292 /tmp/vagrant-puppet/modules-0=116144MB;236233;265762;0;295292 /tmp/vagrant-puppet/manifests=116144MB;236233;265762;0;295292
OK: mailq is empty|unsent=0;2;5;0
OK - load average: 0.72, 0.61, 0.36|load1=0.720;15.000;30.000;0; load5=0.610;10.000;25.000;0; load15=0.360;5.000;20.000;0;
PROCS OK: 0 processes with STATE = Z
DNS OK: 0.060 seconds response time. example.com returns 192.0.43.10|time=0.060311s;;;0.000000
NTP OK: Offset 0.5200469494 secs|offset=0.520047s;60.000000;120.000000;
If one of these checks exit with 1 instead of 0, the overall exit-code of puppi deploy would also be 1 and therefore the autodeploy would fail. Because of that, the puppet-run will fail:
err:/Stage[main]//SomeModule::Gateway::App[gateway]/SomeModule:Appbase[gateway]/SomeModule::Appdeploy[gateway]/SomeModule::Autodeploy[gateway]/Puppi::Run[gateway]/Exec[Run_Puppi_gateway]/returns: change from notrun to 0 failed: puppi deploy gateway && touch /var/lib/puppi/archive/puppirun_gateway returned 1 instead of one of [0] at /tmp/vagrant-puppet/modules-0/puppi/manifests/run.pp:26
notice: Finished catalog run in 585.45 seconds�[0m
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
cd /tmp/vagrant-puppet/manifests && puppet apply --modulepath '/tmp/vagrant-puppet/modules-0' /tmp/vagrant-puppet/manifests/node.pp --detailed-exitcodes || [ $? -eq 2 ]
That is quite annoying. In our case, we run a jenkins which running "vagrant up" on a lot of server-roles and we have about once a month a situation where one of these checks fails and all the jobs are red. One reason for example was a situation where dnsutils was required in certain version by nagios-plugins and because the binary was not there, the check fails as well.
How we can deal with this situation. A simple workaround would be e.g.:
command => "puppi deploy
I'll do a pull-request based on this.
I'm afraid that was one of my worst pull-requests. There is a bad-syntax-error in run.pp:
command => "puppi deploy
should be:
command => "puppi deploy
will create another pull-request. I'm very sorry, i tested it on the commandline and simply pasted it in.
But shouldn't happen again, because i have a CI for a reason ;-).
dont worry, it's also my fault, i should check better pl and reactivate travis integration.