SM3: Failed patch job scheduled for future time

I have the latest SM3 version installed and in testing. I attempted to install some patches to a SLES12-SP1 system for a future time. The action was scheduled to begin no earlier than 12:50AM CDT and, according to the event history, it was completed at 01:00AM CDT. The patch attempt failed. However, the event history provides absolutely no detailed information as to why it failed. The details from the job history follow. How can I get detailed information on why this job failed?

[QUOTE]This action will be executed after 4/7/17 12:50:00 AM CDT
This action’s status is: Failed.
The client completed this action on 4/7/17 1:00 AM
Client execution returned
There was no job cache entry.
(code -1)

Patches Affected:
SUSE-12-SP1-2017-451 - moderate: Security update for wget
SUSE-12-SP1-2017-326 - moderate: Security update for libquicktime
SUSE-12-SP1-2017-551 - moderate: Security update for jasper
SUSE-12-SP1-2017-542 - low: Security update for audiofile[/QUOTE]

I am seeing another issue with patches scheduled for a future time. When the scheduled time arrives, the list of patches requested is installed fairly quickly, based on /var/log/zypper.log. However, after the installation of the patch, SM takes awhile before failing the package (in this case, the patches were installed at 13:12 and the package failed at 14:00). Installing the patch immediately does not involve this delay. It is only when the patch is scheduled for a future time. So it seems there is some communication failure between SM and the client when a patch is scheduled in the future.

Has anyone experienced this?

On Fri, 07 Apr 2017 14:14:02 +0000, achinayoung waubonsee wrote:
[color=blue]

I have the latest SM3 version installed and in testing. I attempted to
install some patches to a SLES12-SP1 system for a future time. The
action was scheduled to begin no earlier than 12:50AM CDT and, according
to the event history, it was completed at 01:00AM CDT. The patch attempt
failed. However, the event history provides absolutely no detailed
information as to why it failed. The details from the job history
follow. How can I get detailed information on why this job failed?
[color=green]

This action will be executed after 4/7/17 12:50:00 AM CDT This action’s
status is: Failed.
The client completed this action on 4/7/17 1:00 AM Client execution
returned
There was no job cache entry.
(code -1)[/color][/color]

That’s a bug (IMHO). I had to open an SR to get through making it work.
We did a lot of things, and I’ve been working with support on three or
four different SuMa SRs. Minimally, you have to be on the latest version
of SuMa, the latest patches for the Minions, and there are some
(otherwise undocumented, as far as I can tell) Minion configurations that
have to be applied.


David Gersic
Knowledge Partner http://forums.microfocus.com
If you find this post helpful, please click on the star below.

[QUOTE]That’s a bug (IMHO). I had to open an SR to get through making it work.
We did a lot of things, and I’ve been working with support on three or
four different SuMa SRs. Minimally, you have to be on the latest version
of SuMa, the latest patches for the Minions, and there are some
(otherwise undocumented, as far as I can tell) Minion configurations that
have to be applied.[/QUOTE]

We have the latest SuMa installed and therefore the latest salt version for the minions. Guess we’ll have to open a ticket to figure out how to make this work.

On Tue, 11 Apr 2017 15:24:01 +0000, achinayoung waubonsee wrote:
[color=blue][color=green]

That’s a bug (IMHO). I had to open an SR to get through making it work.
We did a lot of things, and I’ve been working with support on three or
four different SuMa SRs. Minimally, you have to be on the latest
version
of SuMa, the latest patches for the Minions, and there are some
(otherwise undocumented, as far as I can tell) Minion configurations
that
have to be applied.[/color]

We have the latest SuMa installed and therefore the latest salt version
for the minions. Guess we’ll have to open a ticket to figure out how to
make this work.[/color]

What version of SuMa? I’m on 3.0.4 here.

What version of the salt and salt-minion packages are installed on the
minions? (rpm -qa | grep salt)

I’ve been through a bunch of things on several SRs. I’m not actually sure
at this point what solved it, but I’m no longer seeing the mysterious
“code -1” here.


David Gersic
Knowledge Partner http://forums.microfocus.com
If you find this post helpful, please click on the star below.

[QUOTE=dgersic;37442]On Tue, 11 Apr 2017 15:24:01 +0000, achinayoung waubonsee wrote:
[color=blue][color=green]

That’s a bug (IMHO). I had to open an SR to get through making it work.
We did a lot of things, and I’ve been working with support on three or
four different SuMa SRs. Minimally, you have to be on the latest
version
of SuMa, the latest patches for the Minions, and there are some
(otherwise undocumented, as far as I can tell) Minion configurations
that
have to be applied.[/color]

We have the latest SuMa installed and therefore the latest salt version
for the minions. Guess we’ll have to open a ticket to figure out how to
make this work.[/color]

What version of SuMa? I’m on 3.0.4 here.

What version of the salt and salt-minion packages are installed on the
minions? (rpm -qa | grep salt)

I’ve been through a bunch of things on several SRs. I’m not actually sure
at this point what solved it, but I’m no longer seeing the mysterious
“code -1” here.[/QUOTE]

SLES11-SP3:
salt-2015.8.12-30.1
salt-minion-2015.8.12-30.1

SLES11-SP4:
salt-2015.8.12-30.1
salt-minion-2015.8.12-30.1

SLES12-SP1:
salt-minion-2015.8.12-33.1.x86_64
salt-2015.8.12-33.1.x86_64

I opened a support ticket for this issue.