Rebased and resolved package conflicts

@amanji there's a pull request here that refactors some startup to a manage script. Any thoughts on if we merge that if that would cause any issues (or should have change to include) the docker compose startup instructions in this PR?

https://github.com/bcgov/traction/pull/1388/files

Let's give it a try. I doubt there will be a huge impact

@loneil we'd need to add this to the manage script:

Deployment URLs ready for review.

FYI trying on the deployed PR and hitting start on the logs doesn't seem to show output or an error

See an aggregateError in the tenant UI backend logs:

FYI trying on the deployed PR and hitting start on the logs doesn't seem to show output or an error

See an aggregateError in the tenant UI backend logs:

We need to build in three more services for the logging. I'm assuming the deployed services dont account for those yet

FYI trying on the deployed PR and hitting start on the logs doesn't seem to show output or an error
See an aggregateError in the tenant UI backend logs:

We need to build in three more services for the logging. I'm assuming the deployed services dont account for those yet

@i5okie do you have any suggestiono n how to set things up for the supporting services? i.e.: we list them as pre-requisites or do we include (optional) depenedncies in the Helm chart?

FYI trying on the deployed PR and hitting start on the logs doesn't seem to show output or an error
See an aggregateError in the tenant UI backend logs:

We need to build in three more services for the logging. I'm assuming the deployed services dont account for those yet

@i5okie do you have any suggestiono n how to set things up for the supporting services? i.e.: we list them as pre-requisites or do we include (optional) depenedncies in the Helm chart?

In my opinion, I think Traction should work without throwing exceptions or failing when it runs without Loki backend being configured. As such, I think Loki should be an optional component setup separately by the user. I'd imagine, if loki endpoint is not provided/log-streaming is disabled, the feature should be turned off in someway. Or at least say logs unavailable in a friendly (not app crashing) manner on the page.

As for the promtail, it should be included as an optional sidecar.
We could put together documentation, with example configs on how to set Traction up with Loki.
I can help with the latter two.

FYI trying on the deployed PR and hitting start on the logs doesn't seem to show output or an error
See an aggregateError in the tenant UI backend logs:

We need to build in three more services for the logging. I'm assuming the deployed services dont account for those yet

@i5okie do you have any suggestiono n how to set things up for the supporting services? i.e.: we list them as pre-requisites or do we include (optional) depenedncies in the Helm chart?

In my opinion, I think Traction should work without throwing exceptions or failing when it runs without Loki backend being configured. As such, I think Loki should be an optional component setup separately by the user. I'd imagine, if loki endpoint is not provided/log-streaming is disabled, the feature should be turned off in someway. Or at least say logs unavailable in a friendly (not app crashing) manner on the page.

As for the promtail, it should be included as an optional sidecar. We could put together documentation, with example configs on how to set Traction up with Loki. I can help with the latter two.

I'll update the PR to hide the log feature when the FRONTEND_LOG_STREAM_URL is not set.