Request for classic confinement for TDengine snap

I suppose publishing a new revision should do?

I will update the package version to align with the classic package (even including Windows version) release in the future.
Current 2.0.2.0 is aligned with the latest stable version of the classic release. Appreciated it if it can be approved manually.

One more question, My snap will release new version with classic package release accordingly. So should I modify snapcraft.yaml every time then commit to git repo? Or to compose a small script to modify version string before run snapcraft. Can I specify snap version by command line argument?

Thanks,

The snap version is settable via a part’s scriptlet, refer the adopt-info key for more info.

Also refer: Selective-checkout: Check out the tagged release revision if it isn't promoted to the stable channel

Disclaimer: Own product, use with your discretion.

Understood. Thanks @Lin-Buo-Ren

Another question, how to transfer the snap, especially snap name to another account? I uploaded the tdengine snap to store and display my launchpad name as publisher. I need transfer it to another account with my employer’s company name as publisher and make its name verified with a checked emoji.

Refer The store-requests category in the Snapcraft Forum for such matter.

For the “verified” check mark, I believe it is only granted to the (very) high-profile snaps, maybe the @store folks can help.

OK.

New question, as when the user remove a snap, the data files will be removed too. But as a database software, most scenario should keep data files untile the user manually delete them. How I can implement this with snap?

When your snap is removed, a snapshot of its data is created that will be retained for a month:

If a user reinstalled your snap in that time, then the data will be restored with it. It is possible to omit some data from the snapshot through the remove hook, as described here.

There isn’t currently a way for a snap to have data in snap specific system wide dirs persist in place after removal though.

1 Like

Is it possible for a snap service to access a user’s data path via home and removable-media interfaces, though?

Data outside of the snap-specific dirs (i.e. $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA, and $SNAP_USER_COMMON) won’t be touched on snap removal.

A hook won’t be able to access data in individual users’ home directories though, unless it has read: all set on its home interface plug (which will trigger manual review on the store).

It is possible to retain a snap’s data forever?

As the document I linked states, manually created snapshots are retained until they are discarded. It also explains how you can control the life cycle of automatic snapshots via the snapshots.automatic.retention configuration variable (either disabling their creation entirely, or changing how long they are retained).

I did skimmed through the referring document, however I would really like to see permanent retention for the automatic snapshots, even when it need to be opted-in manually.

I guess snap set system snapshots.automatic.retention=100y might work, but a forever value instead of <duration> or off might also be appreciated.

I tried to save/restore it on a centos system. but seems not all data be saved then restored data makes the server fails to start now.

$ sudo snap logs tdengine
[sudo] password for shuduo:
2020-09-09T03:00:05Z tdengine.tdengine[6787]: 09/09 11:00:05.921277 
0x7f70e8f1d3c0 DND Failed to start TDengine, please check the log 
at:/var/log/taos
2020-09-09T03:00:05Z tdengine.tdengine[6787]: config file:/etc/taos/taos.cfg not 
found, all variables are set to default
2020-09-09T03:00:05Z tdengine.tdengine[6787]: failed to open log 
file:/var/log/taos/taosdlog.0, reason:No such file or directory
2020-09-09T03:00:05Z tdengine.tdengine[6787]: failed to init log file
2020-09-09T03:00:06Z systemd[1]: snap.tdengine.tdengine.service holdoff time 
over, scheduling restart.
2020-09-09T03:00:06Z systemd[1]: Stopped Service for snap application 
tdengine.tdengine.
2020-09-09T03:00:06Z systemd[1]: start request repeated too quickly for 
snap.tdengine.tdengine.service
2020-09-09T03:00:06Z systemd[1]: Failed to start Service for snap application 
tdengine.tdengine.
2020-09-09T03:00:06Z systemd[1]: Unit snap.tdengine.tdengine.service entered 
failed state.
2020-09-09T03:00:06Z systemd[1]: snap.tdengine.tdengine.service failed.

There are three kinds of data be used by the tdengine daemon. 1, /var/snap/tdengine/current/etc/taos/taos.cfg; 2. /var/snap/tdengine/current/var/log/taos/taosdlog.0; 3. /var/snap/tdengine/current/var/lib/taos/.

They are managed to be layout:
layout:
/var/lib/taos:
bind: $SNAP_DATA/var/lib/taos
/var/log/taos:
bind: $SNAP_DATA/var/log/taos
/etc/taos:
bind: $SNAP_DATA/etc/taos

Not sure if any trick needed to handle it.

i guess your app tries to write to the dir but the dir structure does not exist yet … you likely want to create an install hook or a command-chain: script that calls mkdir -p for $SNAP_DATA/var/lib/taos, $SNAP_DATA/var/log/taos and $SNAP_DATA/etc/taos …

like:

#! /bin/sh

[ -d "$SNAP_DATA/var/log/taos" ] || mkdir -p $SNAP_DATA/var/log/taos
[ -d "$SNAP_DATA/var/lib/taos" ] || mkdir -p $SNAP_DATA/var/lib/taos
[ -d "$SNAP_DATA/etc/taos" ] || mkdir -p $SNAP_DATA/etc/taos

… and if the cfg file needs to be there before first start, you maybe also want to copy it into $SNAP_DATA/etc/taos from that script …

1 Like

I already use install hook can layout section to handle it. It works for normal install.

$ cat snap/hooks/install 
#!/bin/sh

if [ ! -d /var/lib/taos ]; then
  mkdir -p /var/lib/taos
fi

if [ ! -d /var/log/taos ]; then
  mkdir -p --mode=777 /var/log/taos
else
  chmod 777 /var/log/taos
fi

if [ ! -d /etc/taos ]; then
  mkdir -p /etc/taos
fi

if [ ! -f /etc/taos/taos.cfg ]; then
  if [ ! -d /etc/taos ]; then
    mkdir -p /etc/taos
  fi
  cp $SNAP/etc/taos/taos.cfg /etc/taos/taos.cfg
fi

$ tail -8 snap/snapcraft.yaml 

layout:
  /var/lib/taos:
    bind: $SNAP_DATA/var/lib/taos
  /var/log/taos:
    bind: $SNAP_DATA/var/log/taos
  /etc/taos:
    bind: $SNAP_DATA/etc/taos

Before I restore my snapshot, the daemon can start as usual. After I restore the snapshot, I see the files be saved to the directories it should be and I checked the md5 is same as original. But the daemon failed to read its cfg file and can’t write to the log file. :frowning:

Hi @alexmurray @jamesh @ogra

I start a new thread for transfer ownership of tdengine to my employer account. Seems no one takes care of it. Could you please let me know if it will be processed?

Thanks,
Shuduo

1 Like

Hi @shuduo,

I can see @roadmr has already answered your transfer ownership request. Can you please add the other account as a collaborator as he suggested so we can move forward with your request?

Also, are you still experiencing issues with your snap? Were you able to solve your install hook/snapshot issue? I see you mentioned you do not need personal-files nor system-files anymore and your last revision https://dashboard.snapcraft.io/snaps/tdengine/revisions/7/ is successfully published. If that’s the case we can remove this request from our queue.

Thanks!

1 Like

OK. I think phase one is completed. I don’t need personal-files and system-files for now. Please close the request. Thanks.

2 Likes