Version 1.3.0 of stahnma/epel creates a dependency cycle when Yumrepo resources are declared in different run stages

[Sharpie]

The changes in #68 added an unfiltered resource collector that makes all Yumrepo instances depend on the EPEL GPG key:

Epel::Rpm_gpg_key <| |> -> Yumrepo <| |>

This will result in a dependency cycle if any Yumrepo resource is declared in a run stage that occurs before the stage containing Class[Epel] and also creates an unnecessary dependency for any repo that doesn't use the EPEL GPG key.

Puppet Enterprise compile masters use such a stage to ensure the PE repositories are configured before Stage[main] kicks off. Adding the Epel from 1.3.0 to a PE compiler results in a dependency cycle:

[root@pe-201732-agent ~]# puppet agent -t --graph


Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for pe-201732-agent.puppetdebug.vlan
Info: Applying configuration version '1515018145'
Error: Found 1 dependency cycle:
(Exec[import-EPEL-7] => Epel::Rpm_gpg_key[EPEL-7] => Yumrepo[pe_repo] => Class[Puppet_enterprise::Repo::Config] => Stage[pe_setup] => Stage[main] => Class[Epel] => File[/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7] => Exec[import-EPEL-7])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
Error: Failed to apply catalog: One or more resource dependency cycles detected in graph

[rnelson0]

If the collector is changed to Epel::Rpm_gpg_key <| |> -> Yumrepo <| tag == 'epel' |>, that should suffice, right?

[Sharpie]

Seems like the intent of #68 may have been to disable management of repos in the EPEL module which allows them to be managed by other modules --- but still keep the GPG key working in the right order via the collector.

Using a tag of epel would work, but would require a tag to get attached to the external resources that need it. Another option would be to require an array of resource titles to be explicitly passed in order to set up the dependency.

Or just punt it entirely. If someone wants to disable management of repos in the epel class because it's managed elsewhere, then they should sort the resulting dependency out in a profile class using a method that is appropriate for their situation.

[rnelson0]

I suggested the tag because of automatic tagging. Maybe it should really be Epel::Rpm_gpg_key <| tag == 'epel' |> -> Yumrepo <| tag == 'epel' |> to limit it to just this module.

[Sharpie]

Aye, but in that case why have a collector at all? Why not just use explicit dependencies on the EPEL yumrepo resources and avoid the knock-on effects of collectors?

Seems like #68 added this specifically to make the module interact with external yumrepo resources.

[rnelson0]

I think that's another way to do the dependencies explicitly without being explicit in labeling each resource. But in this case, it does seem like removing it entirely is appropriate.

[jyore]

what was the resolution here? it is breaking my setup pretty hard.

[stahnma]

Just released 1.3.1 that I think should fix this.