-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[WIP] ✨Add support for defining KubeadmConfig files by reference (ConfigMap & Secret) #1860
Conversation
- Add field: KubeadmConfig.spec.files[].contentFrom - Resolve ConfigMap and Secret references in kubeadm controller - Add cloudinit.File type to avoid passing misleading API-type parameters (.ContentFrom) into cloudinit generation funcs - Update BootstrapData test to parse yaml and assert on file existance - Add "sigs.k8s.io/yaml" dependency
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Welcome @nstogner! |
Hi @nstogner. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: nstogner The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Looks like I need to get my company email associated with the CLA. |
|
||
// ContentFrom indicates the content for the file should be retrieved from a referenced resource. Mutually exclusive with Content. | ||
// +optional | ||
ContentFrom *FileContentSource `json:"contentFrom,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to move this up a level? Instead of requiring one secret or configmap per file, leverage the structure of secrets and configmaps to allow a user to import multiple files from a single configmap or secret?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would mean we'd have files
for inline, and filesFrom
(?) for content from confimaps/secrets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would mean we'd have files for inline, and filesFrom (?) for content from confimaps/secrets?
Possibly... There is also the issue of the additional metadata that is included in the individual file types as well. It just feels quite a bit heavy weight to force one secret/configmap per file, when these resources are intended to provide multiple files by design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, in light of this, I think we probably should spend some more time data modeling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps it makes sense to copy the same pattern that pod volumes use:
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#configmapvolumesource-v1-core
Allow for specifying default file metadata (in this case owner
, permissions
, encoding
) at the directory level (see defaultMode
in the above example), and then allow for overriding those at the file level (see items[].mode
in the above example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do the configmap & secret sources in Kubernetes offer anything like this?
Pod volumes are a slightly different use-case in that the unit of concern is a dir rather than a file. Also, the volume source and the volume mount location are specified separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be documented in the code how we are preventing two machines referencing the same ConfigMap/Secrets, because this will break the clusterctl move logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fabriziopandini Noted.
Are we happy to move forward with the above data structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with it.
FYI I'm trying to overcome the limitation of the single cluster on a parallel thread about clusterctl move
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok moving forward. Note, we have a fairly aggressive timeline for getting v1alpha3 done, so this may make it, or be deferred to v1alpha4 - just want to be up front about that.
going through the open PRs, I wonder what's the status of this one? Should we close it and try to spec it out in v0.4 a little more? |
@nstogner: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I do think it's worth finalizing the data format before asking @nstogner to do any additional coding. |
I'd move the discussion into a proposal google doc first, and use the CAEP template format to start the discussion and gather feedback |
@nstogner not sure if you're currently working on this, I started a doc and fresh PR from master incorporating these changes + my interpretation of the desired updates (added you as a git coauthor) #1739 (comment) |
Going to close this for now given that we have other PRs soon tackling this. /close |
@vincepri: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What this PR does / why we need it:
Allow users to specify file content in KubeadmConfig by referencing ConfigMap and Secret objects.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1846