-
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
✨ CABPK can now read file contents from a Secret #3083
Conversation
/hold for some additional manual testing |
87a85b7
to
039ea98
Compare
/test pull-cluster-api-e2e |
func Convert_v1alpha3_File_To_v1alpha2_File(in *kubeadmbootstrapv1alpha3.File, out *File, s apiconversion.Scope) error { | ||
// We don't implement manual conversion for types using contentFrom | ||
return autoConvert_v1alpha3_File_To_v1alpha2_File(in, out, s) | ||
} |
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.
We should still restore it when we go v1alpha3 -> v1alpha2 -> v1alpha3
, there is an example in other files, or I can help tomorrow
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.
will add
// +optional | ||
Secret *SecretFileSource `json:"secret,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.
This shouldn't be optional I think? If one specifies a FileSource
in file.contentFrom: {}
it should fail validation saying that secret
is required
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.
Since we only have one I was thinking if in the future we change this from required to optional it'd be breaking? But I think you mentioned today it's fine, and I concur that makes sense. Will make required.
The webhook does validate the stricter scenario already, I think you're correct regardless.
/test pull-cluster-api-test |
Only reviewed ~40% for now, will continue later |
5c977e8
to
d006bc0
Compare
Co-authored-by: Vince Prignano <[email protected]> Signed-off-by: Alexander Eldeib <[email protected]>
I tried to reorder commits so all the functional stuff is in one because it's fairly small compared to total changes. Moved the rest into separate Go/yaml commits, hope that's easier to review. |
How this looks for Azure now, if anyone is interested: apiVersion: bootstrap.cluster.x-k8s.io/v1alpha3
kind: KubeadmConfigTemplate
metadata:
name: ${CLUSTER_NAME}-md-0
spec:
template:
spec:
files:
- contentFrom:
secret:
name: azure-secret
key: azure.json
owner: root:root
path: /etc/kubernetes/azure.json
permissions: "0644"
joinConfiguration:
nodeRegistration:
kubeletExtraArgs:
cloud-config: /etc/kubernetes/azure.json
cloud-provider: azure
name: '{{ ds.meta_data["local_hostname"] }}'
---
apiVersion: v1
kind: Secret
metadata:
name: azure-secret
data:
"azure.json": |
${AZURE_JSON_B64} definitely nicer than the previous example IMO |
@@ -39,6 +39,7 @@ func (src *KubeadmConfig) ConvertTo(dstRaw conversion.Hub) error { | |||
dst.Status.DataSecretName = restored.Status.DataSecretName | |||
dst.Spec.Verbosity = restored.Spec.Verbosity | |||
dst.Spec.UseExperimentalRetryJoin = restored.Spec.UseExperimentalRetryJoin | |||
dst.Spec.Files = restored.Spec.Files |
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 think this is what we want? Otherwise we have to match files based on some property field to match array items?
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.
We should only restore the files that have ContentFrom
populated (non-nil)
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.
Is this because the restored version might be stale where conversion was possible?
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.
Correct, in case a v1alpha2 controller modified some of the files (even though unlikely because bootstrap should only happen once), we need to make sure to restore those that have the new schema.
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 not sure I follow what this is doing... we're setting dst.Spec.Files
to restored.Spec.Files
and then appending some of the restored files to dst.Spec.Files
? Isn't that going to result in duplicates?
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.
Nice catch.
I think the first line dst.Spec.Files = restores.Spec.Files
is leftover from my first revision, it should only be the loop. The intent is to look at restored files with contentFrom and append them. We shouldn’t append restored files with content set.
Will PR shortly
/hold cancel |
return nil | ||
} | ||
|
||
func (c *KubeadmConfig) validate() error { |
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.
func (c *KubeadmConfig) validate() error { | |
func (c *KubeadmConfigSpec) validate() error { |
If we add this method to KubeadmConfigSpec
instead of KubeadmConfig
we should be able to call it from the webhooks defined under controlplane/kubeadm
as well.
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.
better?
89831eb
to
5c3a0f2
Compare
/retest |
/retest |
8f5f288
to
2cff638
Compare
Signed-off-by: Alexander Eldeib <[email protected]> Co-authored-by: Vince Prignano <[email protected]>
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.
One other thing that came to mind when I was reading the conversion is that today files
has no checks on whether the path
for each added file
is actually unique.
Would that cause a configuration error?
in.ContentFrom = nil | ||
in.Content = string(data) | ||
collected[i] = in |
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.
Just to double check, this logic is only changing the content of the struct at runtime, but it won't be stored in the KubeadmConfig at the end when we patch.
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's the intent. I could probably make this a little bit more explicit by newing up a slice, copying, and returning? Plus comments
/milestone v0.3.7 |
Files not validating path uniqueness is a problem, yes. This PR matches the existing behavior in files which is effectively "last file wins". I can validate uniqueness on path and adjust the conversion logic to account? The main effect of this right now is loss of conversion fidelity: conversion from v1a3 to v1a2, then adding a raw content file with the same path as a contentFrom file and then converting back to v1a3 would prefer the contentFrom file, even though the raw content file is newer. |
We should probably also validate that via webhooks at create time |
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.
@alexeldeib I like very much this new approach
Only one minor not from my side, otherwise lgtm
@alexeldeib I'm fine doing the validation in a different PR / later |
/retitle ✨ CABPK can now read file contents from a Secret |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexeldeib, fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@vincepri I'm happy either way. Might make more sense to snapshot as-is and iterate, but the additional code change isn't too big. I'll have a chance to wrap up the additional changes today/tomorrow. @fabriziopandini thanks for review! 👍 |
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.
/lgtm
What this PR does / why we need it:
related to #1739
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):revised from #3038 after offline discussion
still needs some manual testing