Bug 1396647 - Incorrect Next Sync date calculation in weekly Sync Plan
Summary: Incorrect Next Sync date calculation in weekly Sync Plan
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Management
Version: 6.1.5
Hardware: Unspecified
OS: Linux
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Walden Raines
QA Contact: Peter Ondrejka
URL: http://projects.theforeman.org/issues...
Whiteboard:
: 1463301 (view as bug list)
Depends On: 1302098 1463696
Blocks: 1463301
TreeView+ depends on / blocked
 
Reported: 2016-11-18 20:02 UTC by Bryan Kearney
Modified: 2020-02-14 18:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1302098
: 1463301 (view as bug list)
Environment:
Last Closed: 2018-02-21 17:09:12 UTC
Target Upstream Version:


Attachments (Terms of Use)
weekly-sync (19.78 KB, image/png)
2017-07-11 13:39 UTC, Peter Ondrejka
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21194 0 Normal Closed Incorrect Next Sync date calculation in weekly Sync Plan 2020-04-13 17:43:48 UTC

Comment 2 Djebran Lezzoum 2017-07-11 13:30:17 UTC
Automation tests are failing for this bug, even if the fix code exist on sat-server
reverting to assigned

Versions:
* candlepin-2.0.37-1.el7.noarch
* candlepin-selinux-2.0.37-1.el7.noarch
* foreman-1.15.1-1.el7sat.noarch
* foreman-cli-1.15.1-1.el7sat.noarch
* foreman-compute-1.15.1-1.el7sat.noarch
* foreman-debug-1.15.1-1.el7sat.noarch
* foreman-discovery-image-3.1.1-22.el7sat.noarch
* foreman-ec2-1.15.1-1.el7sat.noarch
* foreman-gce-1.15.1-1.el7sat.noarch
* foreman-installer-1.15.1-1.el7sat.noarch
* foreman-installer-katello-3.4.1.3-1.el7sat.noarch
* foreman-libvirt-1.15.1-1.el7sat.noarch
* foreman-openstack-1.15.1-1.el7sat.noarch
* foreman-ovirt-1.15.1-1.el7sat.noarch
* foreman-postgresql-1.15.1-1.el7sat.noarch
* foreman-proxy-1.15.0-2.el7sat.noarch
* foreman-rackspace-1.15.1-1.el7sat.noarch
* foreman-selinux-1.15.0-1.el7sat.noarch
* foreman-vmware-1.15.1-1.el7sat.noarch
* katello-3.4.2-1.el7sat.noarch
* katello-ca-consumer-sat-r220-02.lab.eng.rdu2.redhat.com-1.0-2.noarch
* katello-certs-tools-2.4.0-1.el7sat.noarch
* katello-client-bootstrap-1.4.0-1.el7sat.noarch
* katello-common-3.4.2-1.el7sat.noarch
* katello-debug-3.4.2-1.el7sat.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-base-3.4.1.3-1.el7sat.noarch
* katello-selinux-3.0.2-1.el7sat.noarch
* katello-server-ca-1.0-1.noarch
* katello-service-3.4.2-1.el7sat.noarch
* openldap-2.4.40-13.el7.x86_64
* pulp-client-1.0-1.noarch
* pulp-docker-plugins-2.3.0-1.el7sat.noarch
* pulp-katello-1.0.2-1.el7sat.noarch
* pulp-ostree-plugins-1.2.1-1.el7sat.noarch
* pulp-puppet-plugins-2.12.2-1.el7sat.noarch
* pulp-puppet-tools-2.12.2-1.el7sat.noarch
* pulp-rpm-plugins-2.12.2-2.el7sat.noarch
* pulp-selinux-2.12.2-2.el7sat.noarch
* pulp-server-2.12.2-2.el7sat.noarch
* python-ldap-2.4.15-2.el7.x86_64
* tfm-rubygem-ldap_fluff-0.4.6-1.el7sat.noarch
* tfm-rubygem-net-ldap-0.15.0-1.el7sat.noarch

Comment 3 Peter Ondrejka 2017-07-11 13:38:41 UTC
Reopening since this still occurs when sync plan's start date is exactly one week in past and start time is later than the time of creation. See the attached screenshot.

Comment 4 Peter Ondrejka 2017-07-11 13:39:46 UTC
Created attachment 1296258 [details]
weekly-sync

Comment 5 Peter Ondrejka 2017-07-11 13:41:14 UTC
*** Bug 1463301 has been marked as a duplicate of this bug. ***

Comment 6 Satellite Program 2017-07-11 14:08:42 UTC
Upstream bug assigned to walden@redhat.com

Comment 7 Satellite Program 2017-07-11 14:08:47 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16035 has been resolved.

Comment 8 John Mitsch 2017-08-09 15:13:43 UTC
Verified Sat 6.3 snap 9

The following seems like expected behavior to me, if it is not, please comment:

- Creating a sync plan in the future will make the start date and the next sync date the same

- Creating a start date in the past will result in the next sync date being the next occurrence of that day. If the sync starts on a Tuesday in the past, the next sync will be on a Tuesday. i.e. (plans created on Wed 2017/08/09):

weekly sync plan 1
Start Date
 2017/08/08 10:59:00 EDT (tues)
Next Sync
 2017/08/15 10:59:00 EDT (tues)

weekly sync plan 2
Start Date
 2017/07/03 11:01:00 EDT (mon)
Next Sync
 2017/08/14 11:01:00 EDT (mon)

Comment 9 Peter Ondrejka 2017-09-25 08:54:16 UTC
Hello John, I'm still able to reproduce my problem in satellite-6.3.0-18.0.beta.el7sat.noarch, I should explain better. This bug causes problems in testing automation, where we want to test weekly syncplans without needing to wait a long time. Therefore we set the start date a week ago from "now", but some time after current time. The aim is to force the syncplan to first execute minutes from "now". However, due to this bug, the first execution is skipped, and next sync is scheduled to a week from "now".

Hope this makes sense. I also noticed that I get -1 day when setting a start day, so e.g. I set 20th in UI, after saving I see 19th.

Could you please try to reproduce this? I suspect this could be also timezone-related.

Comment 10 John Mitsch 2017-09-25 13:15:24 UTC
Peter,

If you are still seeing this in a 6.3 snap, then I think what would be best is to mark it back to assigned, make sure that Walden fully understands the issue, and he can take another look at it.

-John

Comment 11 Walden Raines 2017-10-03 14:34:46 UTC
Hey Peter,

Do you see this same behavior if you use hammer or the API to create the sync plan?

(In reply to Peter Ondrejka from comment #9)
> Hello John, I'm still able to reproduce my problem in
> satellite-6.3.0-18.0.beta.el7sat.noarch, I should explain better. This bug
> causes problems in testing automation, where we want to test weekly
> syncplans without needing to wait a long time. Therefore we set the start
> date a week ago from "now", but some time after current time. The aim is to
> force the syncplan to first execute minutes from "now". However, due to this
> bug, the first execution is skipped, and next sync is scheduled to a week
> from "now".

Couldn't you test this by setting a weekly plan with the start date a week prior to now plus a few minutes?

> Hope this makes sense. I also noticed that I get -1 day when setting a start
> day, so e.g. I set 20th in UI, after saving I see 19th.
> 
> Could you please try to reproduce this? I suspect this could be also
> timezone-related.

I wonder if this is a duplicate of bug #1438845.  Are you still able to reproduce this on a recent snap?

Comment 12 Peter Ondrejka 2017-10-04 12:52:41 UTC
Hi Walden,

(In reply to Walden Raines from comment #11)
> Hey Peter,
> 
> Do you see this same behavior if you use hammer or the API to create the
> sync plan?

Yes the same problem when using hammer

> 
> Couldn't you test this by setting a weekly plan with the start date a week
> prior to now plus a few minutes?

yes, that is what I'm trying to do, good rephrase :)

> > Hope this makes sense. I also noticed that I get -1 day when setting a start
> > day, so e.g. I set 20th in UI, after saving I see 19th.

Ok this is another problem and happens only in UI, with start date in the future the next sync is calculated correctly, but the start date is decreased by one day for some reason. So I set start date e.g. on 3rd expecting resync on 10th, after saving I see start date on 2nd with resync on 9th, do you want a separate bug for this?

> 
> I wonder if this is a duplicate of bug #1438845.  Are you still able to
> reproduce this on a recent snap?

yes, also reproducible when setting UTC or a different timezone in user settings

Looking at the code in the associated pr (https://github.com/Katello/katello/pull/6238/files#diff-cbbf4a31420b097c086fac10249ad959), I think the problem is here:

+          days = self.sync_date.wday - now.wday
+          days += 7 if days <= 0

So if I set date one week from now, days will be 0 and I'll get +7 no matter what. So the if should be extended to add week only if time is also less than now

Cheers

Comment 13 Walden Raines 2017-10-04 13:43:19 UTC
(In reply to Peter Ondrejka from comment #12)
> Ok this is another problem and happens only in UI, with start date in the
> future the next sync is calculated correctly, but the start date is
> decreased by one day for some reason. So I set start date e.g. on 3rd
> expecting resync on 10th, after saving I see start date on 2nd with resync
> on 9th, do you want a separate bug for this?

Yes please.

Comment 14 Walden Raines 2017-10-04 13:48:42 UTC
Created redmine issue http://projects.theforeman.org/issues/21194 from this bug

Comment 15 Walden Raines 2017-10-04 13:57:44 UTC
This is what I see in master.

It was 9:50 when I tried this.

1. Set start time to 9:55, results:

Start Date
 2017/10/04 09:55:00 -0400
Next Sync
 2017/10/04 09:55:00 -0400

2. Set start time to 9:45, results:

Start Date
 2017/10/04 09:45:00 -0400
Next Sync
 2017/10/11 09:45:00 -0400

To me this appears to be correct.  Do you agree?

If so, I will just need to track down the change in master that fixes this and get it into 6.3

Comment 16 Walden Raines 2017-10-04 14:47:11 UTC
(In reply to Walden Raines from comment #15)
> This is what I see in master.
> 
> It was 9:50 when I tried this.
> 
> 1. Set start time to 9:55, results:
> 
> Start Date
>  2017/10/04 09:55:00 -0400
> Next Sync
>  2017/10/04 09:55:00 -0400
> 
> 2. Set start time to 9:45, results:
> 
> Start Date
>  2017/10/04 09:45:00 -0400
> Next Sync
>  2017/10/11 09:45:00 -0400
> 
> To me this appears to be correct.  Do you agree?
> 
> If so, I will just need to track down the change in master that fixes this
> and get it into 6.3

This also works for me the same in the latest 6.3 snap.  Please advise.

Comment 17 Peter Ondrejka 2017-10-05 08:34:35 UTC
There are two conditions to see this bug:
a. start date exactly week from now in the past
b. start time is later than now

-- Suppose "now" is 2017/10/05 10:00:00
-- I want to test weekly sync works and I want to set it so that it executes in 5 mins from now, so I set start date and time to: 2017/09/28 10:05:00
-- what I expect is next sync 2017/10/05 10:05:00, what I actually get is next sync 2017/10/12 10:05:00

Comment 18 Peter Ondrejka 2017-10-05 09:27:03 UTC
filed a bug for ui syncplan decrement here https://bugzilla.redhat.com/show_bug.cgi?id=1498793

Comment 19 Walden Raines 2017-10-05 15:04:02 UTC
PR: https://github.com/Katello/katello/pull/6990

Comment 22 Peter Ondrejka 2017-10-24 15:20:41 UTC
Verified in satellite-6.3.0-21.0.beta.el7sat.noarch, automation also looks happy

Comment 23 Bryan Kearney 2018-02-21 16:43:36 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336

Comment 24 Bryan Kearney 2018-02-21 17:09:12 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA.

For information on the advisory, and where to find the updated files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336


Note You need to log in before you can comment on or make changes to this bug.