Make app rollbacks more robust #107

New Issue

decentral1se · 2021-03-18T10:46:41Z

decentral1se commented

2021-03-18 10:46:41 +00:00

Just had to rollback gitea and it was quite a manual process. We could improve here and I think that ties into coop-cloud/organising#48 and the specific question of "what happens when something goes wrong".

We have abra app <app> rollback <service> but this doesn't always mean that it will roll back to a previous version! Maybe you deployed the same version twice (.e.g re-applying labels) and the rollback only switches back to the previous container that has other labels.

Currently we only keep the current version + digest in the abra.sh so it is not possible to know what is actual previous tag and digest as we are doing it all manually now.

I think if coop-cloud/organising#51 is successful then we could consider reading having abra itself read the RSS, get the tags, calculate the digests and then understand what versions are available and what can be done. This would reduce workload for the packaging side of things and make version handling more robust on the abra side of things.

It would be great to extend then our rollback command. Something like:

abra app <app> rollback [--version=<version>] [--list-versions]

Just had to rollback `gitea` and it was quite a manual process. We could improve here and I think that ties into https://git.autonomic.zone/coop-cloud/organising/issues/48 and the specific question of "what happens when something goes wrong". We have `abra app <app> rollback <service>` but this doesn't always mean that it will roll back to a previous version! Maybe you deployed the same version twice (.e.g re-applying labels) and the rollback only switches back to the previous container that has other labels. Currently we only keep the current version + digest in the `abra.sh` so it is not possible to know what is actual previous tag and digest as we are doing it all manually now. I think if https://git.autonomic.zone/coop-cloud/organising/issues/51 is successful then we could consider reading having `abra` itself read the RSS, get the tags, calculate the digests and then understand what versions are available and what can be done. This would reduce workload for the packaging side of things and make version handling more robust on the `abra` side of things. It would be great to extend then our `rollback` command. Something like: > `abra app <app> rollback [--version=<version>] [--list-versions]`

👍 1

decentral1se added this to the Beta release milestone 2021-03-18 10:46:41 +00:00

decentral1se added the

enhancement

label 2021-03-18 10:46:41 +00:00

decentral1se referenced this issue

2021-03-18 10:49:32 +00:00

Add abra app ls --status to show if app requires an update or not #102

decentral1se referenced this issue

2021-03-18 11:24:49 +00:00

Add a specific app version check command #108

decentral1se referenced this issue from coop-cloud/organising

2021-03-19 11:16:56 +00:00

How to collect app image version/digests that abra can easily read? #51

decentral1se referenced this issue

2021-03-20 21:39:47 +00:00

Make app deploys more robust #113

decentral1se commented

2021-04-02 19:08:55 +00:00

See #113 (comment).

See https://git.autonomic.zone/coop-cloud/abra/issues/113#issuecomment-4746.

3wordchant commented

2021-04-05 11:08:19 +00:00

Think this might now be addressed by #135:

$ abra app foobar deploy
# Deploys latest version, e.g. v3
$ abra app foobar rollback
# Rolls back to previous version, e.g. v2
$ abra app (deploy|rollback) v1
# Rolls back to a specific version

One question I have is whether deploy --upgrade should enforce that it's actually an upgrade, and rollback should enforce that it's actually a downgrade? If we can rely on the order of versions in abra-apps.json then that might not be too tricky, but beware some apps like filestash which use non-sequential UIDs for their versions 🤦

Think this might now be addressed by #135: ``` $ abra app foobar deploy # Deploys latest version, e.g. v3 $ abra app foobar rollback # Rolls back to previous version, e.g. v2 $ abra app (deploy|rollback) v1 # Rolls back to a specific version ``` One question I have is whether `deploy --upgrade` should enforce that it's actually an upgrade, and `rollback` should enforce that it's actually a downgrade? If we can rely on the order of versions in `abra-apps.json` then that might not be too tricky, but beware some apps like `filestash` which use non-sequential UIDs for their versions 🤦

decentral1se commented

2021-04-05 13:43:04 +00:00

If we can rely on the order of versions in abra-apps.json then that might not be too tricky, but beware some apps like filestash which use non-sequential UIDs for their versions 🤦

😱 😱 😱

Wow good catch. Should we just nip that in the bud now and change the data structure of the versions to have a key that is a sortable value that we control? Perhaps a date string? An integer? Not sure.

> If we can rely on the order of versions in abra-apps.json then that might not be too tricky, but beware some apps like filestash which use non-sequential UIDs for their versions 🤦 😱 😱 😱 Wow good catch. Should we just nip that in the bud now and change the data structure of the versions to have a key that is a sortable value that we control? Perhaps a date string? An integer? Not sure.

decentral1se commented

2021-04-05 13:46:30 +00:00

Do we even need --upgrade now? Maybe let's discuss this once all the stuff is merged and we can think through some consolidation of the CLI.

Do we even need `--upgrade` now? Maybe let's discuss this once all the stuff is merged and we can think through some consolidation of the CLI.

3wordchant referenced this issue

2021-04-05 14:24:41 +00:00

Reconsidering `deploy --update` / `rollback` #137

3wordchant commented

2021-04-05 14:24:54 +00:00

Wow good catch. Should we just nip that in the bud now and change the data structure of the versions to have a key that is a sortable value that we control? Perhaps a date string? An integer? Not sure.

AFAIK JSON lists preserve ordering, so as long as we take care to add new versions to the end of the versions list then I think we're OK - and it'd be really nice to avoid introducing an extra layer of versioning. Maybe this is an area where we can try and help upstreams?

Do we even need --upgrade now?

See #137

> Wow good catch. Should we just nip that in the bud now and change the data structure of the versions to have a key that is a sortable value that we control? Perhaps a date string? An integer? Not sure. AFAIK JSON lists preserve ordering, so as long as we take care to add new versions to the end of the `versions` list then I think we're OK - and it'd be _really_ nice to avoid introducing an extra layer of versioning. Maybe this is an area where we can try and help upstreams? > Do we even need `--upgrade` now? See #137

decentral1se commented

2021-04-05 15:54:03 +00:00

AFAIK JSON lists preserve ordering, so as long as we take care to add new versions to the end of the versions list then I think we're OK - and it'd be really nice to avoid introducing an extra layer of versioning

OK, agreed! So, we rely on app-json.py then to guarantee our ordering. I'll keep this in mind and hopefully we don't run into issues. Should be fine 🙏

> AFAIK JSON lists preserve ordering, so as long as we take care to add new versions to the end of the versions list then I think we're OK - and it'd be really nice to avoid introducing an extra layer of versioning OK, agreed! So, we rely on `app-json.py` then to guarantee our ordering. I'll keep this in mind and hopefully we don't run into issues. Should be fine 🙏

decentral1se commented

2021-04-05 20:01:30 +00:00

See you all in #137.

See you all in https://git.autonomic.zone/coop-cloud/abra/issues/137.

decentral1se closed this issue

2021-04-05 20:01:30 +00:00

This repo is archived. You cannot comment on issues.