Release logic doesn't understand difference between app/$other container updates #159

New Issue

decentral1se · 2021-05-03T07:49:34Z

decentral1se commented

2021-05-03 07:49:34 +00:00

Following coop-cloud/portainer#5, I am running abra recipe portainer release which results in the following diff:

diff --git a/compose.yml b/compose.yml
index 66a4f2e..7f53776 100644
--- a/compose.yml
+++ b/compose.yml
@@ -28,7 +28,7 @@ services:
         - "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect"
         - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true"
         - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}"
-        - coop-cloud.${STACK_NAME}.app.version=1.23.2-4ae7f143
+        - coop-cloud.${STACK_NAME}.app.version=1.24.2-fb45b437
   agent:
     image: portainer/agent:2.4.0
     volumes:
@@ -43,7 +43,7 @@ services:
       placement:
         constraints:
           - node.role == manager
-      labels: ['coop-cloud.${STACK_NAME}.agent.version=2.1.0-397d3dea']
+      labels: ['coop-cloud.${STACK_NAME}.agent.version=2.4.0-d8a9a032']
 volumes:
   portainer_data:
 networks:

We've fallen behind here on updating because there is an app update and and underyling service update for the agent container. In this case, abra says that the new version should be 1.24.2 but should it not be 1.24.2_1?

This one is a bit tricky.

Maybe we need a --app (or whatever) flag to tell the release command that we only care about this app container and not the agent one and we manually order the updates? We could then have a --underlying (or whatever) to tell it to only do upgrade logic on the underling services?

Following https://git.autonomic.zone/coop-cloud/portainer/pulls/5, I am running `abra recipe portainer release` which results in the following diff: ```diff diff --git a/compose.yml b/compose.yml index 66a4f2e..7f53776 100644 --- a/compose.yml +++ b/compose.yml @@ -28,7 +28,7 @@ services: - "traefik.http.routers.${STACK_NAME}.middlewares=${STACK_NAME}-redirect" - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLForceHost=true" - "traefik.http.middlewares.${STACK_NAME}-redirect.headers.SSLHost=${DOMAIN}" - - coop-cloud.${STACK_NAME}.app.version=1.23.2-4ae7f143 + - coop-cloud.${STACK_NAME}.app.version=1.24.2-fb45b437 agent: image: portainer/agent:2.4.0 volumes: @@ -43,7 +43,7 @@ services: placement: constraints: - node.role == manager - labels: ['coop-cloud.${STACK_NAME}.agent.version=2.1.0-397d3dea'] + labels: ['coop-cloud.${STACK_NAME}.agent.version=2.4.0-d8a9a032'] volumes: portainer_data: networks: ``` We've fallen behind here on updating because there is an `app` update *and* and underyling service update for the `agent` container. In this case, `abra` says that the new version should be `1.24.2` but should it not be `1.24.2_1`? This one is a bit tricky. Maybe we need a `--app` (or whatever) flag to tell the `release` command that we only care about this `app` container and not the `agent` one and we manually order the updates? We could then have a `--underlying` (or whatever) to tell it to only do upgrade logic on the underling services?

decentral1se added this to the Beta release milestone 2021-05-03 07:49:34 +00:00

decentral1se added the

bug

versioning

labels 2021-05-03 07:49:34 +00:00

3wordchant referenced this issue

2021-05-04 07:24:16 +00:00

Nextcloud release not being picked up as a n+1 version #158

3wordchant commented

2021-05-04 07:41:11 +00:00

I think we have different ideas about how the versioning should work, yours is probably right, but let me lay out mine so we're choosing between them from a position of Maximum Information.

To me, 1.24.2 means "the first recipe involving portainer/portainer:1.24.2 that we publish", and 1.24.2_1 means "the second recipe involving portainer/portainer:1.24.2 that we publish", by definition updating anything except the version of portainer/portainer.

This means that if we update > 1 image in a release, the increment will be determined by the overall changes. Assuming we have a foo recipe with 3 services, starting at example/image:0.0.1 (app), example/image2:1.2.3 (db) and example/image3:4.5.6 (cache), and upgrading to:

image:0.0.2, image2:1.2.4, image3:4.5.7 → 0.0.2 (i.e. ignore the fact there were updates to other services beyond the main one)
image:0.0.1 (unchanged), image2:1.2.4, image3:4.5.7 → 0.0.1_1 (i.e. only increment by one even though two non-main services have changed)

In other words, to me, version 1.24.2 of our Portainer recipe doesn't mean "a recipe where the ingredients are portainer/portainer:1.24.2, plus the oldest version of portainer/agent that we know about -- it means "the first version of our Portainer recipe that features portainer/portainer:1.24.2".

I guess this comes back to the question of how much intervention we're making as recipe maintainers: if the answer is "none" then I definitely see the case for making sure we make tags for all reasonable combinations of image versions, to make sure folks can easily switch between them -- but if we're moving towards "each released recipe version is a (somewhat) tested (somewhat) recommended combination of images then the calculus between extra complexity in sub_recipe_release & extra noise in abra recipe foo versions vs offering a more limited set of version combinations seems to lean in the other direction.

I think we have different ideas about how the versioning should work, yours is probably right, but let me lay out mine so we're choosing between them from a position of Maximum Information. To me, `1.24.2` means "the first recipe involving `portainer/portainer:1.24.2` that we publish", and `1.24.2_1` means "the second recipe involving `portainer/portainer:1.24.2` that we publish", by definition updating anything except the version of `portainer/portainer`. This means that if we update > 1 image in a release, the increment will be determined by the overall changes. Assuming we have a `foo` recipe with 3 services, starting at `example/image:0.0.1` (`app`), `example/image2:1.2.3` (`db`) and `example/image3:4.5.6` (`cache`), and upgrading to: - `image:0.0.2`, `image2:1.2.4`, `image3:4.5.7` → `0.0.2` (i.e. ignore the fact there were updates to other services beyond the main one) - `image:0.0.1` (unchanged), `image2:1.2.4`, `image3:4.5.7` → `0.0.1_1` (i.e. only increment by one even though two non-main services have changed) In other words, to me, version `1.24.2` of our Portainer recipe doesn't mean "a recipe where the ingredients are `portainer/portainer:1.24.2`, plus the oldest version of `portainer/agent` that we know about -- it means "the first version of our Portainer recipe that features `portainer/portainer:1.24.2`". I guess this comes back to the question of how much intervention we're making as recipe maintainers: if the answer is "none" then I definitely see the case for making sure we make tags for all reasonable combinations of image versions, to make sure folks can easily switch between them -- but if we're moving towards "each released recipe version is a (somewhat) tested (somewhat) recommended combination of images then the calculus between extra complexity in `sub_recipe_release` & extra noise in `abra recipe foo versions` vs offering a more limited set of version combinations seems to lean in the other direction.

👀 1

decentral1se commented

2021-05-04 17:35:05 +00:00

Oh yeah, I like what you're proposing! Now that I re-read this, I'm definitely leaning more towards new versioning semantics (A New Versioning System TM) which was specifically what we said we wouldn't be doing. Down to just document what we discussing here on version handling. I also think if we can do some diffing / change log / git commit showing via abra commands on deploy or some other way, this will mitigate my concerns. I just it to be easy to know what is coming in the update. My semver.org training means I look for that exclusively in the version itself but it doesn't have to be that way. Arguably semver isn't that great anyway because $lots_of_reasons.

Oh yeah, I like what you're proposing! Now that I re-read this, I'm definitely leaning more towards new versioning semantics (A New Versioning System TM) which was specifically what we said we wouldn't be doing. Down to just document what we discussing here on version handling. I also think if we can do some diffing / change log / git commit showing via `abra` commands on deploy or some other way, this will mitigate my concerns. I just it to be easy to know what is coming in the update. My semver.org training means I look for that exclusively in the version itself but it doesn't have to be that way. Arguably semver isn't that great anyway because `$lots_of_reasons`.

decentral1se added

documentation

and removed

bug

labels 2021-05-04 17:35:29 +00:00

3wordchant referenced this issue from a commit

2021-05-30 19:22:17 +00:00

Add more about versioning

3wordchant closed this issue

2021-05-30 19:22:17 +00:00

This repo is archived. You cannot comment on issues.