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

Handle unknown types as unstructured #954

Merged
merged 4 commits into from
Oct 18, 2019
Merged

Handle unknown types as unstructured #954

merged 4 commits into from
Oct 18, 2019

Conversation

alenkacz
Copy link
Contributor

@alenkacz alenkacz commented Oct 16, 2019

What this PR does / why we need it:
When scheme did not contain that type, we previously failed. Since we should be able to handle all types that people might have installed in their cluster, we should fallback to parsing a type as unstructured when not available.

This PR has 3 parts:

  • update to ParseKubernetesObjects to process unknown types as Unstructured
  • use of dynamic restmapper in execution that ensures that we discover new types that were added during the lifetime of the controller
  • integration test

NOTE: Right now we are using dynamic mapper from test harness. That is probably not as robust as the one introduced in the controller-runtime 0.3.0. I will port this code to the controller-runtime mapper when we bump the version of controller-runtime (that should happen prior to 0.8.0 anyway).

Fixes #913

@alenkacz alenkacz changed the title Handle unknown types as unstructured WIP: Handle unknown types as unstructured Oct 16, 2019
@alenkacz
Copy link
Contributor Author

I'll try to add integration test to confirm this

@alenkacz alenkacz changed the title WIP: Handle unknown types as unstructured Handle unknown types as unstructured Oct 17, 2019
@@ -52,6 +54,7 @@ func (drm *DynamicRESTMapper) reloadOnError(err error) bool {
return false
}
err = drm.reload()
fmt.Println("reload")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errant println?

Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

functionally lgtm . I wouldn't stop a merge... but I do think it would be more readable with some package changes and it would be nice to keep "test" pkg from bleeding into the cli

@@ -23,6 +23,7 @@ import (
"github.com/kudobuilder/kudo/pkg/controller/instance"
"github.com/kudobuilder/kudo/pkg/controller/operator"
"github.com/kudobuilder/kudo/pkg/controller/operatorversion"
util "github.com/kudobuilder/kudo/pkg/test/utils"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. IMO we should not import from the pkg/test packages. This could should move out to a common lib location used by kudo and test
  2. it should not be in a utils package. IMO it looks like we have a code in test/utils/ which should be in our project kube or kubernetes package.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have a number of kube Clients like this in pkg/kubdoctl/kube/config.go

//ParseKubernetesObjects parses a list of runtime.Objects from the provided yaml
// ParseKubernetesObjects parses a list of runtime.Objects from the provided yaml
// If the type is not known in the scheme, it tries to parse it as Unstructured
// TODO(av) could we use something else than a global scheme here? Should we somehow inject it?
func ParseKubernetesObjects(yaml string) (objs []runtime.Object, err error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yaml string seems unnecessarily limiting... wouldn't io.Reader be better?

Copy link
Member

@kensipe kensipe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed the fact that there is a future controller-runtime feature that abstracts the client for unstructured... this looks good to go for me

@alenkacz alenkacz merged commit 5459b7d into master Oct 18, 2019
@alenkacz alenkacz deleted the av/unstructured branch October 18, 2019 07:18
alenkacz added a commit that referenced this pull request Oct 18, 2019
**What this PR does / why we need it**:
When scheme did not contain that type, we previously failed. Since we should be able to handle all types that people might have installed in their cluster, we should fallback to parsing a type as unstructured when not available.

This PR has 3 parts:
- update to `ParseKubernetesObjects` to process unknown types as Unstructured
- use of dynamic restmapper in execution that ensures that we discover new types that were added during the lifetime of the controller
- integration test

NOTE: Right now we are using dynamic mapper from test harness. That is probably not as robust as the one introduced in the controller-runtime 0.3.0. I will port this code to the controller-runtime mapper when we bump the version of controller-runtime (that should happen prior to 0.8.0 anyway).

Fixes #913
alenkacz added a commit that referenced this pull request Oct 18, 2019
**What this PR does / why we need it**:
When scheme did not contain that type, we previously failed. Since we should be able to handle all types that people might have installed in their cluster, we should fallback to parsing a type as unstructured when not available.

This PR has 3 parts:
- update to `ParseKubernetesObjects` to process unknown types as Unstructured
- use of dynamic restmapper in execution that ensures that we discover new types that were added during the lifetime of the controller
- integration test

NOTE: Right now we are using dynamic mapper from test harness. That is probably not as robust as the one introduced in the controller-runtime 0.3.0. I will port this code to the controller-runtime mapper when we bump the version of controller-runtime (that should happen prior to 0.8.0 anyway).

Fixes #913
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Broken support of Prometheus operator CRDs
3 participants