I guess the main difference between check and updatesready is that the latter requires you to fetch the updates first, right? Is the workflow you envision a cron or periodic job that only runs freebsd-update check and informs the user if there are any updates, but makes them actually fetch those updates manually? For a user who eventually applies every update, will this new workflow result in less total load on the update servers, or about the same?

In D36241#823751, @asomers wrote:

I guess the main difference between check and updatesready is that the latter requires you to fetch the updates first, right? Is the workflow you envision a cron or periodic job that only runs freebsd-update check and informs the user if there are any updates, but makes them actually fetch those updates manually? For a user who eventually applies every update, will this new workflow result in less total load on the update servers, or about the same?

indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.

check the TEST PLAN above

updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.

the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).

how would that be done, you may ask? by setting a temporary UNAME_r env. variable and running freebsd-update check I'd say.

the further available flexibility delivered by this new check command would also allow users (sysadmins?) to:

• save their download traffic (paying less money?, in case of regular unwanted binary files download);
• avoid unnecessary disk I/O, when fetch writes small or mid size files to the cache directory;
• enhance a way to monitor for available updates (as mentioned before, by not fetching all files at once);
  • it includes monitoring available updates using either a simple shell script, a Nagios plugin, or more complexes scenarios using Grafana or whatever;
• reduce the time of automated deployments on workflows and pipelines that rely on freebsd-update to create virtual machines, physical servers or just jails;
• let users (sysadmins?) define a e.g.: "policy to update FreeBSD machines" only when -p2/-p4/-p5 versions are available -- or whatever the new flexibility provides them.

indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.

check the TEST PLAN above

updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.

the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).

But every user who runs "freebsd-update check" will eventually also run "freebsd-update fetch". So is the overall load any less this way? Does "freebsd-update fetch" download all files on every invocation, even if there are already downloaded files that haven't been installed?

In D36241#824095, @asomers wrote:

indeed the main difference is that check only fetches a bare minimum (and sanitized) tag, which tells us which version is available on FreeBSD's update servers.

check the TEST PLAN above

updatesready do not work in that way; it downloads like all binary files and at the end report back that one is able to run e.g.: freebsd-update install.

the so-called footprint and impact coming from the "client machines" against the update servers using this proposed check command is way smaller compared to running others like install - and, IMHO, that new check command can also be used in a way to verify for available upgrades as well (again, without really fetching all required files to perform such action).

But every user who runs "freebsd-update check" will eventually also run "freebsd-update fetch". So is the overall load any less this way? Does "freebsd-update fetch" download all files on every invocation, even if there are already downloaded files that haven't been installed?

that's correct, indeed: eventually we do need to run freebsd-update fetch in order to get our updates.

should one runs that routine in a crontab(1) to check for updates every day - which I believe a few people do - then these folks are repeatedly running "fetch_inspect_system" and having subtle little spikes on their machines' load (I know: not the perfect terminology here. just wish to try illustrating a point).

the proposed check command interrupts the verification for available updates before reaching that point and still serves the purpose (the purpose of only checking for updates and existing).

by having the option to run check, we do not need to:

1. fire up unnecessary HTTP requests fetching a) metadata indexes, b) sort them, and c) download all the binaries;
2. stop by the "Inspecting system..." stage;
3. copy unmodified files and prepare a rollback (which is only a thing after we have installed something).

there's also something else to bring into consideration

maybe for some folks downloading 28MB or 200MB is not a big deal, but in some places around the globe we do have users/admins that would pretty much need an alternative option like check to avoid downloading that amount of data;
running a simple check in one place and take the opportunity to download the data in a different one can be handy, or just download in a different time of the day.

here we have maybe a different point of view that could be sweet to share:

• 12.3-RELEASE

taking the 12.3-RELEASE as example, the very first run of freebsd-update fetch running on a fresh installed system would produce the following:

root@freebsd:~ # env PAGER=cat time freebsd-update fetch >/dev/null
       38.63 real        20.64 user         1.81 sys

root@freebsd:~ # cat /var/db/freebsd-update/tag
freebsd-update|amd64|12.3-RELEASE|6|c63d0d5b3974423f39310a515f177873bea6b649510643bd0781788c062fa41d|1675123200

root@freebsd:~ # du -sh /var/db/freebsd-update/
150M    /var/db/freebsd-update/

running the very same command again would present us the following:

root@freebsd:~ # env PAGER=cat time freebsd-update fetch >/dev/null
       12.51 real        10.94 user         0.88 sys

if there's the check command available as an alternative option to just check for updates, well:

root@freebsd:~ # time freebsd-update check >/dev/null
        0.41 real         0.09 user         0.06 sys

ping?

any further suggestions or inputs about this change request? anyone?

I've being running that for quite a while and the fleet is green ever since.

thanks @gbe !
it would be awesome to get approval from src, so we can land this one -- which I am using solo for quite a time

any new input from @src would be really appreciated here; this is running smooth for me since past updates (for all supported releases).

ping @asomers @cperciva, and others maybe?

The only problem I have with this new feature is that it is 75% redundant with updatesready. I think that having two so-similar features will confuse users. Is there any way to get the benefits of both, while not adding any new commands?

In D36241#861449, @asomers wrote:

The only problem I have with this new feature is that it is 75% redundant with updatesready. I think that having two so-similar features will confuse users. Is there any way to get the benefits of both, while not adding any new commands?

they are used for different purposes, once we look and analyze the code;

• check verifies the remote update servers if there's something to be fetched, and returns a status for that;
• updatesready checks if the local machine has binaries (which were already downloaded) on a particular BASEDIR ready to be installed.

that said, would you mind to raise us attention to those "75% of code redundancy" you say check is if compared against updatesready? I am not sure if I was able to follow that, or you missed the point while analyzed them in the way described above.

on top of the past descriptions flagged on this very same comment, I shall ask for a quick look on the fact of how this new proposed command to the freebsd-update has a positive impact on performance and disk I/O -- in which way? here you must read the description, with its detailed information.

ping

ping @src