When start fails, only stop and delete options available

[jsliacan]

Daemon is running, and pull secret is not set. Then I clicked Start in the tray. Start failed, but the tray only offered Stop and Delete options (both of which do nothing, since CRC is not up). Also, tray doesn't offer Start even after I press Stop or Delete.

I would expect that it would offer Start as well, because the user can run crc config set pull-secret-file <location> and continue.

Just attaching this remark here too: I couldn't find an instruction telling me how to pass the pull secret file to the tray. Maybe outline this in the README?

Thanks!

[anjannath]

@jsliacan @praveenkumar Here's all the scenarios and what the menu states should be, please edit/add to it:

1. When start fails -> Start, Stop, Delete all menus should be enabled (no VM exists but user clicked on start)
2. When start succeeds -> Start menu disabled, stop and delete should be enabled (VM exists)
3. When VM does not exists -> Only start should be enabled.

Just attaching this remark here too: I couldn't find an instruction telling me how to pass the pull secret file to the tray. Maybe outline this in the README?

there's is no way to set the pull secret from the tray yet, this would be part of #1 but we can mention the requirement crc config set pull-secret to the readme.

[jsliacan]

@anjannath Cool, I'm not sure about your 1. I'd assume if Start fails, Stop and Delete would be disabled. Othewise the user might be confused about the Schrodinger's VM: both stopped and not (since you "can" Stop it but also "Start" it from the current state) :)

I'd add:

4. When VM exists but is stopped -> Start and Delete enabled; Stop disabled;

I'll write again if I recall something else.

we can mention the requirement crc config set pull-secret to the readme.

Upvote from me!

[anjannath]

@jsliacan With the latest release this should be fixed now, please give it another try, latest binary can be grabbed from the release page: https://github.com/code-ready/tray-macos/releases/download/v1.0.0-alpha.2/crc-tray-macos.tar.gz

[anjannath]

I hit this issue again, need to look again.. :(

[gbraad]

Schrodinger's VM

LOL. What would you suggest it to be?

When "failed" only "delete" should be shown?

[jsliacan]

@gbraad based on this from Anjan's point 1:

(no VM exists but user clicked on start)

I'd say that only start should be shown. If no VM exists, then the user cannot stop the VM and they cannot delete the VM either.

On the other hand, if failed start meant that the VM is not started but might exist, then delete should also be enabled.

[gbraad]

In case of a failure, Start is not the right option. A restart from failure means needs a Delete to happen. So, only the Delete option with a clear failure statement.

[jsliacan]

Sure, if some sort of clean-up is needed after a failed start, then probably delete is the only option - as you say.

[gbraad]

In that case, I think we need to record if the Start was successful or not, as detecting a failure state is needed. Not sure if we can 'detect' it without recording the failed start. this is because we do not want to add 'tray-specific logic' for something that should also reflect in generic use:

you shouldn't be able issue a new start on the command line etiher if a failure happened.

@code-ready/crc-devel WDYT?

[cfergeau]

1. If start succeeded, we allow to run start again and just indicade that crc is already running.
2. If start failed and the VM is not running, then re-running start is most likely the best way forward
3. If start failed and the VM is running, maybe we have a degraded cluster we can interact with, maybe the cluster is not working at all. In both cases, it would be nice if crc stop was enough before trying crc start again. Getting that right probably goes with refactoring machine.Start()

Regarding storing some state about crc, I suspect we'll need to do it sooner or later (for example to record what we changed during preflight/what we did not change)

[gbraad]

If start failed and the VM is not running, then re-running start is most likely the best way forward

This is not a given. It depends on the failure. When the VM is created, but not started, this might fail again. An example is the situation is memory assignment. When memory is not available, the start would fail. A VM would exist, but the start is not possible... unless adjusted. Which at the moment means: delete as a change/modify is not possible.