-
Notifications
You must be signed in to change notification settings - Fork 6
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
employ docker-compose v3.4 and shared logging config #152
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll wait for the tests to pass then it should be all good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions. Not approving immediately because I'd like to try it on my dev server to see the difference with the new logging config but looks good overral, except the .gitignore
part that I find unusual.
&default-logging | ||
driver: "json-file" | ||
options: | ||
max-size: "200k" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we have not set any of those config currently (driver, max-size, max-file). What's was their default?
It's very nice to have a unified logging config for all containers but can each container, if needed, not use this config and roll their own?
And to loop back to the original Weaver PR, Weaver need to "hook" into other components logs and that's why it prefers other components to have unified logging config or is there another reason to introduce this unified logging?
Just to be clear, I like it to have a default and unified logging config, I just want to understand its relation to Weaver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docker's default is json so that remains the same.
The difference here is that we add log rotation over 10 files.
This is a config we have found a long time ago when deploying on our instances since twitcher and magpie can generate an immense quantity of logs (on each request). This allows discarding them gradually instead of accumulating GB of useless logs.
Each container can define its own logging section by using the relevant config instead of the default-logging
reference.
I don't think there is a nice way to automate that though. Best could be to have an optional-component, but I think it is better to control the logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Weaver, it is a bit more tricky since a different docker-compose file is employed.
Depending on how docker-compose merges the files, the reference could or won't work across files.
Basically, if files are merged, and then references resolved, it would work. But if internally it uses PyYAML or similar lib, to read each file individually and merge them, Weaver's compose will raise a missing reference. So the config would need to be duplicated in its own file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I understand correctly, Weaver did not need this central logging and the log rotation to avoid accumulating infinite logs (which is indeed a nice thing).
From our recent "contributing guideline", this PR should not have been mixed with the Weaver PR to begin with. Or if mixed in, it should have been "well explained" that it is not required by Weaver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is why it has been split by itself now that we updated the contribution guideline.
Please consider that Weaver PR was started in January and review only started in March, both long before we even started discussions of contribution guidelines.
@@ -213,9 +233,8 @@ services: | |||
- "48983:9001" | |||
volumes: | |||
- /data/solr:/data | |||
volumes_from: | |||
- mongodb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I understood from our meeting, the removal of volumes_from
directive was because of the update to format version 3.4
, not because we want it or Weaver needs it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. volumes_from
is deprecated for >=3
There are a lot of improvements in docker-compose since v2, so better bump it while problems are still few.
This needs to be tested, but if I understand the compose correctly, that volumes_from
directive specifically is useless, since mongodb
doesn't even have a volumes
section. Starting with Weaver though, I require a data persistence volume in mongo, so I would like to have this adjusted with docker-compose v3 before it other images are not using it anyway (and don't start breaking obviously).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this looks harmless but should be tested to be sure. Has you or Mat gone over the failed build to determine the error is not related to this? Currently only the ESGF notebook should be intermittently failing because their server seems flaky but everything else should be green.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please confirm failing tests are okay.
Please let me do this merge since I need to since this merge with my other PR bird-house/birdhouse-deploy-ouranos#10 else our prod won't even start.
@nikola-rados I am pretty sure you will also need to do something like my PR bird-house/birdhouse-deploy-ouranos#10 above on your side. I can also sync with you for this merge. Let me know.
&default-logging | ||
driver: "json-file" | ||
options: | ||
max-size: "200k" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if I understand correctly, Weaver did not need this central logging and the log rotation to avoid accumulating infinite logs (which is indeed a nice thing).
From our recent "contributing guideline", this PR should not have been mixed with the Weaver PR to begin with. Or if mixed in, it should have been "well explained" that it is not required by Weaver?
@@ -213,9 +233,8 @@ services: | |||
- "48983:9001" | |||
volumes: | |||
- /data/solr:/data | |||
volumes_from: | |||
- mongodb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this looks harmless but should be tested to be sure. Has you or Mat gone over the failed build to determine the error is not related to this? Currently only the ESGF notebook should be intermittently failing because their server seems flaky but everything else should be green.
@tlvu I'm not too sure what was the problem on the last build, it was stopped for some reason. => http://daccs-jenkins.crim.ca/job/DACCS-iac/401
|
Just to confirm, it reran the whole thing, one time targeting master and the other docker-compose-update master docker-compose-update Results are the same in both cases, as presented below.
|
@nikola-rados I am pretty sure you will also need to do something like my PR for Ouranos custom config bird-house/birdhouse-deploy-ouranos#10 your side. Let me know once you are done so we can sync this merge. |
@tlvu I have updated our config. |
@nikola-rados Thanks so I'll merge this during the day tomorrow so you can go-live manually if required. |
update docker-compose file version to 3.4 To match bird-house/birdhouse-deploy#152, otherwise our deployment will not start.
Default logging retention should have been bumped to something more reasonable for prod. I forgot to push the bump here so bumping in PR #165 |
…on-to-something-more-reasonable-for-prod bump default log retention to 500m instead of 2m, more suitable for prod # Overview Bump default log retention to 500m instead of 2m, more suitable for prod Forgot to push during PR #152. ## Changes **Non-breaking changes** - Bump default log retention to 500m instead of 2m, more suitable for prod
export only the specific changes of docker-compose version and logging config from #114
Change overview:
volume_from: mongodb
fromsolr
andncwms2
container.Matching PR for Ouranos specific config bird-house/birdhouse-deploy-ouranos#10
Fixes #10