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

Validate YAML / JSON API values #2809

Open
chrislovecnm opened this issue Jun 24, 2017 · 4 comments
Open

Validate YAML / JSON API values #2809

chrislovecnm opened this issue Jun 24, 2017 · 4 comments
Labels
area/usability lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@chrislovecnm
Copy link
Contributor

In order to provide greater usability, we should have validation that does:

  1. validate valid YAML before a kops execution, before a state store is created.
  2. validate extra YAML values. Currently, we ignore extra stuff, we should warn and force the user to turn off warning like kubectl.
  3. what am I missing? Validate different versioning? For instance when we move from v2 to v3?
@chrislovecnm chrislovecnm changed the title Validate yaml Validate YAML Jun 24, 2017
@chrislovecnm chrislovecnm changed the title Validate YAML Validate YAML / JSON API values Nov 9, 2017
@chrislovecnm
Copy link
Contributor Author

Some notes from @liggitt

to see if you're dropping fields, you can decode into an unstructured object in addition to your struct type, then re-encode your struct and see if they are equal

  1. get bytes to decode
  2. decode into unstructured.Unstructured
  • 2 and 3 should match
  • if 3 has extra data, then you likely are using defaulting that set fields for the user
  • if 3 has missing data, then the user specified fields not present in your struct
    that could be because they're writing to a newer version of kops, or because they typo-ed a field
  • if you get strict about not dropping fields, older versions of kops will break if the user specifies a value that is unrecognized

We also just need to validate the file as valid YAML.

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 7, 2018
@blakebarnett
Copy link

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 7, 2018
@chrislovecnm
Copy link
Contributor Author

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added the lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. label Feb 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/usability lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

5 participants