-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Bug 1247735 - prehook (and posthook?) deployment pods are deleted after exit which makes logs unavailable to users (edit) #3952
Comments
Some clarification:
|
There is an issue with #1 in that I may be trying to "develop" a hook. If the hook completes without error but did not do what I thought it should have done, I have no way to troubleshoot that. I could, in those situations, always cause my hook to fail by throwing a nonzero exit code but then the deployment can not ever continue which may be a part of my hook development. If the centralized logging story doesn't include hooks in some way, I think that we really need to allow successful hook pods to be kept via configuration. |
This is reasonable, but it also applies to the primary deployer pod, not just hooks. Short of centralized logging, the only other way I'm seeing around all this would be cleanup policies for deployer pods. When discussing the upstream deployment proposal (kubernetes/kubernetes#12236) I mentioned the idea of generalizing the rolling updater cleanup policy onto the high level strategy resource itself, which people seemed somewhat agreeable to. /cc @smarterclayton |
@thoraxe please close this in favor of https://trello.com/c/5Pt8kGwT. |
WORKSFORME |
Also centralized logging is coming, and it'll be more important to make On Thu, Aug 20, 2015 at 10:48 AM, Erik M Jacobs [email protected]
Clayton Coleman | Lead Engineer, OpenShift |
Currently, after a prehook or posthook pod completes, it is deleted. This means that a normal OpenShift user cannot view the logs because they would need system-level access to directly view the Docker logs.
This behavior wasn't present in beta4.
Some thoughts for solutions:
This is related to #3544 in some ways.
The text was updated successfully, but these errors were encountered: