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

Make the .lock file cross the Read-Modify-Write #28197

Closed
wants to merge 1 commit into from

Conversation

cjcullen
Copy link
Member

Should help prevent concurrent calls to ModifyConfig (with one field changed) from producing an invalid kubeconfig.

We should still eventually rework this to give some stronger semantics around kubeconfig file modification.

@cjcullen
Copy link
Member Author

@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note-label-needed labels Jun 29, 2016
@k8s-bot
Copy link

k8s-bot commented Jun 29, 2016

GCE e2e build/test passed for commit 6495d12.

@deads2k
Copy link
Contributor

deads2k commented Jun 29, 2016

Why not lock the entire ModifyConfig to ensure a coherent view of the data? It's likely to modify multiple elements anyway?

@krousey
Copy link
Contributor

krousey commented Jun 29, 2016

@cjcullen I agree with @deads2k. We should have a lock (or set of locks in this weird multi-config file setup that we seem to support) that we hold for the entirety of the read/modify/write cycle.

@cjcullen
Copy link
Member Author

cjcullen commented Jun 29, 2016

That's tough in this possibly multi-file setup. Could I call configAccess.GetLoadingPrecedence() and "lock" all of the files before I do anything?

@krousey
Copy link
Contributor

krousey commented Jun 29, 2016

@cjcullen That might be best for now. You also might want to make sure the directory exists before creating the lock file.

@deads2k Do we really need this multi-file setup?

@deads2k
Copy link
Contributor

deads2k commented Jun 29, 2016

@deads2k Do we really need this multi-file setup?

It only exists to support merging kubeconfig files together using an env var, but that was a usage that @ghodss pushed rather hard for. I don't want remove it without a very good reason.

@krousey
Copy link
Contributor

krousey commented Jun 29, 2016

I think for the short term, we want a lock file per config file held across the entirety of ModifyConfig.

Long term, I'd like to question the usefulness of having multiple config files.

@deads2k Given how complicated this code looks, I wouldn't want to keep it without a very good reason. I'm probably just not aware of the use-cases, but I'd like to be enlightened.

@deads2k
Copy link
Contributor

deads2k commented Jun 29, 2016

@deads2k Given how complicated this code looks, I wouldn't want to keep it without a very good reason. I'm probably just not aware of the use-cases, but I'd like to be enlightened.

I'm not aware of anyone using it besides @ghodss . @smarterclayton or @bgrant0607 have you see anyone else use multiple kubeconfig files in an env var for merging?

@ghodss
Copy link
Contributor

ghodss commented Jun 29, 2016

Here are the issues/use cases for multiple config files - though I'm not sure if this refers to any possibility of multiple files in ~/.kube/, or multiple files spread throughout the file system that get merged together.

Multiple files in ~/.kube, like ~/.kube/config and ~/.kube/kubectl: #10693
Multiple .kubeconfig files getting merged: #9298

@cjcullen
Copy link
Member Author

Closing in favor of #28232.

@cjcullen
Copy link
Member Author

Opened #28260 to continue the general refactoring discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants