Bug 1288543 - changes to puppet classes not immediately active
changes to puppet classes not immediately active
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Configuration Management (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: Unspecified
: --
Assigned To: satellite6-bugs
Katello QA List
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2015-12-04 09:30 EST by David Juran
Modified: 2017-01-12 14:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-01-12 14:13:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Juran 2015-12-04 09:30:42 EST
Description of problem:
I've noticed that sometimes a change in a puppet class on the satellite server is not immediately visible to a client.

I'm currently working on developing some puppet modules so I've created a custom environment on the satellite (/etc/puppet/environments/testing) where I have my git checkout.

 Whenever I do a change in one of the classes, I run 

hammer proxy import-classes --name <my_satellite> --environment testing
And then on the client, I run "puppet agent -td" to see what happens

I've noticed however that sometimes, the changes are not seen by the client on the first run, rather what is executed is the old class without the changes is being executed. Highly annoying.

Is there something I'm missing, some part of the importing to the puppet master that happens in the background? And if so, is there a way of finding out if it's done?

Various suggestions I've received is to delete /var/lib/puppet/client_data/* on the client, though to my understanding puppet agent --test should ignore cache.

Another suggestions is to restart the puppet master on the satellite server (httpd).

Ideally, I would like hammer not to return before everything really was finished so to speak.

Version-Release number of selected component (if applicable):
Comment 1 Bryan Kearney 2016-07-26 15:09:20 EDT
Moving 6.2 bugs out to sat-backlog.
Comment 2 Bryan Kearney 2017-01-12 14:13:00 EST
This is an older bug which I do not envision being addressed in the near term. I am closing this out. If you believe doing so is an issue, please feel free to re-open and provide additional business information. Thank you.

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