release: 0.7.0-alpha.2

[diegodelemos]

No description provided.

[tiborsimko]

When updating this PR, you can edit NOTES.txt to put mysecretpassword back where mypass1234 now is... I had shortened it to fit 80 columns, but the formatting now allows the original value mysecretpassword that we also use elsewhere... so I think we can put it back.

[mvidalgarcia]

I see the tag is called 0.7.0a2 instead of 0.7.0-alpha.2, is this correct? Looks wrong to me.

[tiborsimko]

Git tag is following Python versioning conventions (PEP0440), hence 0.7.0a2. The produced Docker image is following semantic versioning conventions, hence 0.7.0-alpha.2. The correspondence is handled by reana-dev...

[diegodelemos]

Actually, what Marco points to is the Docker tag (see here) which is wrongly following PEP440. Did you release "manually" or did you use reana-dev? if so we might have a bug around here?

reana/reana/reana_dev/release.py

Lines 119 to 120 in e0a29b6

	if parse_pep440_version(current_tag):
	docker_tag = translate_pep440_to_semver2(current_tag)

I've recently released RJC using reana-dev and it correctly got the semver version...

[tiborsimko]

Fixed.

Hmm, it looks like it must have been manual, but I don't seem to have any entrance at all about tagging 0.7.0a2 in my shell history... Moreover alpha.1 was released well before... So I don't recall what happened. Let's see next time.

[tiborsimko]

... ah, I might know how it happened:

$ cd reana-server
$ git checkout maint-0.7
$ reana-dev docker-build -c . -t auto
reana-dev docker-build -c . -t auto
[2020-09-25T16:13:46] reana-server: git describe --tags
[2020-09-25T16:13:46] reana-server: docker build -t reanahub/reana-server:0.7.0a3 .
^C
Aborted!

I must have used -t auto probably... I'll create an issue.

[tiborsimko]

I have tested various combinations of specifying release namespace and release name, and pushed some fixes so that printed instructions would be copy-paste-able to work out of the box.

I have also amended scripts/create-admin-user.sh and friends accordingly.

However, some observations: when using

$ helm install helm/reana --wait --generate-name
NAME: reana-1601457612
...

The things don't work, because the pods are created like this:

$ kubectl get pods
NAME                                                 READY   STATUS    RESTARTS   AGE
reana-1601457-cache-57ccbd4644-jgfcw                 1/1     Running   0          72s
reana-1601457-db-5f5cdd4d85-xjtcz                    1/1     Running   0          72s
reana-1601457-message-broker-96f547668-77x8p         1/1     Running   0          72s
reana-1601457-server-555589bdfd-c7hg7                2/2     Running   0          72s
reana-1601457-ui-675dd98f65-m6xkr                    1/1     Running   0          72s
reana-1601457-workflow-controller-78b67dd89b-2bnhs   2/2     Running   0          72s
reana-1601457612-traefik-7cf64f9d88-rhrnz            1/1     Running   0          72s

Note that only traefik respects the generated name; the others are "cut".

(2) Using a name like "reana", "myreana" or "reanadev" works well, but using a name like "xyzzy" generates troubles too, as "-reana" is being appended to infrastructure pods:

$ kubectl get pods
NAME                                               READY   STATUS    RESTARTS   AGE
xyzzy-reana-cache-567465756b-kgmsv                 1/1     Running   0          119s
xyzzy-reana-db-5c5879d79f-n6ff9                    1/1     Running   0          119s
xyzzy-reana-message-broker-55bc649d74-8nbdw        1/1     Running   0          119s
xyzzy-reana-server-669cf6b988-x7lw7                2/2     Running   0          119s
xyzzy-reana-ui-8669c86f5f-pf5tg                    1/1     Running   0          119s
xyzzy-reana-workflow-controller-7998dff758-kh94h   2/2     Running   0          119s
xyzzy-traefik-687fb5c4c9-rd296                     1/1     Running   0          119s

[tiborsimko]

... to be compared to "good" situations like:

$ kubectl get pods
NAME                                            READY   STATUS    RESTARTS   AGE
reananew-cache-5759888787-l4v9h                 1/1     Running   0          19m
reananew-db-79f7bfdb5d-lb9d5                    1/1     Running   0          19m
reananew-message-broker-5759645bdc-xln8h        1/1     Running   0          19m
reananew-server-565874b4b7-s58jb                2/2     Running   0          19m
reananew-traefik-747ff4b6df-2mgf7               1/1     Running   0          19m
reananew-ui-5dbc478766-bpwdx                    1/1     Running   0          19m
reananew-workflow-controller-6785d47659-rnbsq   2/2     Running   0          19m

The only thing in the helm install ... command that changed was the wanted name.

[diegodelemos]

Note that only traefik respects the generated name; the others are "cut".

We had to truncate the name because of this. The solution here would be changing the prefix for dependencies, to use the same as REANA, working on it.

(2) Using a name like "reana", "myreana" or "reanadev" works well, but using a name like "xyzzy" generates troubles too, as "-reana" is being appended to infrastructure pods:

This was a conscious decision in the past: if the application name is not contained in the name chosen by the user, the -reana- suffix is added. If we are ok with xyz as valid component prefix (e.g. xyz-cache-5759888787-l4v9h) I can remove the suffix logic.

[tiborsimko]

Some thoughts on this:

• Let's not do too deep code changes in the alpha release times indeed... So:

  • if we need to truncate names (yeah, sha1s can be loooong), then let's document that people should use release names shorter than N characters. (I mean document somewhere visibly in docs.reana.io.)

  • Ideally, when people would do helm install myverylongnamethatcannnotbeused ..., it would be perfect if helm replied "Sorry cannot use such a long name" if there was ever a way?!

• Requiring "reana-" prefix might be understandable, but "contains" seems a bit arbitrary, giving people choice append? prepend? I'd say if we don't need reana, then let's remove it, and allow users to use whatever they think fit. Somebody might want to name their reana instance in non-reana way, after all.

[diegodelemos]

if we need to truncate names (yeah, sha1s can be loooong), then let's document that people should use release names shorter than N characters. (I mean document somewhere visibly in docs.reana.io.)

Added in reanahub/docs.reana.io#62. As a long term solution we could look at relying on labels to store the UUID and component_type (see our component naming scheme). We already use labels to store the workflow run mode so it should be easy.

Ideally, when people would do helm install myverylongnamethatcannnotbeused ..., it would be perfect if helm replied "Sorry cannot use such a long name" if there was ever a way?!

I couldn't find a way of doing this.

but "contains" seems a bit arbitrary, giving people choice append? prepend?

Fixed. Just to give some background on this; the "contains" approach is used by most of Helm based projects (see here) that's the reason we went for it.