Yumrepo resource flapping

[DjE]

Hi all,

We find that the yumrepo resource is flapping on RedHat 6 Enterprise with the redhat.repo file since Puppet 3.4.x version (due to a change about attribute content control)

We have updated with the latest Puppet 3.6 server and agent, because we saw this commit : https://github.com/puppetlabs/puppet/commit/9c25f75febe4df7d900e553824c9379cb7367c76, but the resource continues to flap.

The resource we want to manage : Yumrepo[rhel-6-server-optional-rpms]
The Puppet change : enabled changed ' 1' to '1'

RedHat want : "enabled= 1"
Puppet want : "enable=1"

As we can see, there is a white space on original state (RedHat generated file).

The change occurs every 4 hour (with 30 minutes runtime interval agent), i did not looking for the process which generate the redhat.repo file.

rhsm (/etc/rhsm/rhsm.conf) manage the yum repo file :

# Manage generation of yum repositories for subscribed content:
manage_repos = 1

[rhsmcertd]
# Frequency of certificate refresh (in minutes):
certFrequency = 240

The certFrequency seems to match with the change which occurs every 4 hours, i did not test it.

Djé

[jcbollinger]

The problem is that you are managing the same resource via two different services.  You are lucky that you are just flapping between two equivalent states.  Choose one system or the other to manage the configuration for that repo.


John

[DjE]

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/903782c7-828c-4fcb-9076-479c28650901%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi,

I agree with you about this potential conflict, but it's a default RedHat configuration with rhsm, and it does not manage exactly the same thing.

Puppet enable the "rhel-6-server-optional-rpms"  which is not by enabled default, and we never said rhsm to enable it (redhat subscription side), so rhsm respect the local decision made via Puppet with the Yumrepo, so it's just a syntax conflict,  it could be a nice thing that Puppet use the same syntax.

Puppet manage the rhsm.conf file so i tried to disable the manage_repos option, but the redhat.repo file has been destroyed by the rhsmcertd service, and disabled all RedHat repositories.
Then Puppet creates the /etc/yum.repos.d/rhel-6-server-optional-rpms.repo file with just the "enabled=1" parameter currently define by the Yumrepo resource.
We don't want to (re)define all the redhat repository urls one by one with the YumRepo resource, maybe there is a better solution.

Djé

[Johan De Wit]

the yumrepo resource creates a *.repo file for every resource.  The redhat thing just puts all repos in one big file.
and if you remove the redhat.repo, on a subscribed system, this file will be recreated depending on the subscribed channel.

I did not test it in puppet3.x, but maybe it could work : still on 2.7, and reworking our rep module is just sitting on the todo.

in redhat.rep, set enabled to 0 for all repos (augeas ?)
manage the redhat subscribed repos/channels with puppet

we do mirror all subscribes RH repos with mrepo, and point all or RH to the local repos.
also we register our systems using the subscription manager, to our local SAM (subscription asset manager ...) 

SAM does not work with rhn, so maybe moving to the subscription thing is not a bad idea.

something to look at ...   maybe ?

grts

jo

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/537B94C9.6000307%40nosbox.net.

For more options, visit https://groups.google.com/d/optout.

-- 
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer              (805008667232363)
Puppet Certified Professional 2013/2014 (PCP0000006)
_________________________________________________________
 
Open-Future                 Phone     +32 (0)2/255 70 70
Zavelstraat 72              Fax       +32 (0)2/255 70 71
3071 KORTENBERG             Mobile    +32 (0)474/42 40 73
BELGIUM                     http://www.open-future.be
_________________________________________________________
 

Upcoming Events:

Linux Training | https://www.open-future.be/linux-training-5-till-9th-may

Puppet Introduction Course | https://www.open-future.be/puppet-introduction-course-12th-may

Puppet Fundamentals Training | https://www.open-future.be/puppet-fundamentals-training-13-till-15th-may

Zabbix Certified Specialist | https://www.open-future.be/zabbix-certified-specialist-training-19-till-21th-may

Zabbix Certified Professional | https://www.open-future.be/zabbix-certified-professional-training-22-till-23rd-may

Subscribe to our newsletter: http://eepurl.com/BUG8H

[jcbollinger]

On Tuesday, May 20, 2014 12:45:45 PM UTC-5, DjE wrote:

I agree with you about this potential conflict, but it's a default RedHat configuration with rhsm, and it does not manage exactly the same thing.

Puppet enable the "rhel-6-server-optional-rpms"  which is not by enabled default, and we never said rhsm to enable it (redhat subscription side), so rhsm respect the local decision made via Puppet with the Yumrepo, so it's just a syntax conflict,

No, it's not.  rhsm is modifying the repository configuration file, even if it is modifying it to a form that is equivalent from Yum's perspective.  If rhsm may change the file in any way, then it's managing the file.

 

  it could be a nice thing that Puppet use the same syntax.

That might solve your particular issue, but Puppet cannot match the syntax details of every piece of software that might conceivably manage Yum repository files.  And it's not worthwhile to try, because the underlying problem is not a syntax conflict, it's that you have established overlapping management responsibilities on your system.

 

Puppet manage the rhsm.conf file so i tried to disable the manage_repos option, but the redhat.repo file has been destroyed by the rhsmcertd service, and disabled all RedHat repositories.
Then Puppet creates the /etc/yum.repos.d/rhel-6-server-optional-rpms.repo file with just the "enabled=1" parameter currently define by the Yumrepo resource.
We don't want to (re)define all the redhat repository urls one by one with the YumRepo resource, maybe there is a better solution.

You have the alternative of managing repo configuration files via a File resource instead of via a Yumrepo resource.  You can control every detail of the file's puppet-asserted content that way.  If you want to do that for multiple repo config files then you could consider creating a defined type for the purpose.  That's a little more limited than the Yumrepo resource type, however, because Yumrepo can manage existing repository definitions in whatever file they appear, whereas a File resource must manage a specific file.


John

[jcbollinger]

On Tuesday, May 20, 2014 4:24:01 PM UTC-5, Johan De Wit wrote:

the yumrepo resource creates a *.repo file for every resource.

Yes, if the repo definition does not already exist.  If it does exist then Puppet manages it in whatever file contains it.  Or it should do, and used to do.  I thought I had seen a ticket about a regression in that area, but I'm having trouble finding it now.

 

  The redhat thing just puts all repos in one big file.
and if you remove the redhat.repo, on a subscribed system, this file will be recreated depending on the subscribed channel.

One file or several should not be a problem for Puppet.

If the file continues to flap, however, instead of just flapping once, then something very strange is going on.  Puppet should not be modifying the file if all the managed properties are already in the correct target state, even if the location or formatting details are not what Puppet would use.  That would indeed be a bug that should be reported.


John