Re: [Chipster-tech] [Extern] - Chipster v4.7.2 and tagged container images

[Chipster <chi...@cs...>]

Hi Oli,

answers below:

> On 25. Aug 2023, at 14.46, Oliver Heil <o....@dk...> wrote:
> 1)
> 
>> image:
>>   tag: v4.7.2
> 
> to ~/values.yaml
> Should this be removed after successful update again? Or should it stay there?


It should stay there. It configures the containers to use images like "docker-registry.rahti.csc.fi/chipster-images-release/web-server:v4.7.2", which makes 
sure that only this specific version is used until you decide to change it.

> 2)
> There seem to be 3 remnants from the old version (top 3 of below list):
> 
>> Every 2.0s: kubectl get pod
>> 
>> NAME                                READY   STATUS                   RESTARTS       AGE
>> type-service-7ff4944dd6-zzdrl       0/1     ContainerStatusUnknown   7 (33m ago)    21d
>> toolbox-86f7994cf9-wl6lc            0/1     Error                    12 (33m ago)   129d
>> backup-77c55fc4df-7ccl4             0/1     Error                    11             129d
> 
> 
> Is there something left to do with them?

I don't know why K3s haven't removed those. You could try remove them yourself:

kubectl delete pod type-service-7ff4944dd6-zzdrl

And so on. However, I don't think those containers really exist anymore, so those shouldn't cause any harm apart from making your listing uglier.

> Some further suggestions:
> 1) You linked to the #updates tag in the k3s/README.md document. For the new images one needs to jump
> ahead/up in the same document following the link in "If there is a newer Chipster container image version available",
> which is somehow confusing. My suggestion is: there should be a single "UPDATE" document which can be
> followed from top to down. The only jumps in there should be when skipping something not necessary and the
> jump should never be ahead/up but always downwards.

I tried to make it easy for the first time installers to specify the container image version, but I admit that end result wasn't very clear for the updates. I have now merged the two chapters.

> 2) It isn't clear in which folder the update procedure has to be started. Where should I be, when I do the first
> step "git pull" ? Actually it is "~/git/chipster-openshift/k3s", I always have to explore it again, because last time
> I had to is months ago.

Added there. It's definitely a good place to mention it, because you hopefully are able to update the Chipster server much more often than you have to reinstall it (where it's only mentioned now).

> 3) Add something about updating the Ubuntu system to the Update-Document. Currently we run 
> Ubuntu 20.04.6 LTS on the chipster server. A 'do-release-upgrade' is shown at login, of course
> I hesitate to do this. Some information would be nice, if chipster is still considerung Ubuntu 20.04 as
> best operating system or if it is already safe to upgrade to a newer version. 

Ubuntu releases long term support (LTS) versions every two years, e.g. 20.04, 22.04 and 24.04. Each version receives updates for five years. Our plan is to minimize the migration work by skipping every other LTS release. So we are using 20.04 for now and plan to migrate to 24.04 after it's released in April 2024 and before the 20.04 end of life in April 2025. I added a few words to the update instructions about this.

> 4) Can I see any version information in the chipster webgui? Like, if a user wants to see the
> current version(s) of the system? I did a brief search for it and didn't found anything. It isn't
> that much important but somehow some kind of software standard, to expose version information
> to the user. I think there are several versions (chipster, chipster-tools,...) to be shown somewhere.

You are right, the version information isn't really available for the end-users at the moment like it should be. We would have to build some kind of automatic system to take the version information from git and incorporate it in the container images. Then the web app could show its own version and perhaps query to backend versions from the Rest APIs. I think the latest change in container image versioning forces us to be more stringent about release versioning, which could be a good stepping stone into that direction. I wrote this down on our backlog and let's hope we can improve it at some point.

Thanks for the comments! Let's hope the instructions are now a bit easier to follow.

Best regards,
Petri