test(conformance): verify Snap installation status in Ubuntu VM

[elezar]

Summary

Add a VM-based Ubuntu Snap installation check to the conformance workflow. It mirrors the Snap release canary through gateway registration and openshell status, without creating a sandbox.

Related Issue

No issue required: CI packaging coverage and workflow reuse.

Changes

• Add Ubuntu test-guest provisioning for snapd, Docker Snap, and candidate OpenShell Snap installation.
• Build a branch Snap and verify its installed gateway reaches openshell status.
• Extract a reusable single-architecture Snap build workflow and use it from release packaging.

Testing

• mise run pre-commit passes
• Local Ubuntu VM installation/status flow passes with a candidate Snap
• Unit tests added/updated (not applicable)
• E2E tests added/updated (not applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-3182.docs.buildwithfern.com/openshell

[elezar]

@olivercalder I was iterating on this, and it was impossible to get the package installed and connected without this change. Since the gateway service is installed in a started state, it crash loops because it can't discover a valid compute driver. At the point where the sudo snap connect openshell:docker docker:docker-daemon tries to restart the gateway in the connect-plug-docker hook, the restart is rejected because (as Codex proposes) some restart limit has been reached.

The argument of switching to install-mode: disable is then that the service will be started (and enabled) at the point where the docker plug is connected -- either automatically for installations from the Snap store directly, or manually in the case of testing.

I'm not quite certain why the existing canary infrastructure allows things to pass, but it could be that the VM-based tooling that we have now adds some other delay which allows the gateway to restart more often.

[olivercalder]

Hmm thank you for flagging this.

This is interesting to me for a few reasons:

1. As mentioned in test(conformance): smoke Snap artifacts in Ubuntu VM #2869 (comment), if there are two autoconnection candidates due to the presence of the docker snap (which has its own assertion to autoconnect any docker slots to its docker:docker-daemon slot) plus the implicit :docker system slot which the openshell snap has a store assertion to autoconnect, then snapd will not select between those two candidates.
2. But here we're testing the build artifact, not openshell from the store, so it does not have the :docker autoconnect assertion, so the docker:docker-daemon autoconnect should occur automatically.

So I'm rather confused, testing a locally-built (non-store) openshell snap with --dangerous, as long as the docker daemon is preinstalled, should cause the docker slot to be autoconnected during installation. And it seems that's the way you've constructed the nix jobs, so this all looks correct to me.

I do see that the other interface connections don't happen until after the openshell snap is installed, so maybe one of those is causing issues?

Either way, if the issue is just that the OpenShell gateway service has hit its fail limit, then you should be able to do this explicitly:

systemctl reset-failed snap.openshell.gateway.service

after connecting the interfaces but before trying to restart and setup the gateway.

It might be the case that we do in fact want to set install-mode: disable, then leave it to install.sh to ensure the docker interface is connected (in case there are two autoconnect candidates), or for the user to decide whether they want to grant access just to the docker snap or to the system :docker slot. But I don't think this change should be made just for the sake of testing, as then users are required to manually start and enable the service after install when they otherwise wouldn't necessarily need to (though we can make install.sh handle this).

[olivercalder]

Thank you, I really like the way this is laid out.

Regarding the start failure, I think it should be the case that the docker auto-connection should actually occur, since the docker snap carries its own store assertion to auto-connect candidate plugs (such as that of openshell:docker). So the docker connection shouldn't be an issue. But the other interfaces not being connected during install could be an issue.

Either way, I think changing the default install-mode feels like a big hammer if it's just to fix testing of the un-published snap artifact. I think using reset-failed is preferable, but either is fine, I think letting install.sh handle everything is another valid option.

[olivercalder]

This should already be removed by snap remove --purge openshell... is it not?

[olivercalder]

Hmm thank you for flagging this.

This is interesting to me for a few reasons:

1. As mentioned in test(conformance): smoke Snap artifacts in Ubuntu VM #2869 (comment), if there are two autoconnection candidates due to the presence of the docker snap (which has its own assertion to autoconnect any docker slots to its docker:docker-daemon slot) plus the implicit :docker system slot which the openshell snap has a store assertion to autoconnect, then snapd will not select between those two candidates.
2. But here we're testing the build artifact, not openshell from the store, so it does not have the :docker autoconnect assertion, so the docker:docker-daemon autoconnect should occur automatically.

So I'm rather confused, testing a locally-built (non-store) openshell snap with --dangerous, as long as the docker daemon is preinstalled, should cause the docker slot to be autoconnected during installation. And it seems that's the way you've constructed the nix jobs, so this all looks correct to me.

I do see that the other interface connections don't happen until after the openshell snap is installed, so maybe one of those is causing issues?

Either way, if the issue is just that the OpenShell gateway service has hit its fail limit, then you should be able to do this explicitly:

systemctl reset-failed snap.openshell.gateway.service

after connecting the interfaces but before trying to restart and setup the gateway.

It might be the case that we do in fact want to set install-mode: disable, then leave it to install.sh to ensure the docker interface is connected (in case there are two autoconnect candidates), or for the user to decide whether they want to grant access just to the docker snap or to the system :docker slot. But I don't think this change should be made just for the sake of testing, as then users are required to manually start and enable the service after install when they otherwise wouldn't necessarily need to (though we can make install.sh handle this).