Do we want to have subscriber service (like on RancherOS)?

[olljanat]

RancherOS 1.5.1 added subscriber service like this:

There is now a built-in service for system upgrades that requires access to the internet. By default, it can detect system updates and downloads the required files. It will not automatically apply the patch. If you want to completely disable this feature, just run ros config set rancher.upgrade.policy none

It was added by rancher#2667 and I assume that they used it to get understanding that how widely RancherOS have been used. It collects processor architecture, system UUID and OS version with these commands and reports them to Rancher:

uname -m
sudo cat /sys/class/dmi/id/product_uuid
sudo ros -v | awk '{print $2}'

Besides of data collection it also will pre-download OS upgrades or even do upgrades automatically if user have enabled it ros config set rancher.upgrade.policy auto

Currently subscriber service is disabled from BurmillaOS beta versions but similar data would be useful for its maintainers too.
What others think, are those infos anonymous enough that we can have enabled by default (and users will be still able to disable it if they want)?

What comes to auto download/upgrade feature. I don't want to have one big "master switch" but instead of it we should make that URL and schedule configurable so users can use it to mass deploy upgrades when they want.

[tomaswarynyca]

I think we have to continue with that functionality since it will give us a notion of which architectures are more used to be able to focus on working on them to get better performance for example.

I think updates should be automatic to provide greater security against serious problems such as vulnerabilities.

[olljanat]

You mean that we actually should make updates automatic by default?

Currently version have been read from http://ros.rancher.io/gateway/version which looks to be just simple text file so we can easily add similar to https://github.com/burmilla/releases/tree/v1.9.x and then just set branch policy on way that it will require at least two of us need to approve it before merge (as it will really trigger upgrades then).

If we do that then we most probably should allow users to also modify that URL so they can example fork that releases repository and that way control that when upgrade happens on their environment.

What comes to that data collection. We need figure out some good place host service which will collect that data.

[tomaswarynyca]

You mean that we actually should make updates automatic by default?

Yes, I could do the automatic updates by default so we save problems. But putting in the cloud-config.yml an option to disable automatic updates giving the user the option of when to update.

To get the version and anonymous data collection we can make an API in PHP to provide the number of the latest version and to upload through a POST request the information collected from the user.

[PrplHaz4]

IMO automatic updates and any telemetry should be opt-IN only. This project should be a steward of open source and act in good faith by default.

IMO it's not worth thinking about auto updating until there's a string of successful, non-breaking stable releases.

Docker Hub should give enough in terms of download stats per image/arch to get directional information.

Github and Docker Hub are already centralized dependencies - I don't think it makes sense to add more or try to maintain a centralized service outside of those until the project has grown and it's actually needed.

I like that RancherOS can check against current version and easy updating (as well as @olljanat's plan above to maintain it in the repo with a commit policy).

[olljanat]

IMO automatic updates and any telemetry should be opt-IN only. This project should be a steward of open source and act in good faith by default.

Agreed. That why I removed whole feature on this point.

Docker Hub should give enough in terms of download stats per image/arch to get directional information.

True so let's rely to those stats then.

Github and Docker Hub are already centralized dependencies - I don't think it makes sense to add more or try to maintain a centralized service outside of those until the project has grown and it's actually needed.

Yea and I like to use only services like these which are free for open source projects and so we don't need maintain any infrastructure.

I like that RancherOS can check against current version and easy updating (as well as @olljanat's plan above to maintain it in the repo with a commit policy).

OK. Then I propose that we reintroduce this one example under "auto-updater" name on os-services which can be enabled with ros service enable auto-updater and scheduled using system cron https://burmillaos.org/system-services/custom-system-services/#service-cron

[ToeiRei]

Just my two cents here:

• We do not need to track users. Lots of people are willing to share their use case I'd suspect as the project takes up speed.
• Auto updates are nice to have

[olljanat]

Closing because not planned.