Another point raised in a SF case: lots of snap CLI arguments do not work when acting on more than one snap at a time. For example, --ignore-validation, but also I think arguments like --stable, --candidate, --beta, --edge, --dangerous, --unaliased would also make sense to apply to all snaps listed. Currently these all throw an error if used with multiple snaps, like snap install --ignore-validation foo bar.
2 Likes
A post was split to a new topic: Helping out with hidden snap folder support
I sometimes work with a bad internet connection, syncing a container to my local machine.
I get extremely irritated if I make a typo specifying the target container on resync. With zfs i get the full container instead of the diff then. It is especially annoying as there is no way to stop the full transfer.
Following features would help:
- lxc copy: have
--refreshabort the copy if the given target does not exist (maybe a flag to override--force, or for backwards CLI compatibility the other way round, a--check-target-exists) - lxc copy: Add a
--abortparameter - cancel a running operation, keeping the old config and reverting to the old state - lxc completion bash: generate a completion which is able to handle the
local:~remote - lxc completion bash: generate a completion which is able to complete the target instance for lxc copy; at least if
--refreshis given. But I think that makes sense in the general case. It currently completes remotes correctly, but no instances. And also `local: is not offered
(Side-note: it I think it should also possible to implement a --continue to continue without full resend if the stream got interrupted with zfs)
I would guess that bash completion could be papercut territory(?)
Thought: how about an autoremove-like feature to cleanup any no longer needed “automatic snapshots the system has taken when you uninstalled any snap without --purge” (just learned this was a thing thanks to @ogra)?
1 Like
This is now done. The architecture is included since 2.72, but I also landed information on the source of snapd and snap binaries.
Architecture:
$ snap version
snap 2.72+g269.14869287a0-dirty
snapd 2.72+g269.14869287a0-dirty
series 16
arch -
kernel 6.17.9-arch1-1
architecture amd64
More info:
$ snap version --verbose
snap 2.72+g269.14869287a0-dirty
snapd 2.72+g269.14869287a0-dirty
series 16
arch -
kernel 6.17.9-arch1-1
architecture amd64
snapd-bin-from native-package # or 'snap' when using reexec
snap-bin-from native-package
Unfortunately, as I mentioned before, folks are likely parsing the output, and given you could do something silly like snap version | awk '/snapd/ { print $2}' (in which case both snapd and snapd-bin-from will match) I felt it’s safest to hide the new fileds behind a --verbose flag.
1 Like
It’s probably best if you open an issue about this in the LXD issue tracker.
There’s one more thing coming for 2.74. We’re adding a new snap report-issue command which will hopefully help with reporting problems about individual snaps. It combines some information from snap info and snap info --verbose. That’s how it looks in action:
$ snap report-issue ohmygiraffe
Contact information provided by "ohmygiraffe" snap publisher:
Issue reporting:
https://github.com/kz6fittycent/ohmygiraffe
Website:
http://www.ohmygiraffe.com
Source code:
https://github.com/kz6fittycent/ohmygiraffe
Use one of the links listed above to report an issue with the snap.
Would you like to open https://github.com/kz6fittycent/ohmygiraffe in browser? [Y/n] ^C
$ snap report-issue firefox
Contact information provided by "firefox" snap publisher:
General:
https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
Website:
https://www.mozilla.org/firefox/
Use one of the links listed above to report an issue with the snap.
Would you like to open https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla in browser? [Y/n] ^
The snap details page available to publishers allows to add a dedicated issue tracker link, but in case the publisher has not provided one, the code tries to guess which of the existing URLs looks most likely to point at some support page (see the output for firefox above).
Maybe I could hook this up somehow to ubuntu-bug, reportbug (for Debian) or others.
3 Likes
Maybe this is too big for this initiative, but I’d like to see more snapd changes history.
I was asking about it here already.
I find the retention extremely limiting, especially when debugging an issue. Even for Canonical support staff it’s very limiting as when we/customers try and create an issue about something any related change information is quite likely to be missing.
What do you think ?
Cheers, Just
4 Likes
snap refresh is not fully functional if you use validation-sets and are ignoring a validation-set assertion for one or more installed snaps.
Something that’s a non helpful UX IMO.
In this example, we have a validation-set controller snapd revision, it’s been ignored to test a newer revision, but we can’t properly make use of snap refresh generally on the system now.
System wide snap refresh not usable
# snap refresh
error: cannot refresh: cannot update snap "snapd" to revision 25577 without
--ignore-validation, revision 23771 is required by validation sets:
~~~8<~~~
Can’t even list pending updates
# snap refresh --list
error: cannot list updates: cannot update snap "snapd" to revision 25577 without
--ignore-validation, revision 23771 is required by validation sets:
~~~8<~~~
For system wide refresh, there’s an argument to be made that the above behaviour is correct, but I think it’s a point of view. snapd could just exclude any snaps with an ignored validation-set set from the system wide refresh, even if via a new option.
Single snap refresh still works, but you have to know which ones have pending updates, which is a bit cumbersome.
For refresh list, I think there’s less of a compelling argument for the current status, why not simply tell me about he pending updates anyway, perhaps highlighting the snaps that are ignoring validation-sets and blocking refresh ?
Cheers, Just
1 Like
I think this is very much needed. I have a daily cronjob dumping the info in a logfile so it does not get lost.
Can you elaborate on how you’re ignoring the validation set? You change it to monitor mode?
I think there’s a case to be made that old entries could be evicted to some sort of archive file. This brings another question of what is the acceptable size of such archive file and whether one size fits all. Users would need to have a way to set a limit or rotate the files somehow. Alternatively snapd could be only responsible for writing the archive file, if enabled in system settings, while truncation/size limit is up to the user, like we used to do with logs files.
Just be refreshing with --ignore-validation
So:
snap refresh --ignore-validation --revision 12345 my-snap
Cheers, Just
As a potential way of doing it reasonable transparently, without danger of filling up a disk, the size could be based on current free space guarantee of the containing volume instead of an absolute size. So, something like “do not allow archive to to take the volume into less than 50% free”, or something like that as very basic example.
Cheers, Just
Right, this now becomes a design exercise and rules that this one are a bit vague, without knowing for what purpose snapd would be collecting this data. One could argue that the logs are precious and the limit should be set differently, or that the log is useless and should be dropped right away. What the correct knob is, or whether any other factors are to be considered (why not amount of free space left?). TBH. I’d prefer the customers and users to be answering said questions themselves and be clear about it right from the start.
As noted above, it’s always requested for support issues, yet frequently isn’t available. This is the most frequent example of a pain point this is causing us [ and Canonical support engineers ], for nearly every ticket.
That’s at least one purpose/use-case.
Also, there is a [ seemingly ] arbitrarily chosen a limit right now. I don’t know the correct process for making any changes there.
I’m just telling you about a frequent issue, that could be small change to fix 
It would be a shame, bit if its reject from here because it turns out to be too big for this initiative, that’s also fine.
Cheers, Just
1 Like
Filed a bug in LP:
3 Likes
A bit of a feature request, but I think it would be really useful to have an --arch flag in snap info and snap search to get info on snaps for the given architecture.
E.g. snap info --arch arm64 steam would show information about the steam snap, which I just learned has a new version which bundles fex. I’d love to see its release information, but can’t from amd64 
This would be particularly useful for snap developers who want to check on their releases from the end-user POV on various architectures other than those of their development machine.
3 Likes
Could you file a bug in LP about it?
Another candidate