search

cdk8s-team / cdk8s

Define Kubernetes native apps and abstractions using object-oriented programming
https://cdk8s.io
Apache License 2.0
4.31k stars 291 forks source link

FlowSchema has incorrect Subject parameters for 1.30 #2138

Open jrcichra opened 4 weeks ago

jrcichra commented 4 weeks ago

Description of the bug:

When creating a FlowSchema in cdk8s with the 1.30 imports it does not have the correct parameters for the Subject object under .spec.rules.subjects. It looks like it is reusing the RBAC Subjects field which does not have the same fields.

There should be a serviceAccount and user field. Instead it has name and namespace at the top level, which is not in kubectl explain flowschema.spec.rules.subjects. Using name and namespace as specified in the typescript schema does not apply to a 1.30.0 cluster.

Reproduction Steps:

Start a new cdk8s project. Make a FlowSchema with at least one .spec.rules.subjects. Attempt to apply the result to a 1.30 cluster.

Error Log:

FlowSchema in version "v1" cannot be handled as a FlowSchema: strict decoding error: unknown field "spec.rules[0].subjects[0].name", unknown field "spec.rules[0].subjects[0].namespace", unknown field "spec.rules[0].subjects[1].name", unknown field "spec.rules[0].subjects[1].namespace

Environment:

Other:

This is :bug: Bug Report

jrcichra commented 4 weeks ago

It looks like the schema is correct in _definitons.json: https://github.com/cdk8s-team/cdk8s/blob/9fddebbca5a56199735bd4fcc375cc9e6cb001f5/kubernetes-schemas/v1.30.0/_definitions.json#L13070

jrcichra commented 4 weeks ago

The issue might be in the cdk8s import code when there are two Objects with the same name (Subject): https://github.com/cdk8s-team/cdk8s-cli/tree/2.x/src/import

jrcichra commented 4 weeks ago

v1beta3 seems to have the proper fields, using that as a workaround for now.

iliapolo commented 3 weeks ago

Thanks for reporting this. Yeah this is because there is a basename collision between io.k8s.api.rbac.v1.Subject and io.k8s.api.flowcontrol.v1.Subject. I think we need to start adding the ApiGroup to generated classes/interfaces names...but that would be a breaking change.

Marking as p1.

iliapolo commented 3 weeks ago

Another possibly non breaking solution is to provide an option to cdk8s import. something like cdk8s import --include-api-group