Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

store things following XDG standards #102

Merged
merged 4 commits into from
Oct 16, 2023

Conversation

laverya
Copy link
Member

@laverya laverya commented Oct 12, 2023

@laverya
Copy link
Member Author

laverya commented Oct 12, 2023

I need to rework this again to use XDG_DATA_HOME/XDG_STATE_HOME as appropriate

bag of worms here

@laverya laverya merged commit 5125340 into main Oct 16, 2023
16 checks passed
@laverya laverya deleted the laverya/sc-88127/use-xdg-variables branch October 16, 2023 16:07
emosbaugh pushed a commit that referenced this pull request Aug 26, 2024
when deciding to start or not an upgrade we should take into account
what is the current embedded cluster we are running on. without this
fix we end up starting a cluster upgrade when it is not necessary.

we were using the kubernetes version (as in `kubectl version`) to
determine if an upgrade was necessary or not. it turns out that when
installed with k0s version v1.29.1+k0s.1 the kubernetes version reported
is v1.29.1+k0s (notice the missing .1 at the end). because of this the
running verion was never equal to the desired version (v1.29.1+k0s.1 !=
v1.29.1+k0s).

now we take into account the actual embedded cluster version. we do so
through an environment variable. this environment variable will change
only when the new operator deployment takes place (add-on upgrade) and
at that stage the kubernetes has already been upgraded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants