Open Sanhajio opened 3 years ago
Hmm, that's slightly weird, I wonder why they have both variations in the spec...
I think ignoring duplicate fields (and instead just printing a warning) for cases like these makes more sense than completely failing the import command, especially since users are usually not the authors of the specs.
I opened an issue in istio, it seems to be a legacy field that is deprecated but kept for backward compatibility. Kubernetes API standard is to write fields in camel case,
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon.
I just observed this doing the same thing for the virtualservice CRD, using --language go
I've also encountered the same thing. I think duplicate fields could safely be ignored, and we should prefer camelCase ones as they are less likely to be deprecated.
This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
Closing this issue as it hasn't seen activity for a while. Please add a comment @mentioning a maintainer to reopen. If you wish to exclude this issue from being marked as stale, add the "backlog" label.
I'm not entirely comfortable with ignoring properties, but maybe in case of a duplicate, we can include the second property in its original casing. Requires a bit of research.
Hi is this issue resolved? duplicate error due to different casing?
The istio VirtualService CRD is still causing the same errors on import (cdk8s-cli 2.2.83) due to the duplicate field names. What is the plan to address this?
Currently this would require some pre-processing before executing cdk8s import
. We will consider putting this on our near term roadmap as looks like this issue is gaining popularity.
@iliapolo, has this made it to the roadmap?
We're currently using a preprocess step in a form of this patch-crds.js
script:
const fs = require('fs');
const yaml = require('yaml');
const filePath = process.argv[2];
const crds = yaml.parse(fs.readFileSync(filePath, 'utf-8'));
/**
* Patch postgresql
*/
{
const crd = crds.items.find(
crd => crd.metadata.name === 'postgresqls.acid.zalan.do',
);
const {properties} =
crd.spec.versions[0].schema.openAPIV3Schema.properties.spec;
delete properties.init_containers;
delete properties.pod_priority_class_name;
properties.users.additionalProperties.items.enum = new Set(
properties.users.additionalProperties.items.enum.map(item =>
item.toLowerCase(),
),
);
}
fs.writeFileSync(filePath, yaml.stringify(crds));
We call it in package.json
script like this:
{
"scripts": {
"import:k8s": "cdk8s import --language typescript --output src/imports k8s",
"import:crds": "kubectl get crds -o yaml > src/imports/crds.yaml && node patch-crds.js src/imports/crds.yaml && cdk8s import --language typescript --output src/imports src/imports/crds.yaml",
"import": "rimraf src/imports && npm run import:k8s && npm run import:crds"
}
}
@bderrly We are actually discussing this internally these days to see if there's a reasonable thing cdk8s can do here.
Description of the bug:
When using
cdk8s import --language python /dev/stdin
on istio's virtual service crd on python I get an import errorI get this error only using cdk8s import python language, I don't get it on This is because on the virtual service crd, there are two fields named almost the same
it ends up being duplicated in the code generation:
a workaround I found is to delete the mirror_percent in the json crd definition
I think duplicate fields could be safely ignored, as the issue does not come from the jsii compiler but from the crd definition, IMHO
Reproduction Steps:
This is :bug: Bug Report