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

Can yodeploy handle logrotate config for an app? #154

Open
stormf opened this issue Jul 27, 2015 · 6 comments
Open

Can yodeploy handle logrotate config for an app? #154

stormf opened this issue Jul 27, 2015 · 6 comments

Comments

@stormf
Copy link
Contributor

stormf commented Jul 27, 2015

So we can stop doing chef pulls like this because when we changed the path a year ago we forgot to update logrotate.

Another when we fixed forgetting to add log files.

@bearnard
Copy link
Contributor

👍 , definitely sounds like a better way.

@adrianmoisey
Copy link
Contributor

Agreed. And we can move logs to /var/log/yola at the same time :)

@stefanor
Copy link
Contributor

Logrotate has a .d, this sounds trivial.

@adrianmoisey
Copy link
Contributor

If we were logging to /var/log/yola/, what about we just create 1 logrotate file that rotates /var/log/yola/*.log.
We could create a yola_base::logrotate recipe that creates /var/log/yola/ and the logrotate config on all machines.

@stormf
Copy link
Contributor Author

stormf commented Jul 29, 2015

We could create a yola_base::logrotate recipe that creates /var/log/yola/ and the logrotate config on all machines.

That's a cool idea, and it would be a good reason to move more app logs to /var/log/yola, but I still think yodeploy would benefit from this functionality. It would let us handle non-yola apps that we have deploy wrappers around such as graphite (which doesn't make sense logging to /var/log/yola).

@stefanor
Copy link
Contributor

Both are good points. Pragmatically, the wildcard is an obvious short-term winner.

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

No branches or pull requests

4 participants