MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description The following discussion from !163093 should be addressed: - [ ] @mvanremmerden started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163093#note_2080648293): (+9 comments) > @vtak @cwoolley-gitlab One of the changes in this MR is that I tried to ensure that there is always only one state visible for the user and that we don't have two states visible at the same time (e.g. "Running" in the badge left and "Stopping" in the button tooltip on the right side). > > Over the last days @ealcantara had a look at the code for `actualState` and `desiredState` and tried to figure out how in this new design each combination should be represented, and what actions should be available. We created a new storybook page so that all combinations can quickly be seen: > > {width=1213 height=907} > > A few questions now for both of you: > > * Are there any constraints in the backend for what combinations should not be possible between `actualState` and `desiredState`? > * Should all `actualState: error` combinations have "Error" as state indicator in the badge? > * Should there be any actions (Start, Stop, Restart, Terminate) visible in the dropdown on the right side for `actualState: error` and\` actualState: unknown\`? ## Acceptance Criteria TODO: Fill out (required) - [ ] [Describe what must be achieved to complete this issue.] - [ ] [Describe another requirement needed to complete this issue.] - [ ] [Add additional acceptance criteria as needed.] ## Technical Requirements TODO: Fill out or delete (optional) [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete (optional) [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete (optional) [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete (optional) [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->