Move pid file to /var/run

[linc01n]

We should move the /opt/atlassian/stash/work/catalina.pid to /var/run

It is because we are symlinking /opt/atlassian/stash to the latest version of stash. Every time we run the chef script to upgrade stash, it will change the symlink target and failed the stash restart since the service can't find the pid.

So the situation is like this:

/opt/atlassian/stash -> /opt/atlassian/stash-3.9.0 the catalina.pid is located in /opt/atlassian/stash-3.9.0

We run the cookbooks to update stash, now it points to /opt/atlassian/stash -> /opt/atlassian/stash-3.10.0 the catalina.pid is still located in /opt/atlassian/stash-3.9.0

At the end of cookbook, we restart the stash service. But it fails because it can't find /opt/atlassian/stash-3.10.0/work/catalina.pid

reference: http://stackoverflow.com/questions/5173636/must-my-pidfile-be-located-in-var-run

[legal90]

:+1:

[bflad]

:+1:

On Mon, Jun 29, 2015, 6:09 AM Mikhail Zholobov notifications@github.com wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/bflad/chef-stash/issues/100#issuecomment-116592358.

[l4u]

:+1:

[patcon]

I think this can be closed now?

[linc01n]

I didn't merge to master. So I leave this open until 4.0 released.

[patcon]

Ah ok, gotcha :) I don't normally see cookbooks using release branches, and hadn't realized.

[linc01n]

4.0 will contain breaking changes so we put it into a separate branch now. Mainly this one

4.0.0 (When Released) Enhancement: #49: Update default database to postgresql

I am not sure how not to break other people deployment with the new cookbook.

[patcon]

One possibility might be to have complex logic in the cookbook until a major release (to support all use-cases), but then make it known (via chef run warnings, etc) that the attributes or approaches will be deprecated in X number of months (or whatever seems fair)?

EDIT: Or of course, people could always stick with the old cookbook -- maybe we shouldn't wait up on them anyhow. I guess how far we bend over to support those specific users (who want to latest, but don't have time to upgrade their whole infra) depends on how many people are using the cookbook...?

[linc01n]

Maybe we check if the user installed mysql then use the mysql path?

[patcon]

Hm. You mean check the run list?

I think the way I've seen is to do some sort of responds_to? on a resource attr, or a resource itself, to check on a feature that would only exist in cookbook version X but not in cookbook version Y. (I don't think we can add conditional logic based on "what version of mysql cookbook is being used"... although I may be wrong)

[patcon]

Example: http://jtimberman.housepub.org/blog/2015/03/20/chef-gem-compile-time-compatibility/

[linc01n]

Merged!