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
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.
Created attachment 1296258 [details] weekly-sync
*** Bug 1463301 has been marked as a duplicate of this bug. ***
Upstream bug assigned to walden
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16035 has been resolved.
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)
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.
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
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?
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
(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.
Created redmine issue http://projects.theforeman.org/issues/21194 from this bug
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
(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.
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
filed a bug for ui syncplan decrement here https://bugzilla.redhat.com/show_bug.cgi?id=1498793
PR: https://github.com/Katello/katello/pull/6990
Verified in satellite-6.3.0-21.0.beta.el7sat.noarch, automation also looks happy
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