-
-
Notifications
You must be signed in to change notification settings - Fork 268
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
Adopt deb822_repository
format.
#153
base: master
Are you sure you want to change the base?
Conversation
7th time's a charm 🙂 |
@geerlingguy @rhino5oh made some tweaks here that have it passing tests. Not sure about the code style; I try to run apt cache updates at the playbook level as handlers, etc but it seems like it might be necessary here when the repository is added, because tests were failing otherwise. Might be a deficiency in my Ansible-fu tho. EDIT: Ah, I see; |
Thanks, Works for me! |
This pr has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution! Please read this blog post to see the reasons why I mark issues as stale. |
This isn't tested, since I'm using a custom role locally, but it's a lightly edited (for code style) version of what I'm doing.
Unfortunately, this whole transition seems to be quite messy and may require some manual work to clear out old keys, old sources, etc if this is rerun on a cluster with the previous system in place.
To go into more detail about why this can require cleanup, the previous approach would create e.g.
/etc/apt/sources.list.d/kubernetes.list
. This creates/etc/apt/sources.list.d/kubernes.source
, so there can be two files pointing to sources for the Kubernetes packages. This also adds the new key in a different location, so there can be multiple keys.The problem I encountered while fighting with this and iterating while targeting a cluster was that I'd get errors like "403 forbidden" when attempting to update the apt cache. That would occur when I was using the wrong
suite
orcomponents
arguments, since converting from the old to the new format is IMHO kinda poorly documented.Then, once I got that sorted out, I had problems where my control plane was on 1.29.2 and my workers were on 1.28.2. This happened because I was working on bootstrapping my control plane (high availability, which is why I didn't use this role) and ended up iterating more on that, while my workers had received less attention. Turns out, I still had those apt-marked to pin the versions.
A sadder man, but wiser now, I open this PR for you.