Bug fix for declaring multiple selinux::module types #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello Mr. Fryman
I recently began using trying out this module, and ran into a peculiar issue. When I try to have two selinux::module declarations get applied to the same host (which should be possible, seeing as how it's a defined type), I get catalog cycle dependency errors. Having multiple selinux::module types defined in such a way that one is dependent on the other (such as having them in separate profile manifests where other contents of the profile require ordering at the role manifest level) appears to be the trigger for the issue. Having read the type definition and thinking about it a bit, I believe the root issue is the way you used tags in the file declarations. While it's a neat trick to work around not knowing if you'll have a .mod file declaration ahead of time, you don't have anything unique in the tag names. As such, when you use the collector to chain resources, the tag search doesn't distinguish between file declarations from this instance of the defined type and other instances of it in the catalog. My proposed workaround is to replace 'selinux-module-build' and 'selinux-module' with 'selinux-module-build-${name}' and 'selinux-module-${name}', respectively. I've tested this method out, and it appears to resolve the issue, without changing anything external or breaking anything (meaning this can be a simple bugfix version release semantically). I'm open to suggestions about how else to handle this, if there's a more preferable way.