Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1017345 - Updating existing sync schedule does not change effective schedule.
Summary: Updating existing sync schedule does not change effective schedule.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Management
Version: 6.0.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: Unspecified
Assignee: Katello Bug Bin
QA Contact: Garik Khachikyan
URL:
Whiteboard:
Depends On: 959031
Blocks: 950743
TreeView+ depends on / blocked
 
Reported: 2013-10-09 17:07 UTC by Eric Helms
Modified: 2015-01-04 22:00 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 959031
Environment:
Last Closed:
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Eric Helms 2013-10-09 17:07:11 UTC 
+++ This bug was initially created as a clone of Bug #959031 +++

Description of problem:

Updating an existing repositories sync schedule-id to a new interval does not modify the actual interval. Though command shows success and task shows success.


Version-Release number of selected component (if applicable):

2.1.1-0.5.beta.el6.noarch

How reproducible:

Everytime

Steps to Reproduce:
1. Create a sync schedule of P1D for a given repository
2. Verify new sync schedule shows
3. Change existing sync schedule using sync schedules update subcommand to PT8M.

  
Actual results:

Check next scheduled sync interval, it will still be for P1D.

Expected results:

Next scheduled sync interval should reflect the more aggressive interval.

Additional info:

Deletion and Creation of a new schedule is the current workaround.

--- Additional comment from Michael Hrivnak on 2013-06-21 09:25:09 EDT ---

Is this related to https://bugzilla.redhat.com/show_bug.cgi?id=968524 ?

--- Additional comment from Jason Connor on 2013-09-13 16:42:11 EDT ---

PR issued for this:
https://github.com/pulp/pulp/pull/612

--- Additional comment from Jason Connor on 2013-09-17 17:35:28 EDT ---

Fix in commit 51c93ef6371dfb57b12f917e4b2d1103354a5720

--- Additional comment from Jeff Ortel on 2013-09-18 19:58:48 EDT ---

build: 2.3.0-0.14.alpha

--- Additional comment from Preethi Thomas on 2013-09-20 08:54:34 EDT ---

verified
[root@pulp-v2-server ~]# rpm -qa pulp-server
pulp-server-2.3.0-0.14.alpha.el6.noarch
[root@pulp-v2-server ~]# 

[root@pulp-v2-server ~]# pulp-admin rpm repo sync schedules list --repo-id zoo1+----------------------------------------------------------------------+
                               Schedules
+----------------------------------------------------------------------+

There are no schedules defined for this operation.

[root@pulp-v2-server ~]# pulp-admin rpm repo sync schedules create -s 2013-09-19T12:51:00Z/P1D --repo-id zoo1
Schedule successfully created

[root@pulp-v2-server ~]# 
[root@pulp-v2-server ~]# 
[root@pulp-v2-server ~]# pulp-admin rpm repo sync schedules list --repo-id zoo1+----------------------------------------------------------------------+
                               Schedules
+----------------------------------------------------------------------+

Schedule: 2013-09-19T12:51:00Z/P1D
Id:       523c5640d669f05dff00067f
Enabled:  True
Last Run: None
Next Run: 2013-09-21T12:51:00Z


[root@pulp-v2-server ~]# pulp-admin rpm repo sync schedules update -s 2013-09-19T12:51:00Z/PT8M --repo-id zoo1 --schedule-id 523c5640d669f05dff00067f
Successfully updated schedule

[root@pulp-v2-server ~]# pulp-admin rpm repo sync schedules list --repo-id zoo1+----------------------------------------------------------------------+
                               Schedules
+----------------------------------------------------------------------+

Schedule: 2013-09-19T12:51:00Z/PT8M
Id:       523c5640d669f05dff00067f
Enabled:  True
Last Run: None
Next Run: 2013-09-20T14:11:00Z


[root@pulp-v2-server ~]#
Comment 3 Garik Khachikyan 2013-10-21 13:27:44 UTC 
# VERIFIED

well, `sync_plan update` cli failed (and there was open a bug on it for a loong time).

UI update of the sync plan interval makes the update displayed correctly both in UI and CLI.

checked on:
===
* apr-util-ldap-1.3.9-3.el6_0.1.x86_64
* candlepin-0.8.25-1.el6sam.noarch
* candlepin-scl-1-5.el6_4.noarch
* candlepin-scl-quartz-2.1.5-5.el6_4.noarch
* candlepin-scl-rhino-1.7R3-1.el6_4.noarch
* candlepin-scl-runtime-1-5.el6_4.noarch
* candlepin-selinux-0.8.25-1.el6sam.noarch
* candlepin-tomcat6-0.8.25-1.el6sam.noarch
* elasticsearch-0.19.9-8.el6sat.noarch
* foreman-1.3.0-18.el6sat.noarch
* foreman-compute-1.3.0-18.el6sat.noarch
* foreman-libvirt-1.3.0-18.el6sat.noarch
* foreman-postgresql-1.3.0-18.el6sat.noarch
* foreman-proxy-1.3.0-3.el6sat.noarch
* katello-1.4.6-39.el6sat.noarch
* katello-all-1.4.6-39.el6sat.noarch
* katello-candlepin-cert-key-pair-1.0-1.noarch
* katello-certs-tools-1.4.4-1.el6sat.noarch
* katello-cli-1.4.3-24.el6sat.noarch
* katello-cli-common-1.4.3-24.el6sat.noarch
* katello-common-1.4.6-39.el6sat.noarch
* katello-configure-1.4.7-5.el6sat.noarch
* katello-configure-foreman-1.4.7-5.el6sat.noarch
* katello-configure-foreman-proxy-1.4.7-5.el6sat.noarch
* katello-foreman-all-1.4.6-39.el6sat.noarch
* katello-glue-candlepin-1.4.6-39.el6sat.noarch
* katello-glue-elasticsearch-1.4.6-39.el6sat.noarch
* katello-glue-pulp-1.4.6-39.el6sat.noarch
* katello-qpid-broker-key-pair-1.0-1.noarch
* katello-qpid-client-key-pair-1.0-1.noarch
* katello-selinux-1.4.4-4.el6sat.noarch
* openldap-2.4.23-31.el6.x86_64
* pulp-katello-plugins-0.2-1.el6sat.noarch
* pulp-nodes-common-2.3.0-0.22.beta.el6sat.noarch
* pulp-nodes-parent-2.3.0-0.22.beta.el6sat.noarch
* pulp-puppet-plugins-2.3.0-0.22.beta.el6sat.noarch
* pulp-rpm-plugins-2.3.0-0.22.beta.el6sat.noarch
* pulp-selinux-2.3.0-0.22.beta.el6sat.noarch
* pulp-server-2.3.0-0.22.beta.el6sat.noarch
* python-ldap-2.3.10-1.el6.x86_64
* ruby193-rubygem-ldap_fluff-0.2.2-2.el6sat.noarch
* ruby193-rubygem-net-ldap-0.3.1-3.el6sat.noarch
* ruby193-rubygem-runcible-1.0.7-1.el6sat.noarch
* signo-0.0.22-2.el6sat.noarch
* signo-katello-0.0.22-2.el6sat.noarch
Comment 6 Bryan Kearney 2014-04-24 17:11:07 UTC 
This was verified and delivered with MDP2. Closing it out.
Comment 7 Bryan Kearney 2014-04-24 17:12:07 UTC 
This was delivered and verified with MDP2. Closing the bug.
Note You need to log in before you can comment on or make changes to this bug.