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

Capture container upgrade logs #22

Open
kdebisschop opened this issue Feb 10, 2020 · 4 comments
Open

Capture container upgrade logs #22

kdebisschop opened this issue Feb 10, 2020 · 4 comments

Comments

@kdebisschop
Copy link
Owner

Is your feature request related to a problem? Please describe.

Capture logs output from a container when upgrading it ? Currently, I have to found the container, the host and make a docker logs against it and I was wondering if there would be a way to get this through the api ?

@mashwino
Copy link

Hi,
logs are also available thrue websocket websocket, could be a way ..

@kdebisschop
Copy link
Owner Author

I use websocket to capture command output. I'm not sure if there will be any differences in an upgrade. I won't have time to try for several days.

@kdebisschop
Copy link
Owner Author

This will be harder than you might expect. Remember that "upgrade" is an action on a service. You are asking for container logs. So logging an upgrade would require these steps:

  1. Identify all of the containers in the service
  2. Attach loggers to each of them via web sockets and show their console - both as they shut down and as connected containers cause changes to the system during upgrade (imagine the upgrade causes a schema change in a backing database - we'd want to capture any resulting errors in the still-running old containers).
  3. Identify new containers as they appear in the service. (I am not sure there is a way to do this except periodically polling the service.)
  4. Attach a web socket logger to each of these containers and capture their console output.
  5. Somehow render this in an organized way (remembering that the upgraded containers are not the nodes we acted on - they are new. So we cannot use RunDeck's ability to track nodes)

All of this would need to work both when start-before-stop is enabled and when it is not.

I am not even sure this is feasible at all. If it is feasible, it would be a large undertaking.

@kdebisschop
Copy link
Owner Author

kdebisschop commented Mar 15, 2020

A smaller possible approach might be to show recent messages logged to console on each container in the service at the end of the upgrade step. I expect the rancher API provides a means to do that, but I'm not sure...

yes...

https://rancher.com/docs/rancher/v1.6/en/api/v2-beta/api-resources/container/#logs

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

No branches or pull requests

2 participants