-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Create solution for making logs available when running Tasks #143
Labels
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
Milestone
Comments
I think you might be working on this @tejal29 , should I assign it to you? |
This was referenced Oct 12, 2018
Closed
bobcatfish
added
the
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
label
Oct 12, 2018
yes thanks! |
knative-prow-robot
pushed a commit
that referenced
this issue
Oct 24, 2018
What is the problem being solved? This PR addresses issue #143. This issue is that it when Build's complete, logs from the steps the Build ran are garbage collected by kubernetes and no longer available to the user. Why is this the best approach? 1) No special kubernetes configuration (eg. changing garbage collector values) What other approaches did you consider? 1) Changing kubernetes garbage collection for these containers so that they are not immediately deleted and log capture was possible What side effects will this approach have? 1) With this approach, users will have to specify the "Command" value for the containers they which to run as the Entrypoint is not retrievable. This means that containers/flows setup to use only the Entrypoint will no longer be supported. What future work remains to be done? 1) It is possible to have the PVCs changed to EmptyDir volumes once a log uploader is created. This will help with the issue that currently PVCs are being created and not cleaned up. Co-authored-by: Christie Wilson <[email protected]>
bobcatfish
added a commit
to bobcatfish/pipeline
that referenced
this issue
Oct 24, 2018
The Builder image contract is actually the opposite of what we now support - it specifies that users should define an `entrypoint` and rely on that, however the new behaviour in tektoncd#167 will completely ignore this `entrypoint`. These docs are a copy of the Builder image docs at https://github.com/knative/docs/blob/master/build/builder-contract.md but modified to describe the contract required by Task. This is for tektoncd#143
knative-prow-robot
pushed a commit
that referenced
this issue
Oct 24, 2018
The Builder image contract is actually the opposite of what we now support - it specifies that users should define an `entrypoint` and rely on that, however the new behaviour in #167 will completely ignore this `entrypoint`. These docs are a copy of the Builder image docs at https://github.com/knative/docs/blob/master/build/builder-contract.md but modified to describe the contract required by Task. This is for #143
Fixed in #167 |
vdemeester
referenced
this issue
in openshift/tektoncd-pipeline
Apr 5, 2019
What is the problem being solved? This PR addresses issue #143. This issue is that it when Build's complete, logs from the steps the Build ran are garbage collected by kubernetes and no longer available to the user. Why is this the best approach? 1) No special kubernetes configuration (eg. changing garbage collector values) What other approaches did you consider? 1) Changing kubernetes garbage collection for these containers so that they are not immediately deleted and log capture was possible What side effects will this approach have? 1) With this approach, users will have to specify the "Command" value for the containers they which to run as the Entrypoint is not retrievable. This means that containers/flows setup to use only the Entrypoint will no longer be supported. What future work remains to be done? 1) It is possible to have the PVCs changed to EmptyDir volumes once a log uploader is created. This will help with the issue that currently PVCs are being created and not cleaned up. Co-authored-by: Christie Wilson <[email protected]>
vdemeester
referenced
this issue
in openshift/tektoncd-pipeline
Apr 5, 2019
The Builder image contract is actually the opposite of what we now support - it specifies that users should define an `entrypoint` and rely on that, however the new behaviour in #167 will completely ignore this `entrypoint`. These docs are a copy of the Builder image docs at https://github.com/knative/docs/blob/master/build/builder-contract.md but modified to describe the contract required by Task. This is for #143
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
Expected Behavior
After running a Task, it should be simple to get the logs that it has produced.
Actual Behavior
You can try to get the logs from the init container, however if the pod has been deleted, the logs are deleted with it. Sometimes you can get these logs but most of the time the pod is deleted and the init container logs vanish with it, though the other container logs are kept by k8s.
Steps to Reproduce the Problem
docker://somethingsomething
Additional Info
The text was updated successfully, but these errors were encountered: