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

Define validation strategy for provider config #44

Closed
rsdcastro opened this issue Apr 12, 2018 · 3 comments
Closed

Define validation strategy for provider config #44

rsdcastro opened this issue Apr 12, 2018 · 3 comments

Comments

@rsdcastro
Copy link

From @rsdcastro on February 22, 2018 21:13

As per comment in #405, "validation is another concern and independent of specifying the cloud provider in the top level object or in the provider specific config. We can't bake provider specific validation logic into the API. That needs to be pluggable somehow through a webhook, admission controller, or some other mechanism. But it's a much larger discussion."

This issue tracks methods we'll allow for validation, including recommendations and examples.

cc @karan

Copied from original issue: kubernetes-retired/kube-deploy#623

@rsdcastro
Copy link
Author

From @roberthbailey on March 7, 2018 18:53

This seems to depend on kubernetes-retired/kube-deploy#504

@roberthbailey
Copy link
Contributor

Validation is provider specific, so this is out of scope for this repository.

/close

@k8s-ci-robot
Copy link
Contributor

@roberthbailey: Closing this issue.

In response to this:

Validation is provider specific, so this is out of scope for this repository.

/close

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.

chuckha pushed a commit to chuckha/cluster-api that referenced this issue Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants