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

Create solution for making logs available when running Tasks #143

Closed
bobcatfish opened this issue Oct 12, 2018 · 3 comments
Closed

Create solution for making logs available when running Tasks #143

bobcatfish opened this issue Oct 12, 2018 · 3 comments
Labels
meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given

Comments

@bobcatfish
Copy link
Collaborator

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

  1. Run a Task (todo: Create step by step walkthrough tutorial #22 we need a simple walkthrough to link here!!)
  2. Try to view the logs by getting them from the init container (see steps 5+ here)
  3. You may see the logs or you may see an error about not being able to find docker://somethingsomething

Additional Info

@bobcatfish
Copy link
Collaborator Author

I think you might be working on this @tejal29 , should I assign it to you?

@bobcatfish 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
@bobcatfish bobcatfish added this to the Mid October Demo milestone Oct 15, 2018
@tejal29
Copy link
Contributor

tejal29 commented Oct 15, 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 <christiewilson@google.com>
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
@bobcatfish
Copy link
Collaborator Author

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 <christiewilson@google.com>
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
Projects
None yet
Development

No branches or pull requests

3 participants