Snapshots detail either too short or too verbose

LXD
1

/1.0/instances/c1/snapshots?project=101

get you only snapshot name:
[0] => /1.0/instances/c1/snapshots/k1?project=101
[1] => /1.0/instances/c1/snapshots/k2?project=101
[2] => /1.0/instances/c1/snapshots/A-0?project=101

/1.0/instances/c1/snapshots?project=101&recursion=1

Along useful information such as [name][expires_at] [created_at] [stateful] [size], it spits for each snapshot the whole story of its attached instance [config][expanded_config][expanded_devices] which leads to a very large output, in case you had some daily plans and lots of snapshots.
Those instance related information are just showing the actual status of container and not related to snapshot.
Once you apply the snapshot to parent container, the config remains anyways the same.
If you create a new instance from it, the config will be either the one you define by profile or otherwise or it should use the config of the parent of snapshot.

BTW, [last_used_at] never changes, what sort of information it supposed to show?

2

Snapshots include instance config/devices/profiles, so it’s perfectly normal to have them show you that information, it is not duplicated from the parent instance.

When you restore a snapshot, it’s not just the filesystem being reverted but the config too.

3

Appreciate your feedback.
I have experienced otherwise.
Config is the actual instance config mirrored on snapshot.
So, snapshot seems merely just revert the storage back and no more.

I have container c1 profile x.
Fetch snapshots info, in all i get profile x specific config, 2xcpu, 2G Ram, 1GB storahe etc.

I change the container profile to y.
All previously taken snapshots showing mow the config y.
Use an old snapshot, it exactly creates or reverts back by utilizing newly applied profile.
So, snapshot is headless and don’t need to mimic the config story.

4

Having implemented snapshots myself, I beg to differ :wink:

stgraber@castiana:~$ lxc launch images:alpine/edge a1
Creating a1
Starting a1
stgraber@castiana:~$ lxc config show a1
architecture: x86_64
config:
  image.architecture: amd64
  image.description: Alpine edge amd64 (20210730_03:56)
  image.os: Alpine
  image.release: edge
  image.serial: "20210730_03:56"
  image.type: squashfs
  image.variant: default
  volatile.base_image: 566601fee5bcfba62c3b814baf86fc0a158539b17a9c6b46f1b90e625ded9826
  volatile.eth0.host_name: veth21287d58
  volatile.eth0.hwaddr: 00:16:3e:a6:f4:c2
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 7e0ff1e7-a9a0-4056-a66b-aba567c967bc
devices: {}
ephemeral: false
profiles:
- default
stateful: false
description: ""
stgraber@castiana:~$ lxc snapshot a1
stgraber@castiana:~$ lxc config set a1 user.foo bar
stgraber@castiana:~$ lxc snapshot a1
stgraber@castiana:~$ lxc config show a1 | grep foo
  user.foo: bar
stgraber@castiana:~$ lxc config show a1/snap0 | grep foo
stgraber@castiana:~$ lxc config show a1/snap1 | grep foo
  user.foo: bar
  user.foo: bar
stgraber@castiana:~$ lxc config unset a1 user.foo
stgraber@castiana:~$ lxc config show a1 | grep foo
stgraber@castiana:~$ lxc restore a1 snap1
stgraber@castiana:~$ lxc config show a1 | grep foo
  user.foo: bar
stgraber@castiana:~$
5

Thanks for clarifying.
BTW never doubted your expertise and authority in this area :slight_smile: