Skip to content
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

Multi platform #5

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Multi platform #5

wants to merge 1 commit into from

Conversation

gilles
Copy link

@gilles gilles commented Mar 28, 2012

Hi,

I have updated the cookbook to be multi platform, I also updated the monitrc files to look like the packaged one.

I've also made a comment in the definition to namespace the source file path. The version I use here is of the form "monit/#{name}.conf.erb".

Thanks for considering

--Gilles

monitrc is also updated to look like the packaged one
@apsoto
Copy link
Owner

apsoto commented May 17, 2012

hey there, sorry for the delay, currently working on merging things (unfortunately it's not going in clean)

I have a question, can you explain what you mean by the comment in libraries/monitrc.rb:

#this should be "monit/#{name}.conf.erb" or "#{name}.monit.conf.erb" to not conflict with other conf files

I'm unclear on the "monit/#{name}.conf.erb" part. Does that mean it would look for the template inside the monit cookbook templates dir with a name of "#{name}.conf.erb"?

@gilles
Copy link
Author

gilles commented May 17, 2012

Hi,

I mean that monit configuration files for services should be in the local cookbook but in a 'monit/' subdirectory, in 'templates/default/monit/' to be precise.

For example on debian memcache uses a memcache.conf. Meaning the template is 'templates/default/memcache.conf.erb.'

If I want to create a monit check I have to name it 'templates/default/memcache.monit.conf.erb' and the target file name will be memcache.monit.conf

I think having the monit template as 'templates/default/monit/memcache.conf.erb' is cleaner.

I do the same for ganglia, all my ganglia plugins are in templates/default/ganglia, same for nagios nrpe, etc. I find my cookbooks more maintainable in the long run.

Thanks

@apsoto
Copy link
Owner

apsoto commented May 17, 2012

As I'm merging I'm noticing that things are not going to stay backwards compatible anyway since I also merged in a patch that moves the LWRP from a library to a definition.

Therefore, I'll try to adopt the subdir convention as the next release will break backwards compatibility anyway.

@freerobby
Copy link
Collaborator

@apsoto Do we want to start a new branch for the next release that will not provide backwards compatibility? I'm not sure what to do with PRs like this at this point.

@apsoto
Copy link
Owner

apsoto commented Oct 5, 2012

good idea, go for it.

If you can release a version that's still backwards compatible, I say release it as 1.0, then next one can be 2.0.

If you have time, create 1.X and 2.X series branches.

Thanks

@ryansch
Copy link
Contributor

ryansch commented Jan 25, 2013

👍

I just started implementing this myself only to discover this pull request. This cookbook doesn't work correctly on redhat family distros when running on master.

@apsoto
Copy link
Owner

apsoto commented Jan 29, 2013

I'm strapped for time, if anyone wants to step up and handle this I can add as a collaborator.

@yourabi yourabi force-pushed the master branch 4 times, most recently from dadcde5 to fa5f017 Compare September 8, 2014 15:39
@yourabi
Copy link
Collaborator

yourabi commented Sep 10, 2014

I think this would be a good addition.

@gilles - if you're still interested can you rebase this against the recent changes and I'll help merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants