Extend UI App Status/Action Buttons

[maltegrosse]

Is it possible to provide a state diagram for the app action buttons?

I am having some difficulties to know when its started/stopped, deployed etc. (somehow the green/red/orange indicates it)

Perhaps first enable / disable the start and stop buttons depending on the pod state.

Finding the app event logs is not really intuitiv, perhaps its possible to make it more clear. Or to merge it with the deployment logs, so you have one overview what historically happened.

What is exactly the difference between Deploy (which is marked black, which somehow looks like an active state) and Rebuild?

Perhaps you can describe abit in k8s words, what exactly going on under the hood, or what was your intention to design it like this.

Thank you for your great efforts and great application!

P.S. perhaps some status indicators can be added to the

• app overview page
• monitoring reousrce usage page

Edit:
Perhaps it is possible to seperate it into container status:
"running", "stopped", "pending" (in addition, it should somehow show which deployment is currently running, like git commit)

and also deployment status:
"deployed", "deploy failed", "deployment in progress"

[biersoeckli]

@maltegrosse

The status is sometimes a bit "buggy" and doesn't update always in realtime. Currently there are three status:

• Gray: app is not running / shutdown
• Green: app is running
• Orange: app is currently being deployed or is shutting down.

This is a good point - enable/disable the buttons depending on the apps status.
So the

• stop button will only be shown when the status of the app is running.
• start button will be removed, because deploy and start do the same

The event logs weren't a planned feature initially. At the beginning of QuickStack it was like a "debug view" to see if the if the deployment succeded or not. An integration into the deployment logs would be ideal.

The difference between "Deploy" and "Rebuild" only applies if your app uses a Git repository as its source.
If the source is Git, the app is built on the QuickStack server, and the resulting images are stored in a registry running on the same server.

1. Clicking "Deploy" will check for an existing build
   a. If a latest build exists and now new changes were added to the repository since the last build, the stored image from the latest build will be deployed.
   b. If no build is found, a new build is triggered and then deployed.
2. Clicking "Rebuild" always triggers a fresh build from the Git repository, even if a latest build already exists.
   For apps using a Docker Image as the source, the "Rebuild" button is not needed and could be hidden.

The following image shows what happens when "Deploy" is clicked (german):

Status indicators for monitoring and in the project overview would also be nice.

Separation of the deployment status and the container status makes sense to me. These two status can also be shown on the app overview, project overview and monitoring page. By hovering over the container status, the current git commit hash and git commit message can be displayed.

The following changes will be made by this issue:

1. Status Indicator Improvements

• Ensure real-time updates for app status.
• Display three container status indicators:
  • Gray: App is not running/shutdown.
  • Green: App is running.
  • Orange: App is deploying/shutting down.
• Display a deployment status indicator:
  • Deployed:
  • Deployment in progress:
  • Deployment failed:

2. Button Visibility Adjustments

• Stop button: Only visible when the app is running or in a pending state.
• Start button: Removed, as "Deploy" and "Start" perform the same function.
• Rebuild button: Hide the rebuild button when a Container image ist the Source

3. Event Logs Integration

• Integration into deployment logs for better visibility.

4. Status Indicators in Multiple Views

• Display deployment status and container status separately.
• Show these statuses in:
  • App Page
  • Project overview
  • Monitoring page
• On hover, show the current Git commit hash and message.

[maltegrosse]

Thank you for your great explanation - now I understand better.

Now I just reconsider my intitial thoughts, as deployment/rebuild can be abit dangerous....

What do you think if u move all deployment related buttons down to the deployment logs.

Additionally, the App events: should it be at the current position of the Logs, and perhaps the Logs is in another tab, such that its not loaded everytime when you quickly browse your app....

Btw, are app events somewhere saved? somehow I can only see the one from few hours ago.