MicroOS version freezing <-> Kube-Hetzner tags

[valkenburg-prevue-ch]

As per this issue #623 and its fix, 74d1a60 , I think we should try to find a way to make explicit which version of MicroOS is tied to which release of kube-hetzner. Right now this is undocumented, and the only relatively certain way is to "check out all the latest today", i.e. the latest kube-hetzner release and the latest microos image.

That is not really safe, right?

I do now know what the way out it is, but I'm hoping to open a discussion about this.

[valkenburg-prevue-ch]

@mysticaltech @aleksasiriski Let's take this here. Replying to #623 (comment) ,

it's actually the second time in three months.

#555
[EDIT: should have been https://github.com//issues/528 ]
#623

[mysticaltech]

I understand, no worries. There's no version to my knowledge it's a rolling release, so we always get the latest and greatest. Normally, we should be quite stable from now on from the OS side of things, as we do not use anything special, just the basics.

[valkenburg-prevue-ch]

But the fact that it is unversioned goes against the standards of fully testing updates before you deploy them. Does the creator address that in the video? (Will watch later).

[mysticaltech]

But that's the point, it's designed to remove that requirement for stability. (If I remember well, he makes this fact pretty clear in his explanation).

[valkenburg-prevue-ch]

Well, he goes a great length to explain why updates should be atomic and offer the possibility to rollback. Which is how microos works once installed, and I love that part. But the way we use it, downloading the latest image in realtime, is the opposite of that. Nothing is atomic, nothing can be rolled back. Installing the exact same code base today and tomorrow may have a very different outcome. That makes me and I can imagine many users a bit scared. For me, I'm good, I host a fixed image on a private server, so I can in fact roll back. But the kube-hetzner project publicly cannot.

[mysticaltech]

I know that @ifeulner does that too. It's fine and that's what the URL param is for, people can choose whatever mirror they want, even their own. Personally, I like to stick with the latest and greatest, and I am sure enough that it won't break (and would be curious if it did break to make sure to make it more robust, but it almost never happens).

That said, with the upcoming release, we will work via an initial snapshot, so unless you delete and recreate the snapshot, you will have the assurance you seek for the users, for the life of the cluster! 🚀🚀

[mysticaltech]

Upcoming LeapMicro will solve those worries.