search

TheRacetrack / racetrack

An opinionated framework for deploying, managing, and serving application workloads
https://theracetrack.github.io/racetrack/
Apache License 2.0
28 stars 5 forks source link

Support deployment warnings #473

Closed iszulcdeepsense closed 1 week ago

iszulcdeepsense commented 3 weeks ago

Sometimes it would be useful to show the client a warning that has been produced during building/deploying a job. Like this one https://github.com/TheRacetrack/racetrack/issues/452. It could be shown in the racetrack CLI logs, when calling racetrack deploy ...

anders314159 commented 2 weeks ago

Is the idea that warnings originating from components, e.g. image-builder, are passed back to the CLI, and then printed there/logged there?

Is the easiest way to send warnings back and forth with the already existing get/post/delete Requests or something like that? I speculate that the loggers are fairly independent, and live in their own separate components/containers, so it might be difficult for the image-builder logger to send something to the CLI logger.

iszulcdeepsense commented 2 weeks ago

Is the idea that warnings originating from components, e.g. image-builder, are passed back to the CLI, and then printed there/logged there?

Is the easiest way to send warnings back and forth with the already existing get/post/delete Requests or something like that?

Yes, warnings may be produced by image-builder. Recently, image-builder got implemented server-sent events. I was thinking maybe it could be made use of to stream warnings like this.

anders314159 commented 2 weeks ago

Is there a central place we store logs/warnings/events? I don't want the CLI to connect directly to e.g. image-builder, so it should go through lifecycle. It might be overkill to implement a whole message queue/logging service/thing.

My plan is to store the build logs in the DB, and the CLI then asks lifecycle for updates, which is the same way as deployment updates are handled now.

Also, are build logs sensitive? Do we need to filter them before passing them back to the CLI?

iszulcdeepsense commented 2 weeks ago

Is there a central place we store logs/warnings/events? I don't want the CLI to connect directly to e.g. image-builder, so it should go through lifecycle. It might be overkill to implement a whole message queue/logging service/thing.

My plan is to store the build logs in the DB, and the CLI then asks lifecycle for updates, which is the same way as deployment updates are handled now.

Build logs and build phase are kept in the database as part of the Deployment model, you can put a new field here: https://github.com/TheRacetrack/racetrack/blob/master/lifecycle/lifecycle/django/registry/models.py#L81C5-L82C15

Also, are build logs sensitive? Do we need to filter them before passing them back to the CLI?

Do we really need to show them build logs? I supposed we just need to show the warnings that will be generated by Racetrack in a predictable manner.

anders314159 commented 1 week ago

Should https://github.com/TheRacetrack/racetrack/issues/452 be set as True by default now that it is a warning instead of an error?

iszulcdeepsense commented 1 week ago

Should #452 be set as True by default now that it is a warning instead of an error?

Yes. I feel like it may be the annoying error, but the users want the warning. So let's start with the warning, and let's check if that's really effective. If not, we can make it an error again.