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

Use another yaml dep to unmarshall the schema #4050

Merged
merged 2 commits into from
Jan 11, 2022

Conversation

antgamdia
Copy link
Contributor

Description of the change

Follow-up PR of #4023.

After giving a try to the repo that the TCE folks so kindly created (vmware-tanzu/community-edition#2775 (comment))), I noticed it still failed in Kubeapps. The unmarshaller was returning an error even if the addtionalProperties prop was properly being set (according to the JSONSchema Spec).
I guess it has something to do with the JSONSchemaPropsOrBool (from k8s) field it tries to unmarshall to, but I don't know the root cause yet.

Anyway, it gets sorted out when using another yaml dependency, which in case of failures, it seems to be using the default value in JSONSchemaPropsOrBool (which is true).

This PR replaces this yaml dep and updates the test cases accordingly.

Benefits

Kubeapps will be able to set default values for all the TCE packages (and any other with the same issue in the schema)

Possible drawbacks

Perhaps it can influence #3848.

Applicable issues

Additional information

image

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
@@ -27,11 +27,11 @@ import (
datapackagingv1alpha1 "github.com/vmware-tanzu/carvel-kapp-controller/pkg/apiserver/apis/datapackaging/v1alpha1"
"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
"gopkg.in/yaml.v3"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't we unify the versions we use?
Here we are using v2.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Absolutely agree, that's indeed the purpose of #3848.
We have several duplicated deps we ought to simplify sooner or later. Regarding this v2 vs v3 I'd clearly go with v3 since it allows editing the Yaml parsed nodes directly, meaning one is eventually able to create custom nodes manually (e.g., adding commented-out values)

@castelblanque
Copy link
Collaborator

Thanks! Kubeapps is one step closer to TCE :)

Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Copy link
Contributor

@absoludity absoludity left a comment

Choose a reason for hiding this comment

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

Excellent!

@antgamdia antgamdia merged commit df51e13 into vmware-tanzu:master Jan 11, 2022
@antgamdia antgamdia deleted the 3853-yamlDep branch January 11, 2022 08:28
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

Successfully merging this pull request may close these issues.

None yet

3 participants