-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
roll our own strict config loading #912
roll our own strict config loading #912
Conversation
994b539
to
346ad70
Compare
346ad70
to
d0f4a5a
Compare
/hold cancel reasonably happy with this now, might experiment with other strict parsers later... (namely: https://godoc.org/gopkg.in/yaml.v3) |
What are the pros and cons of moving away from apimachinery? |
pros:
cons:
The api machinery makes sense for large sets of kubernetes APIs. It's overkill for loading a config file and doing some defaulting / converting between sets of types. DeepCopy is always purely mechanical though, so it's kinda nice to keep for those, and has a very simple API. |
then, it's clear the path here 😄 |
the picture around component-config vs usage of api-machinery is not very clear, yet component-config is still leaning towards continuing to use api-machinery for config management. the alternatives introduces by this approach are fine and would work. my personal vote would be to continue using api-machinery, because without it kind will deviate from the plan for the ecosystem. yet in the end of the day the maintainers know best what is best for the project. |
this gives considerably better errors.
|
Totally understand and sympathize with that, but the ecosystem has it's own tech-debt (EG switching to yaml.v3 has been "fun" I gather and not looking super feasible soon...) that kind does not need to be held back by, and I think many of the components have different needs. kind is a good place to try things and report back, it's OK to be a little different. We can always switch back at a later date if the trade-off changes. With a little more cleanup this:
|
/hold |
d112cef
to
d60c95f
Compare
d60c95f
to
140c6a3
Compare
140c6a3
to
53bd2eb
Compare
/test all |
(confirming https://status.docker.com/pages/533c6539221ae15e3f000031 impact, see #951 for temporary work around) |
how is the workflow of adding a new api field or adding a new api version? |
~unchanged. |
/retest |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amwat, BenTheElder 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 |
/hold cancel |
|
||
// Nodes contains the list of nodes defined in the `kind` Cluster | ||
// If unset this will default to a single control-plane node | ||
// Note that if more than one control plane is specified, an external | ||
// control plane load balancer will be provisioned implicitly | ||
Nodes []Node `json:"nodes,omitempty"` | ||
Nodes []Node `yaml:"nodes,omitempty" json:"nodes,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.
sorry for not having a look at this PR again.
i think this dropped support for user provided JSON kind config files?
which is not very critical but diverges from the "component config" / api-machinery trend.
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 also has json tags for now? (reread the diff?)
- we never supported JSON config files. I don't intend to. yaml is a superset of json.
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.
Kubernetes needs a seperate JSON parser for other reasons (because it gives better errors?). yaml.v3 also gives better errors kubernetes/kubernetes#78946
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.
missed the extra tags in the diff.
|
||
// get kind & apiVersion | ||
tm := typeMeta{} | ||
if err := yaml.Unmarshal(raw, &tm); err != 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.
hm, i've heard that v3 enables strict by default for the Unmarshal function.
kubernetes-sigs/yaml#26 (comment)
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 doesn't. we parse a config file in CI.
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.
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 took a pass through the actual yaml.v3 code before switching)
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 see, perhaps the linked commend was misleading.
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.
also the new Node object's Decode()
does not preserve strict being enabled 😞
AFAICT implementing the secret "obsolete" (v2 api) custom YamlUnmarshal
method works fine though.
/hold
this is an interesting possible alternative to #911
it's less code, simpler, doesn't use
unsafe
, doesn't fail lints ....