Major updates (read description) #17
Conversation
treydock
commented
Apr 6, 2021
treydock
commented
- Drop Puppet 5 support
- Add Puppet 7 support
- Drop Debian 8 support
- Support perfSONAR 4.3.x
treydock
force-pushed
the
updates
branch
2 times, most recently
from
9ea5b94 to
c94063d
Compare
| if $::perfsonar::manage_epel { | ||
| include ::epel | ||
| if $perfsonar::manage_epel { | ||
| contain 'epel' |
There was a problem hiding this comment.
I think that would work the same as containing the resource since main class handles the ordering. Only reason I would not do require is technically the repo class doesn't require epel, it's actually the install class that requires epel but that is handled via containment ordering.
There was a problem hiding this comment.
contain will force that the epel class will not be applied until after the perforsonar class has started to be applied. This means if perfsonar is ordered in the catalog on a resource that itself has a dependency on epel, there will be a circular dependency. See https://github.com/puppetlabs/puppet/blob/main/lib/puppet/functions/contain.rb
There was a problem hiding this comment.
The containment is in perfsonar::repo so that does not create any issues for main perfsonar class. The acceptance tests do not run into any circular dependencies, so not sure what the issue might be other than maybe inaccurate description in comments for containment? If you look at the output from acceptance tests the EPEL class gets applied when the perfsonar yumrepo is added but before the installation of any of the perfsonar packages. The EPEL class application and yumrepo from this module are sort of intertwined together and then the actual package install happens.
There was a problem hiding this comment.
I think where a circular dependency could happen is if you said Class[epel] -> Class[perfsonar] which would be unnecessary given ordering in this module.
* Drop Puppet 5 support * Add Puppet 7 support * Drop Debian 8 support * Support perfSONAR 4.3.x
