Bug #11292
closed
sync plans can be created and assigned, but don't trigger syncs
Description
1. I create a sync plan - for example, daily. The task completes successfully.
2. I apply that plan to product. The update completes successfully.
3. Nothing happens at the specified time.
/var/log/foreman/production.log contains a record for the creation of the sync-plan/association with a product, but I don't see any other errors at the time of the event.
Backend System Status:
Component Status Message
candlepin OK
candlepin_auth OK
elasticsearch OK
foreman_tasks OK
pulp OK
pulp_auth OK
Installed Packages:
candlepin-0.9.45-1.el6.noarch
candlepin-common-1.0.22-1.el6.noarch
candlepin-selinux-0.9.45-1.el6.noarch
candlepin-tomcat6-0.9.45-1.el6.noarch
elasticsearch-0.90.10-7.el6.noarch
katello-2.2.1-0.el6.noarch
katello-certs-tools-2.0.1-1.el6.noarch
katello-common-2.2.1-0.el6.noarch
katello-debug-2.2.1-0.el6.noarch
katello-default-ca-1.0-1.noarch
katello-installer-2.2.2-1.el6.noarch
katello-installer-base-2.2.2-1.el6.noarch
katello-repos-2.2.1-1.el6.noarch
katello-selinux-2.2.1-1.el6.noarch
katello-server-ca-1.0-1.noarch
katello-service-2.2.1-0.el6.noarch
libqpid-dispatch-0.4-4.el6.x86_64
m2crypto-0.21.1.pulp-8.el6.x86_64
mod_wsgi-3.4-2.pulp.el6.x86_64
ptnousvapp100.rnet.dstl.gov.uk-qpid-broker-1.0-1.noarch
ptnousvapp100.rnet.dstl.gov.uk-qpid-client-cert-1.0-1.noarch
ptnousvapp100.rnet.dstl.gov.uk-qpid-router-client-1.0-1.noarch
ptnousvapp100.rnet.dstl.gov.uk-qpid-router-server-1.0-1.noarch
pulp-docker-plugins-0.2.2-1.el6.noarch
pulp-katello-0.4-1.el6.noarch
pulp-nodes-common-2.6.0-1.el6.noarch
pulp-nodes-parent-2.6.0-1.el6.noarch
pulp-puppet-plugins-2.6.0-1.el6.noarch
pulp-puppet-tools-2.6.0-1.el6.noarch
pulp-rpm-plugins-2.6.0-1.el6.noarch
pulp-selinux-2.6.0-1.el6.noarch
pulp-server-2.6.0-1.el6.noarch
python-gofer-qpid-2.5.3-1.el6.noarch
python-isodate-0.5.0-4.pulp.el6.noarch
python-kombu-3.0.24-5.pulp.el6.noarch
python-pulp-bindings-2.6.0-1.el6.noarch
python-pulp-common-2.6.0-1.el6.noarch
python-pulp-docker-common-0.2.2-1.el6.noarch
python-pulp-puppet-common-2.6.0-1.el6.noarch
python-pulp-rpm-common-2.6.0-1.el6.noarch
python-qpid-0.30-7.el6.noarch
python-qpid-qmf-0.30-5.el6.x86_64
python-rhsm-1.8.0-2.pulp.el6.x86_64
qpid-cpp-client-0.30-7.proton.0.9.el6.x86_64
qpid-cpp-client-devel-0.30-7.proton.0.9.el6.x86_64
qpid-cpp-server-0.30-7.proton.0.9.el6.x86_64
qpid-cpp-server-linearstore-0.30-7.proton.0.9.el6.x86_64
qpid-dispatch-router-0.4-4.el6.x86_64
qpid-proton-c-0.9-2.el6.x86_64
qpid-qmf-0.30-5.el6.x86_64
qpid-tools-0.30-4.el6.noarch
ruby193-rubygem-katello-2.2.2-2.el6.noarch
ruby193-rubygem-qpid_messaging-0.30.0-1.el6.x86_64
rubygem-hammer_cli_katello-0.0.14-1.el6.noarch
rubygem-smart_proxy_pulp-1.0.1-1.el6.noarch
Updated by Eric Helms over 8 years ago
- Status changed from New to Need more information
- translation missing: en.field_release changed from 61 to 31
- Triaged changed from No to Yes
Do you ever see a sync kicked off? Perhaps at another time? I want to narrow down whether it never kicks off or if we have a mismatch between your expected time and the actual time.
Updated by J C over 8 years ago
No, no evidence of anything starting at any time. I've waited days for a plan set to daily. I did wonder whether there is a mismatch between time as Foreman/Katello sees it and the OS...but how to show that?
Updated by Eric Helms over 8 years ago
You can try adding https://gist.github.com/ehelms/52405ed3e75ec54ed91f to /usr/share/foreman/Rakefile and then running 'foreman-rake list_active_sync_schedules' which will output the schedules from Pulp's view point.
Updated by J C over 8 years ago
Thanks for the suggestion Eric, I've actually done that before, but should have said so.
As it happens, I was in the middle of searching for this bug to add an update....Having not changed a thing or done any updates, honest, I came back to work after the weekend to find that the new plans I create now work!? In fact, if you start a new plan, the time it starts off with is the current time (rather than one hour from now). No idea. But pleased. As no one else seems to be experiencing this issue I suggest we close it. Thanks though.
Updated by Eric Helms over 8 years ago
- Status changed from Need more information to Resolved