Implement CRC CLI update

[evidolob]

We need to implement update flow with podman-desktop API for update of installed binary

[gbraad]

We do not have a proper way to detect this as output from the command... perhaps extend crc version for this from the API?

[evidolob]

We do not have a proper way to detect this as output from the command... perhaps extend crc version for this from the API?

Technically it should be possible, need to look on it

[cfergeau]

Can/should crc be shipped together with the openshift local extension image? (just a question I had in the back of my mind for a while :)

[deboer-tim]

Yes, it's an option and we do it for most of the podman extensions. You'd still want to 'copy/install crc out' so that there's a proper copy on the system path in a normal location. This option is better for offline installs or someone who can't reach the download by the time you're trying, but bigger extension size especially if you do it for all OSes.

[gbraad]

The question is:

• would this be an installer of CRC with an extension
• or, an extension (installer) with CRC embedded

The first option to me sounds more reasonable... although; perhaps this should be the "OpenShift Toolbox"-installer as we have more interesting extensions that can be collected in a nice and convenient package ;-)

Note: we would also have the system bundles, which account for 1 to over 2+ GBs if we want to have a real offline installer

[deboer-tim]

Yeah, I agree a full offline installer is out of scope due to 2 GB size. :) Might not be a bad idea to include just the crc cli in the extension though to make sure it can always be installed?

[gbraad]

I think we should strive for a full offline installer, regardless of the size. but perhaps putting the CLI inside the extension would be possible as a first increment... just wonder if we should follow the same release cadence, and if this needs to be signed (if so, we have a dependency for release timing).

[gbraad]

Some additional comments after dropping this in the team sync:

Containers for extensions need to be platform specific if we want to include the crc binaries. This is currently not an issue for Kind as they are not an external extension, as it is the PD building/bundling process that handles this platform selection.

[gbraad]

Perhaps picking up the need to 'update', as given in the command output might be a good first step.

<span style="fa-exclamation">New version available<span>

[deboer-tim]

Current state for podman: after you update the extension it knows about the new version, and the only prompt is an option to update on the dashboard.

IMHO I'd just worry about detecting and supporting a similar flow with this issue, and we figure out separately the best way to handle this for multiple extensions and engines. It wouldn't be very usable if Podman, Kind, OpenShift Local and others all add a status bar item flagging updates, and possibly with different behaviours. To make sure we cover this I've opened two issues:

• https://github.com/containers/podman-desktop/issues/2184
• https://github.com/containers/podman-desktop/issues/2185

[gbraad]

right, there are two issues

• informing the user of a new version of the extension
• have the extension perform a dependency update

they are related, but very different issues. PD should not handle updates of kubernetes or OpenShift local by itself, as this is the responsibility of the extension as one of its dependencies. PD should in my opinion just show extension updates that are available and perhaps offer an onupdate event, or activate to be informed about an update flow? otherwise, extensions need to track their own versions that were used/installed and determine an update happened.

I still believe the extension should be informing the user somehow, and think it is up to to the extension what is the best way: this might be a dialog, a status bar notification, of other. for example, a security issue most likely should be 'forced' by a dialog informing the user more actively,while a minor upstate can be a notification or exclamation somewhere in the UI. perhaps thought from UI/UX? or just show a notification for the extension tab and the specific extension when they report an updateavailable or by version check.

Note that the installation and updates for different engines will still inherit different behaviour: from an msi that needs to run to just a replacement of a binary.

/cc: @mairin

[mairin]

@gbraad Some thoughts / ideas :) I have a quick & dirty mockup below.

I agree that a security issue could be handled differently than a minor update. Right now our task manager might be an ideal place, might need to rephrase it (as below) to be more generally a notification area... anyway this is how a minor update could be.

For a security update... I am not sure how forceful we can/should be? Will the user get an oppty to migrate stuff off? (I know we say don't put anything on OpenShift Local you care about but...) Could be something where there's a specific time period we give until it's forced (kind of like how some mobile OSes handle updates now?) We could warn them about the ticking clock via notifications. Maybe when the time's run out we shut down OpenShift Local and don't allow it to be used unless it's updated? (Not sure if this is too harsh?)

Any update should be queued up since it's a large download, can be thru the task manager like so:

[deboer-tim]

@gbraad agreed - the extension should remain solely responsible for both deciding that there is an update available and performing the update. My concern is if each extension decided on a different UI mechanism to notify users and update, and was suggesting we just keep that part simple until we've had a chance to talk/design.

https://github.com/containers/podman-desktop/issues/2019 will allow extensions to create tasks, and we might need a second issue for notifications, but then I think the pattern above could work well.