Disabling automatic refresh for snap from store

backlog

#101

@keg, I’m not sure if you found your answer or not (I think I replied to something like your comment in a different thread, but I’m not sure if it’s worth moving it).

The snapd timer is internal; it won’t show up under systemctl list-timers. That timer that you see, you can disable it if you want — it’s getting removed in an upcoming release after we confirmed it’s not needed (and confuses things for people wanting to set the refresh slower than that timer).

To see snapd’s timer, try

$ snap refresh --time 
timer: 00:00~24:00/4
last: 2018-03-07T23:35:00+01:00
next: 2018-03-08T05:09:00+01:00

#102

Could the snapd timer (or a future global switch) work with the ‘Restrict background data usage’ toggle in GNOME 3.28 (see the ‘Metered Bandwidth Toggle’ heading)? (Tagging @kenvandine because I think he works on GNOME-snapd interaction?)


Snap refresh over metered connections
#103

Wondering if there is a news on this particular front?


#104

Did you see Announcing Snap Enterprise Proxy Beta ? The Snap Enterprise Proxy solves this issue.


#105

A lot of valid use cases for this to be added in this thread but in reality, the lack of this feature immediately disqualifies snaps for any system that requires 24/7 guaranteed operation/up time.

Seems to me like that would cause a high lack of adoption for anybody designing a system requiring this.

I hope we’re getting closer to a kill switch option over there…


#106

I think if you ask questions you might just find that there is no intention of ever including a ‘kill switch option’ - - - - ever.

For me - - - I have been, and am, working on finding ways to control this penchant for updating. I also really don’t like being forced to run on ‘edge’ level which is even less secure than beta according to the docs I’ve been able to find.


#107

@dabeegmon who is forcing you to run edge?


#108

Hi,

The need for this is exactly why we built the Snap Enterprise Proxy. Did you check it out? Is there something about it that doesn’t fit what you’re looking for? I’d love to get feedback.

So close, we made a release of it! See Announcing Snap Enterprise Proxy Beta


#109

I don’t know who set it up. I installed snapd from debian repositories. Know that now I’m using edge - - - isn’t what I normally do (one of the reasons I run debian is that I get to choose at which level of software risk I wish to work) but I’m not given any kind of choice in the snapcraft world re: upgrades nor updates. I would prefer to be running at ‘stable’ as this software is on my server and I want reliability in server applications.

At install there were no clear directions on how to set up snapd to use any particular channel in the available docs. Subsequently read of the method after someone else had some problems with their installation and that information was given as part of the ‘fix’.


#110

You’re asking for feedback.

Two issues:

  1. product is in beta
  2. product is not open source

#111

I think perhaps you’ve misunderstood the model - snapd isn’t a distribution like Debian or Ubuntu, there isn’t a global switch to use unstable or stable.

The decision is made on a per-snap basis and allows the user to make different decisions for different application according to their needs and comfort levels.

e.g. you could help Mozilla test the latest bits by using firefox from edge because it’s not business critical to you, but at the same time you could use canonical-livepatch from stable, because you want a higher level of stability there.


#112

Snaps do not in any way autmatically swithc to “edge” unless you explicitly told snapd to do this for you with either snap switch --edge <snapname> or snap refresh --edge <snapname>

What are the snaps you see being switched to the edge channel without you asking for this ?
snap list |grep edge

By default you will always install and run only stable snaps unless you actively tell the system to not do this… typically these snaps have gone through a process of QA and testing in the edge, beta and candidate channels before they enter stable.

just like a debian package in debian might enter via experimental, go to unstable, then testing and later land in stable after all QA has been processed, there isnt so much of a difference, except that the design of snaps makes them completely independent from the host OS.


#113

After quick review of the documentation, i’m struggling to wrap my head around how this as being treated as an acceptable solution. It really feels like this was a completely isolated development project to solve other use cases that just happened to give a work around to solving the forced update issue people want to turn off themselves.

The prerequisites in themselves are an extensive list of setup and configuration steps needed just to be able to start using the proxy and then that doesn’t even account for all the setup and headache it’s going to take to get the actual runtime setup correctly.

So if I were to review the user/developer conversation from this thread, it just doesn’t feel like this is the right answer to this issue:

User: I want to turn off updates
Developer: we aren’t going to let you
User: I need to for these reasons
Developer: Okay, but you have to do a lot of extra work with another software package to get it to do that
User: So you will support configuration that allows turning off updates indefinitely by doing this?
Developer: Yes
User: So can you just give me an option to tun them off directly without all the extra work?
Developer: No


#114

The documentation that I have been able to find (very much not much available) indicated that ‘core’ is a requirement for running snapd.
So when I downloaded snapd core was also installed. I was not asked which channel I wanted - - - it was prescribed.
I have, due to lack of knowledge (itself largely due to the paucity of documentation) inadvertently viewed snapcraft as being comparable to an os - - - when in reality it is and it isn’t.
It is in that it manipulates oses and it isn’t in that it does require an os to work.


#115

I love your total adherence to the party line.

You might want to check on the snap labeled ‘core’ - - - it is neither independent from snapd nor is it independent from the host OS.
Any changes that may have been introduced were to maintain a working system following the directions of either the team producing the snap or the dev team here.
It does seem like the team here likes to work on the edge - - - for a business on the other hand - - - risky software is quite easy to justify discarding - - - - it tends to produce far too much stress.


#116

Please don’t struggle - - - -you will only hurt yourself. The wonderful people here only want to help you so you don’t hurt yourself - - - - but you must do EVERYTHING as they tell you do. If you are bad - - - - things will not go well for you!

Your review is - - - imo - - - quite accurate!


#117

I’m afraid I can’t continue the discussion in this tone.


#118

The core snap tracks the stable channel by default and the release process means that the core snap goes through the beta and candidate channels (spending considerable time in them) before reaching stable. People who need reliability are encouraged to find a way to test new versions coming through beta and candidate before they hit stable and report issues to the snapd team. If they find an issue, it will be fixed via a point release and a regressed version of core will not hit stable until the issue is fixed. You also have the Snap Enterprise Proxy if you need to hold back updates.

(Would like to mention that I’m not part of the snapd, snapcraft, or snap advocacy teams and thus, I hope, my opinion is independent)

I would also like to request that this topic is kept open and that if action needs to be taken on any posts that infringe the advice in the FAQ then that should be taken, rather than closing the topic :slight_smile:


#119

While I don’t agree with the developers decision to not allow toggling updates on and off, they do deserve to be treated with respect.

The biggest problem stems from Canonical developers ignoring user feedback in this case. There are valid use-cases, both in enterprise and in desktop usage where control over updates is beneficial if not critical.

The solution suggested here indirectly solves it in a bad way. Ask one of your user experience colleague’s what he thinks of the suggested workflow.

Moreover the suggested solution is proprietary. For those of us who factored open source into the decision to use Ubuntu, this is a red flag.


#120

I think the following quote explaining why the store is proprietary may be of interest here: