Check if there is an upgrade available every now and then #208

New Issue

2021-10-19T09:15:22Z

knoflook commented

2021-10-19 09:15:22 +00:00

we obviously don't want to do that every time you run abra, but we could run a check when you run commands that connect to the internet. To additionally minimise the internet footprint we can simply get a random number every time so that there's a 20% chance the code executes, and/or we could have a small file ~/.abra/.lastupdatecheck that would have the date and time of last check and if i.e. at least a day passed since then it's gonna check again. Simple and elegant, and if it can't check it can throw a DEBUG or INFO message. Additionally we can utilise concurrency to not slow things down: so a new thread would be spawned on startup that would run concurrent to the normal code and then right before abra exits it could print the last line like: INFO: there is a new abra version available. To install it run abra upgrade and then we can also have another file like ~/.abra/.newversion that will store this info and if this file exists abra will always show this information and won't even run the code to check for a new version.

we obviously don't want to do that every time you run abra, but we could run a check when you run commands that connect to the internet. To additionally minimise the internet footprint we can simply get a random number every time so that there's a 20% chance the code executes, and/or we could have a small file ~/.abra/.lastupdatecheck that would have the date and time of last check and if i.e. at least a day passed since then it's gonna check again. Simple and elegant, and if it can't check it can throw a DEBUG or INFO message. Additionally we can utilise concurrency to not slow things down: so a new thread would be spawned on startup that would run concurrent to the normal code and then right before abra exits it could print the last line like: `INFO: there is a new abra version available. To install it run abra upgrade` and then we can also have another file like ~/.abra/.newversion that will store this info and if this file exists abra will always show this information and won't even run the code to check for a new version.

knoflook added this to the (deleted) milestone 2021-10-19 09:15:22 +00:00

knoflook added the enhancement abra labels 2021-10-19 09:15:22 +00:00

knoflook added this to the Spicing abra up project 2021-10-19 09:22:09 +00:00

decentral1se commented

2021-10-19 09:59:58 +00:00

Ah great you brought this up!

I like this proposal for the CI UI/UX!

Some more points for consideration...

abra app ls -S shows if there are updates available right now also but bear in mind, it checks the catalogue, not the upstream image hub! So there are two sources of upgrades here:

hub upstream (important for recipe maintainers, time to test + publish!)
catalogue (important for hosters, time to upgrade!)

Some prior art from Cloudron on upgrades in general which we discussed before:

Cloudron has a daemon running on the host which is polling every x minutes for upgrades and then sending an email that an upgrade can be done.
Cloudron does auto upgrades on minor and/or patch releases and sends a mail when they're done.

I wonder would having a small separate golang program which uses abra as a library and sits on the server and polls running applications. This might also feed into having our own monitoring also! Cloudron also mails if your app gets killed because of an OOM error, then you would get a mail? This might be a separate thing tho.

In any case, any progress here would be great!

Ah great you brought this up! I like this proposal for the CI UI/UX! Some more points for consideration... `abra app ls -S` shows if there are updates available right now also but bear in mind, it checks the catalogue, not the upstream image hub! So there are two sources of upgrades here: 1. hub upstream (important for recipe maintainers, time to test + publish!) 2. catalogue (important for hosters, time to upgrade!) Some prior art from Cloudron on upgrades in general which we discussed before: - Cloudron has a daemon running on the host which is polling every x minutes for upgrades and then sending an email that an upgrade can be done. - Cloudron does auto upgrades on minor and/or patch releases and sends a mail when they're done. I wonder would having a small separate golang program which uses `abra` as a library and sits on the server and polls running applications. This might also feed into having our own monitoring also! Cloudron also mails if your app gets killed because of an OOM error, then you would get a mail? This might be a separate thing tho. In any case, any progress here would be great!

knoflook modified the milestone from (deleted) to (deleted)

2021-10-19 10:36:45 +00:00

knoflook commented

2021-10-19 10:42:19 +00:00

abra app ls -S shows if there are updates available right now also but bear in mind, it checks the catalogue, not the upstream image hub! So there are two sources of upgrades here

i was actually thinking about updates to abra itself, sorry forgot to put it in the issue 😆

I wonder would having a small separate golang program which uses abra as a library and sits on the server and polls running applications. This might also feed into having our own monitoring also! Cloudron also mails if your app gets killed because of an OOM error, then you would get a mail? This might be a separate thing tho.

making a daemon that automatically checks the upgrades for your apps is in my opinion way better than integrating this option into abra, as it will be a substantial amount of code that will introduce new bugs, and require maintaining. If it turns out to not be useful it's easier to just deprecate another project than to remove the code from the app itself. We could also use existing programs for that like grafana.

Sorry if this is incoherent my mind is all over the place 😆 let me know if you need any clarification

> abra app ls -S shows if there are updates available right now also but bear in mind, it checks the catalogue, not the upstream image hub! So there are two sources of upgrades here i was actually thinking about updates to abra itself, sorry forgot to put it in the issue 😆 > I wonder would having a small separate golang program which uses abra as a library and sits on the server and polls running applications. This might also feed into having our own monitoring also! Cloudron also mails if your app gets killed because of an OOM error, then you would get a mail? This might be a separate thing tho. making a daemon that automatically checks the upgrades for your apps is in my opinion way better than integrating this option into abra, as it will be a substantial amount of code that will introduce new bugs, and require maintaining. If it turns out to not be useful it's easier to just deprecate another project than to remove the code from the app itself. We could also use existing programs for that like grafana. Sorry if this is incoherent my mind is all over the place 😆 let me know if you need any clarification

decentral1se commented

2021-11-05 09:23:11 +00:00

All good :) Made coop-cloud/organising#236 for the general auto-update discussion for apps.

All good :) Made https://git.coopcloud.tech/coop-cloud/organising/issues/236 for the general auto-update discussion for apps.

decentral1se referenced this issue

2021-11-05 09:23:26 +00:00

Automatic patch/security updates for deployed apps #236

moritz closed this issue

2023-03-22 12:21:12 +00:00

decentral1se commented

2023-03-24 08:11:54 +00:00

Ah, this ticket was originally about having abra tell users if there is a new version of abra itself available! It just got confusing in the discussion and went off-topic. abra still can't do this 😄

Ah, this ticket was originally about having `abra` tell users if there is a new version of `abra` itself available! It just got confusing in the discussion and went off-topic. `abra` still can't do this 😄

decentral1se reopened this issue

2023-03-24 08:11:56 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#208