The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #9410

yumrepo type does notice changes

Added by Jascha Lee over 4 years ago. Updated about 4 years ago.

Status:DuplicateStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:yumrepo
Target version:-
Affected Puppet version:2.6.6 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

If the yum repo config file changes or disappears after the initial puppet run in which it was created or modified, subsequent puppet runs will not notice. The local change will remain (inconsistent with the catalog) and/or the removed file will not be reconstructed.

It was suggested that indentation of multiple gpgkey values might be at play, but this happens even with a single gpgkey value.

class yum {
    yumrepo {
        "tivo-coxrtltivoqa2sp01.tivo.com":
            descr    => "TiVo repo coxrtltivoqa2sp01.tivo.com",
            baseurl  => "http://$yumvar_reponame/yum/rpms",
            gpgkey   => "http://$yumvar_reponame/yum/GPG/RPM-GPG-KEY-MySQL",
            gpgcheck => "1",
            enabled  => "1";
    }
}

Related issues

Related to Puppet - Refactor #8758: Yumrepo should be refactored to use a provider In Topic Branch Pending Review

History

#1 Updated by James Turnbull over 4 years ago

  • Status changed from Unreviewed to Needs More Information
  • Assignee changed from James Turnbull to Jascha Lee

Can you show me some log output for this? I’ve never seen this happening. Can you replicate this with the simplest possible yumrepo resource and we’ll work up from there. Thanks!

#2 Updated by Jascha Lee over 4 years ago

  • Assignee changed from Jascha Lee to James Turnbull

I simplified the yumrepo manifest on the master and restarted it (by restarting httpd):

# cat /etc/puppet/modules/yum/manifests/init.pp
class yum {
    yumrepo {
        "tivo-coxrtltivoqa2sp01.tivo.com":
            descr    => "TiVo repo coxrtltivoqa2sp01.tivo.com",
            baseurl  => "http://coxrtltivoqa2sp01.tivo.com/yum/rpms";
    }
}

I reloaded the client:

# service puppet reload
Restarting puppet:                                         [  OK  ]

It didn’t notice the change:

# tail -f /var/log/messages
Sep 12 18:48:44 coxrtltivoqa2hd02 puppet-agent[28621]: Caught HUP; calling restart
Sep 12 18:48:44 coxrtltivoqa2hd02 puppet-agent[28621]: Restarting with '/usr/sbin/puppetd --server=coxrtltivoqa2sp01.tivo.com'
Sep 12 18:48:50 coxrtltivoqa2hd02 puppet-agent[31477]: Reopening log files
Sep 12 18:48:50 coxrtltivoqa2hd02 puppet-agent[31477]: Starting Puppet client version 2.6.6
Sep 12 18:48:59 coxrtltivoqa2hd02 puppet-agent[31477]: Finished catalog run in 0.72 seconds



# cat /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo
[tivo-coxrtltivoqa2sp01.tivo.com]
name=TiVo repo coxrtltivoqa2sp01.tivo.com
baseurl=http://coxrtltivoqa2sp01.tivo.com/yum/rpms
enabled=1
gpgcheck=1
gpgkey=http://coxrtltivoqa2sp01.tivo.com/yum/GPG/RPM-GPG-KEY-MySQL

So I removed the file, and reloaded again:

# rm /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo
# service puppet reload

And it noticed it this time:

# tail -f /var/log/messages
Sep 12 18:53:33 coxrtltivoqa2hd02 puppet-agent[31477]: Caught HUP; calling restart
Sep 12 18:53:33 coxrtltivoqa2hd02 puppet-agent[31477]: Restarting with '/usr/sbin/puppetd --server=coxrtltivoqa2sp01.tivo.com'
Sep 12 18:53:34 coxrtltivoqa2hd02 puppet-agent[440]: Reopening log files
Sep 12 18:53:34 coxrtltivoqa2hd02 puppet-agent[440]: Starting Puppet client version 2.6.6
Sep 12 18:53:37 coxrtltivoqa2hd02 puppet-agent[440]: (/Stage[main]/Yum/Yumrepo[tivo-coxrtltivoqa2sp01.tivo.com]/descr) descr changed '' to 'TiVo repo coxrtltivoqa2sp01.tivo.com'
Sep 12 18:53:37 coxrtltivoqa2hd02 puppet-agent[440]: (/Stage[main]/Yum/Yumrepo[tivo-coxrtltivoqa2sp01.tivo.com]/baseurl) baseurl changed '' to 'http://coxrtltivoqa2sp01.tivo.com/yum/rpms'
Sep 12 18:53:37 coxrtltivoqa2hd02 puppet-agent[440]: Finished catalog run in 0.59 seconds

I removed the file again, and simply waited for the regular puppet run:

# rm /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo
# tail -f /var/log/messages
Sep 12 19:23:38 coxrtltivoqa2hd02 puppet-agent[440]: Finished catalog run in 0.61 seconds
Sep 12 19:53:39 coxrtltivoqa2hd02 puppet-agent[440]: Finished catalog run in 0.59 seconds

# cat /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo
cat: /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo: No such file or directory
# service puppet reload
Sep 12 20:17:22 coxrtltivoqa2hd02 puppet-agent[440]: Caught HUP; calling restart
Sep 12 20:17:22 coxrtltivoqa2hd02 puppet-agent[440]: Restarting with '/usr/sbin/puppetd --server=coxrtltivoqa2sp01.tivo.com'
Sep 12 20:17:23 coxrtltivoqa2hd02 puppet-agent[23213]: Reopening log files
Sep 12 20:17:23 coxrtltivoqa2hd02 puppet-agent[23213]: Starting Puppet client version 2.6.6
Sep 12 20:17:25 coxrtltivoqa2hd02 puppet-agent[23213]: (/Stage[main]/Yum/Yumrepo[tivo-coxrtltivoqa2sp01.tivo.com]/descr) descr changed '' to 'TiVo repo coxrtltivoqa2sp01.tivo.com'
Sep 12 20:17:25 coxrtltivoqa2hd02 puppet-agent[23213]: (/Stage[main]/Yum/Yumrepo[tivo-coxrtltivoqa2sp01.tivo.com]/baseurl) baseurl changed '' to 'http://coxrtltivoqa2sp01.tivo.com/yum/rpms'
Sep 12 20:17:25 coxrtltivoqa2hd02 puppet-agent[23213]: Finished catalog run in 0.61 seconds

And then it came back:

# cat /etc/yum.repos.d/tivo-coxrtltivoqa2sp01.tivo.com.repo
[tivo-coxrtltivoqa2sp01.tivo.com]
name=TiVo repo coxrtltivoqa2sp01.tivo.com
baseurl=http://coxrtltivoqa2sp01.tivo.com/yum/rpms

#3 Updated by Stefan Schulte over 4 years ago

It looks like the yumrepo type uses a class variable (@inifile) that is used to store an in-memory representation of the yum repositories but never refreshes it between puppetruns. So if you run puppet as a daemon (and not out of cron for example) you’ll notice the described behaviour. Maybe this is best solved in #8758?

#4 Updated by James Turnbull about 4 years ago

  • Status changed from Needs More Information to Duplicate
  • Assignee deleted (James Turnbull)

Closing in favour of #8758.

Also available in: Atom PDF