-
Notifications
You must be signed in to change notification settings - Fork 565
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making the management of the daemon package optional #377
Conversation
I'm curious what about installing the I don't see anything terribly wrong with this approach, but I'd like to understand the problem a bit more before merging. |
Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests |
There's nothing horribly wrong with this approach, except that other Specifically we have another class that handles installing several packages Regards,
|
Perhaps a better route would be simply make a |
Would you like me to take that approach with this? I can adjust my PR to follow that logic. (Also, would it be all-or-nothing with the java install? or keep that unique?) |
@joshsouza I was more brainstorming, I'm not convinced that's the right way to go myself but I wanted to bring it up as a potential alternative to adding a single parameter for this one package |
@jhoblitt I wouldn't mind some opinions on this from you as well, if you've got the time. I'm thinking that needing to specify distinct packages that the module should manage is going to get crufty and confusing, especially for new users, whereas providing a "the module manages its dependencies" or "the module does not manage its dependencies" mode will be much easier to understand and document |
@rtyler It's not a perfect solution due to parse order dependence, but I have generally preferred to use ensure_packages() when there is no clear "ownership" of a package. In a general sense, I don't have an objection to params that disable functionality the user may want to control external to the module (eg, package installation, configuration, service management). I have been drifting towards not providing it by default as every param/branch incurs a small amount of additional test maintenance. Specific to this PR, I feel the naming is a bit confusing as I would naively expect |
@jhoblitt I think this is a good suggestion, I'll respin this PR as soon as I can. I'm also attending puppetconf and all the preparation is really killing the first part of the week for me :/ |
`jenkins::slave` uses the `daemon` package on debian. As this is a commonly needed package, directly declaring a package resource may lead to manifest conflicts. closes voxpupuli#377
@joshsouza #391 switches over to using |
That works great! Thank you! |
Your welcome! |
This tripped up my team. Perhaps a bit of an overkill fix, but at least it retains existing functionality. I'd love to hear of a different approach if you have something you'd suggest.