search

cdk8s-team / cdk8s

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

FlowSchema has incorrect Subject parameters for 1.30 #2138

Open jrcichra opened 2 months ago

jrcichra commented 2 months 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 2 months 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 2 months 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 2 months ago

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

iliapolo commented 2 months 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 2 months ago

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