[MODULES-7422] Yumrepo target attribute does not work Created: 2014/06/15  Updated: 2019/09/30

Status: Accepted
Project: Modules
Component/s: yumrepo_core
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: C Lang Assignee: Unassigned
Resolution: Unresolved Votes: 28
Labels: puppethack, type_and_provider, yumrepo
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to PUP-8542 document that the property 'target' f... Closed
relates to PUP-723 Due to prefetching, Yumrepo clobbers ... Closed
Template:
Team: Coremunity
QA Contact: Eric Thompson

 Description   

Simplified example:

    yumrepo { 'foo-bar':
      descr  => 'Foo Bar',
      target => '/tmp/foo-bar.repo'
    }
 
    yumrepo { 'foo-bat':
      descr  => 'Foo Bat',
      target => '/tmp/foo-bar.repo'
    }

Notice: /Stage[main]/Yum/Yumrepo[foo-bat]/ensure: created
Info: changing mode of /etc/yum.repos.d/foo-bat.repo from 600 to 644
Notice: /Stage[main]/Yum/Yumrepo[foo-bar]/ensure: created
Info: changing mode of /etc/yum.repos.d/foo-bar.repo from 600 to 644



 Comments   
Comment by Tim Meusel [ 2014/10/23 ]

Same issue here on Puppet 3.7.1 and 3.7.2:

  yumrepo{'puppetrepo-products':
    name      => 'puppetrepo-products',
    descr     => 'Puppet Labs Products El 7 - $basearch',
    ensure    => 'present',
    baseurl   => 'http://myownmirror',
    gpgkey    => 'http://myownmirror',
    enabled   => '1',
    gpgcheck  => '1',
    target    => '/etc/yum.repo.d/puppetlabs.repo',
  }
  yumrepo{'puppetrepo-deps':
    name      => 'puppetrepo-deps',
    descr     => 'Puppet Labs Dependencies El 7 - $basearch',
    ensure    => 'present',
    baseurl   => 'http://myownmirror',
    gpgkey    => 'http://myownmirror',
    enabled   => '1',
    gpgcheck  => '1',
    target    => '/etc/yum.repo.d/puppetlabs.repo',
  }

which creates two seperate files, /etc/yum.repos.d/puppetrepo-products.repo and /etc/yum.repos.d/puppetrepo-deps.repo (my approach was to modify the default puppetlabs.repo file which gets created via the puppetlabs-release-el-6.noarch.rpm)

Comment by Tim Meusel [ 2014/10/23 ]

this is maybe related, the following doesn't provide a valid manifest with a target attribute:

# puppet resource yumrepo puppetlabs-products
yumrepo { 'puppetlabs-products':
  ensure   => 'present',
  baseurl  => 'http://yum.puppetlabs.com/el/7/products/$basearch',
  descr    => 'Puppet Labs Products El 7 - $basearch',
  enabled  => '1',
  gpgcheck => '1',
  gpgkey   => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabs',
  priority => '2',
}

Comment by Hunter (Hunner) Haugen [ 2014/10/24 ]

The yumrepo resource type defines target to be a parameter 1 and so therefore it is not read from the system during self.instances as a property would be, and thus cannot be updated by itself. (Parameters are used to modify the behavior of the provider when sync'ing properties, but are not themselves sync'd.)

But it doesn't seem to be taken into account even when creating the repo... during the create, the provider calls the store class method 2 which is for a Puppet::Util::IniConfig object 3. (NB, virtual_inifile is a collection of all .repo files into one big ini structure.) The iniconfig file collection will store each ini structure in a file named after its key in the virtual_inifile object 4 which doesn't take target into account at all.

To start fixing this, it would probably require updating the description section 5 to be able to use target instead of descr if it is available, and the description is not currently one of the pre-existing sections. But that would probably also run into issues with destroying 6, among other things.

I assume we would not want to allow targets to be changed once a repo entry exists... or at least I can't imagine how puppet would handle such an operation.

Comment by Tim Meusel [ 2014/11/06 ]

we had a little discussion in the IRC about this issue. Somebody (maybe Hunter?) mentioned to remove the yumrepo type from the puppet core and put it into an own module as this would be easier as fixing the code. Any thoughts on that?

Comment by Nathanael Cole [ 2015/11/03 ]

Still a bug in 3.8.2.

On CentOS 6.6:

yumrepo {'repo1':
        baseurl  => "http://yumreposerver/yum/OracleLinux/OL6/1/base/i386",
        descr    => 'Bobs Happy Fun Oracle Linux Repo',
        target   => '/etc/yum.repos.d/bob/repo1.repo',
        ensure   => present,
        enabled   => false,
        gpgcheck => false,
}

This creates a "repo1.repo" in /etc/yum.repos.d/ instead of the specified /etc/yum.repos.d/bob/

If reposdir is set to /etc/yum.repos.d/bob/ in yum.conf then it gets placed in that dir instead.

Comment by Thomas Lowry [ 2016/01/05 ]

I have confirmed this to be an issue for me as well. Version 3.8.4-1 here.

Comment by W Sanders [ 2016/01/19 ]

Also in 4.2.2 master/agent.

Comment by Jonathan Gazeley [ 2016/09/13 ]

I'm working on a manifest that manages the stock yum.repos.d definitions from CentOS and can override some settings. This is tested and working on CentOS 7 but produces different behaviour on CentOS 6. Both platforms are running Puppet 3.8.7

yumrepo { 'CentOS-Base':
  name       => 'base',
  target     => '/etc/yum.repos.d/CentOS-Base.repo',
  baseurl    => $baseurl,
  mirrorlist => $mirrorlist,
  descr      => 'CentOS-$releasever - Base',
  enabled    => $enabled,
  gpgcheck   => '1',
  gpgkey     => "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-${::repo_centos::releasever}",
}

On CentOS 7 this produces a file "CentOS-Base.repo". On CentOS 6 this produces a file "base.repo".

Comment by Chris Denneen [ 2017/02/07 ]

I know fixing the target to work properly is most important but I was wondering if you look at some of the repo files for like the CentOS legacy 7.x repos as new versions release. They combine a bunch in single repo files.
So target would have to be treated more like a "tag" of some sort and files based in that target used to generate based on iteration in a template (so repo file could be single or have 20 in one file)

Comment by Josef David S. Prado [ 2017/04/24 ]

Hi Guys, can anyone tell me is this works in any of the available puppet versions or if it a bug taht affects all of then?

I´m facing it and I would like to decide if I will upgrade to a newer version or just stop trying to use yumrepo.

Regards,

Josef

Comment by Michael Burk [ 2017/05/25 ]

Just verified that target is ignored in puppet-agent-1.10.0 on CentOS 7.

Comment by Fabrice Bacchella [ 2017/08/26 ]

If target don't work, please don't put it on the documentation.

Comment by Jacob Helwig [ 2018/03/01 ]

We should deprecate/remove the target param, and point people at https://forge.puppet.com/puppet/yum

Comment by Lucas Yamanishi [ 2018/03/01 ]

Jacob Helwig The voxpupuli-yum module makes extensive use of the core Yum resource type, and it could use the `target` attribute.  In fact, some of the module data sets it in hope that this ticket will some day get fixed. See reference below. If you are proposing to move the core type to Voxpupuli, that is another discussion entirely. But deprecating the attribute is not the answer, IMO.

Ref: https://github.com/voxpupuli/puppet-yum/blob/master/data/os/RedHat/CentOS.yaml

Comment by Jacob Helwig [ 2018/03/01 ]

When we were looking at things, it wasn't immediately apparent that the yum module was just a thin wrapper around the built-in types (https://github.com/voxpupuli/puppet-yum/blob/2ecfb6bf0f9ced94dbb911fcf4faa6e5fec982bc/manifests/init.pp#L17-L21). Since the module isn't doing its own thing to correctly handle yum repos, that doesn't really help much for this particular case.

Comment by Chris Denneen [ 2018/03/01 ]

Jacob Helwig yes it's just a wrapper around the yumrepo resource

https://github.com/voxpupuli/puppet-yum/blob/2ecfb6bf0f9ced94dbb911fcf4faa6e5fec982bc/manifests/init.pp#L130-L132

 

Comment by garrett honeycutt [ 2018/03/01 ]

If you are looking for a module that does not rely on the yumrepo type, I'm about to release a new version of my yum module that is feature complete against the yum.conf man pages.

https://github.com/ghoneycutt/puppet-module-yum/pull/24

Comment by Eric Delaney [ 2018/03/12 ]

We looked at trying to fix 'target' but its a bit of work and we don't have the run way to make it for 5.5.0. It also makes more sense to wait for the provider to be split out of puppet and then do this work. So I've created PUP-8242 to remove the documentation of 'target' for now and we'll revisit this later.

Comment by Josh Cooper [ 2018/07/06 ]

Future development on the yumrepo type and provider will be done in https://github.com/puppetlabs/puppetlabs-yumrepo_core, and we will package the most recent stable version of the module into puppet-agent 6.0 packages moving forward.

Comment by Robert August Vincent II [ 2019/07/22 ]

If someone could point me to the code that parses a yumrepo type, I'd be happy to work on a fix. But I don't see a yumrepo provider, only a yumrepo::inifile provider.

Josh Cooper? Could you provide some insight?

Comment by Jacob Helwig [ 2019/07/22 ]

That's the correct provider. https://github.com/puppetlabs/puppetlabs-yumrepo_core/blob/8938357/lib/puppet/provider/yumrepo/inifile.rb#L134-L143 is specifically where it's doing the parsing of the .repo files. It uses Puppet::Util::IniConfig under the hood to do the actual parsing of the INI style files.

Comment by Robert August Vincent II [ 2019/07/22 ]

Jacob Helwig – I have read the code, and understand that the yumrepo::inifile provider is used to parse pre-existing .repo files. But where is the code that reads the explicitly-provided parameters of a yumrepo resource?

yumrepo { 'my_repo':
  baseurl => 'https://my/repo/url',
  descr   => 'My Repo Description',
  target  => '/etc/yum.repos.d/myrepo.repo',
}

Comment by Jacob Helwig [ 2019/07/22 ]

Ah, I misunderstood the question as where the file parsing was going on, not how the type & provider system itself worked. Parameters are defined as part of the type, so that's in Puppet::Type::Yumrepo.

Comment by Robert August Vincent II [ 2019/07/22 ]

What connects Puppet::Type::Yumrepo to Puppet::Provider::Yumrepo::Inifile?

I don't understand the implicit mechanism.

Perhaps to fix this bug, there needs to be an explicit Puppet::Provider::Yumrepo implementation?

Comment by Jacob Helwig [ 2019/07/22 ]

All types have a set of providers. In this case, there is only one. Puppet::Provider::Yumrepo::Inifile is explicitly declared as a provider for the Puppet::Type::Yumrepo type when it is created (https://github.com/puppetlabs/puppetlabs-yumrepo_core/blob/8938357/lib/puppet/provider/yumrepo/inifile.rb#L3). There is a bunch of machinery for determining which provider to use when applying a catalog (which one is suitable) if there are multiple providers, but that doesn't really come into play in this case, since there is only one provider, and it doesn't declare any restrictions on its suitability. Having an explicit Puppet::Provider::Yumrepo wouldn't affect this bug.

Comment by Robert August Vincent II [ 2019/07/22 ]

Okay; I think I see. A fix would need to modify (at least) the self.instances and self.prefetch functions.

Generated at Wed Nov 20 21:38:05 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.