schnapps issueshttps://gitlab.nic.cz/turris/schnapps/-/issues2021-06-21T11:10:10+02:00https://gitlab.nic.cz/turris/schnapps/-/issues/39Allow import of medkits2021-06-21T11:10:10+02:00Karel KociAllow import of medkitsRight now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an in...Right now the only way to import medkit is to import it as a factory. This is in most cases the correct way user wants to import medkit but sometimes it makes sense to want to import it just like the regular snapshot without having an info file. I mostly use it when someone sends me the image to test some issue. I do not want to replace the factory image and I do want to remove it afterwards.
My suggestion is to allow import of generic medkit with switch `-m`:
```
schnapps import -m omnia-medkit-100.tar.gz
```
It would automatically fill in info for example as if following info file would be provided:
```
TYPE="single"
DESCRIPTION="Medkit: ${file%.tar.gz}"
CREATED="$(date)"
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/schnapps/-/issues/28Add some sort of target rollback selection instead of default latest snapshot2021-02-22T10:51:47+01:00Karel KociAdd some sort of target rollback selection instead of default latest snapshotI am commonly experiencing issue that router gets stuck in some situation after update. In such case rollback using button is no use because it rollbacks it back to post-update state with existing error.
I think that solution is simple ...I am commonly experiencing issue that router gets stuck in some situation after update. In such case rollback using button is no use because it rollbacks it back to post-update state with existing error.
I think that solution is simple and that is to not automatically rollback to just any snapshot. I see two possible ways but there might be even more:
* Have some selection for automatic rollback. That is something like pointer to snapshot that should be used for that. We can move it for example after successful boot (thus ensuring that router at least boots after rollback).
* Allow snapshot to select if it should be target of automatic rollback (of course using number should still work). The use case is to mark post-update snapshot that is automatically created as not target of automatic rollback selection.
It would be also awesome if new solution would work with rollback mechanism of previous schnapps commands as that would make it immediately available to all users.https://gitlab.nic.cz/turris/schnapps/-/issues/26Decide what to do about subvolumes2020-09-16T15:05:49+02:00Michal HruseckyDecide what to do about subvolumesDecide what to do about subvolumes that are bellow the original subvolume.
Options:
* notify user that he is doing something he shouldn't
* snapshot them recursivelly
I'm leaning more towards the first option. Second option kinda defi...Decide what to do about subvolumes that are bellow the original subvolume.
Options:
* notify user that he is doing something he shouldn't
* snapshot them recursivelly
I'm leaning more towards the first option. Second option kinda defies the purpose of the subvolume. Lets meditate about it.https://gitlab.nic.cz/turris/schnapps/-/issues/21Add support for relationship between snapshots on different filesystems2021-02-22T10:25:14+01:00Karel KociAdd support for relationship between snapshots on different filesystemsWith storage plugin and rollbacks it is problematic that all files on external storage are kept as they were. This can cause rollback to break anything that has files in `/srv`.
It would be nice to be able to tie together snapshots on d...With storage plugin and rollbacks it is problematic that all files on external storage are kept as they were. This can cause rollback to break anything that has files in `/srv`.
It would be nice to be able to tie together snapshots on different filesystems so they will be always rolled back together.
Additionally tie together different filesystems so creating snapshot on one will create a snapshot on the second one as well.https://gitlab.nic.cz/turris/schnapps/-/issues/13[feature suggestion] Automatic sync on creating/modifying snapshots2019-11-18T16:53:36+01:00David Beitey[feature suggestion] Automatic sync on creating/modifying snapshotsWhen reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might auto...When reading the documentation for sync (https://docs.turris.cz/geek/schnapps/schnapps/#remote-manipulation-with-snapshots), I got the impression from setting up a remote URL as part of the 'global' configuration that schnapps might automatically keep things in sync when creating/modifying/deleting snapshots.
This isn't currently the case so it'd be great if there was an option to enable this -- or else made the default if a remote URL is configured. I feel this is a sensible default as it would help ensure remote snapshots are always up-to-date (particularly helpful in the case of backups).
I've set up `cron` to run `schnapps sync` periodically, but given the [schedule for schnapps](https://gitlab.labs.nic.cz/turris/schnapps/blob/master/schnapps.cron) it's fiddly trying to ensure calls to `sync` run at the right times.Michal HruseckyMichal Hrusecky