Workflow to restart microservices for a plugin

[markjmiller]

Closes #2650

Demo

cosmos_microservices_demo.mp4

Edit: start button shows when enabled is false, otherwise show restart

Design choices / Changes

• This keeps plugins and microservices cleanly separated and leaves the control of microservices in that tab (vs having a command in the plugin dropdown)
• Using query params is extendible to other systems that want to route to this tab
• Moved microservice state to a better location and formatted it more clearly
• Consolidated start/restart buttons based on enabled value

Could improve

• The confirmation dialogue doesn't like newlines so formatting all the services as a bullet list requires more work

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.25%. Comparing base (23c8263) to head (a1bc1e8).
⚠️ Report is 161 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2667      +/-   ##
==========================================
- Coverage   79.25%   79.25%   -0.01%     
==========================================
  Files         664      664              
  Lines       52882    52882              
  Branches      734      734              
==========================================
- Hits        41912    41909       -3     
- Misses      10890    10893       +3     
  Partials       80       80              

Flag	Coverage Δ
python	81.16% <ø> (-0.01%)	⬇️
ruby-api	84.76% <ø> (-0.06%)	⬇️
ruby-backend	82.16% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ryanmelt]

I like the implementation - Having a view microservices filter, and the control buttons is nice!

Only thing wrong is too much trust in the state values. The State Values require cooperatively written microservices, and they aren't really a fixed set of keywords. State can be anything you want in a microservice, and can be undefined for microservices that don't provide microservice status.

[ryanmelt]

Don't base the success of the button presses on State. You can leave the colored state label, that is nice, but success/failure should just be based on the Enabled flag changing.

[markjmiller]

Don't base the success of the button presses on State. You can leave the colored state label, that is nice, but success/failure should just be based on the Enabled flag changing.

@ryanmelt it turns out that restarting with the microservice /start api doesn't actually cause enabled to turn to false, so I'm not sure what else exists to track the state change back to running/ok. Note that start/stop will explicitly set enabled to true/false respectively, so those work.

Here's some ideas/options...

1. Have restart explicitly call /stop, wait, then /start
2. Update the api service to set enabled to false for a restart via /start -- or create a /restart endpoint
3. Just drop the UI loading state for restart (still can see the state change via badge)

Thoughts?

[ryanmelt]

Restarts just touch the object, and change the timestamp. You could have the restart as complete as soon as the timestamp changes.

[markjmiller]

I agree with this approach--we don't actually need to detect a full restart cycle. Just showing the loading indicator for one state change gives the user feedback their button click worked, and it's still valid for a user to trigger a restart immediately again if they wanted to.

[markjmiller]

Could be tweaked some more, but what do you think about making enabled more clear with a toggle icon?

It better highlights how restart and stop relates to state and enabled.

[ryanmelt]

I don't like the switches. If state is Running and enabled is false it's not running. That just means the last status received was running. Should probably not show the actual state if enabled is false, just show "stopped".

[markjmiller]

Is that an api issue that should be addressed? Why would state keep emitting as "running" if enabled=false?

[ryanmelt]

No. Internally there are two models. MicroserviceModel and MicroserviceStatusModel. The first is the control model which should always be correct. The latter is the most recent status reported by the microservice.

[markjmiller]

Sounds good. Ready for review @ryanmelt.