Closed abelsromero closed 2 years ago
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: abelsromero
To complete the pull request process, please assign brendandburns after the PR has been reviewed.
You can assign the PR to them by writing /assign @brendandburns
in a comment when ready.
The full list of commands accepted by this bot can be found here.
To fix csharp code-gen we need to pin at version 2 so we should set npm i autorest@2.0.4413
see: https://github.com/kubernetes-client/csharp/issues/563
We can do that in this PR or a separate PR
We need to validate that this doesn't introduce any code differences in the generated clients before this can be merged.
Ideally this would be a pre-merge check, but sadly it's not currently added as a test.
We can do that in this PR or a separate PR
I can give it a try in this same PR.
Running with v2.0.4413
resulted in the following error
There is a new version of AutoRest available (3.1.2).
> You can install the newer version with with npm install -g autorest@latest
Starting @microsoft.azure/autorest-core from /tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417
Loading AutoRest core '/tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417/node_modules/@microsoft.azure/autorest-core/dist' (2.0.4417)
No configuration found at 'file:///'.
Loading local AutoRest extension '@microsoft.azure/autorest.csharp' (/node_modules/@microsoft.azure/autorest.csharp)
Loading local AutoRest extension '@microsoft.azure/autorest.modeler' (/node_modules/@microsoft.azure/autorest.modeler)
events.js:292
throw er; // Unhandled 'error' event
^
Error: write EPIPE
at afterWriteDispatched (internal/stream_base_commons.js:156:25)
at writeGeneric (internal/stream_base_commons.js:147:3)
at Socket._writeGeneric (net.js:785:11)
at Socket._write (net.js:797:8)
at writeOrBuffer (internal/streams/writable.js:358:12)
at Socket.Writable.write (internal/streams/writable.js:303:10)
at Writable.write [as _write] (/tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417/node_modules/@microsoft.azure/autorest-core/dist/lib/pipeline/plugin-endpoint.js:38:31)
at writeOrBuffer (internal/streams/writable.js:358:12)
at Writable.write (internal/streams/writable.js:303:10)
at StreamMessageWriter.write (/node_modules/vscode-jsonrpc/lib/messageWriter.js:82:27)
at /node_modules/vscode-jsonrpc/lib/main.js:761:35
at new Promise (<anonymous>)
at Object.sendRequest (/node_modules/vscode-jsonrpc/lib/main.js:751:26)
at Object.GetPluginNames (/tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417/node_modules/@microsoft.azure/autorest-core/dist/lib/pipeline/plugin-endpoint.js:78:86)
at AutoRestExtension.GetPluginNames (/tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417/node_modules/@microsoft.azure/autorest-core/dist/lib/pipeline/plugin-endpoint.js:116:31)
at Function.FromChildProcess (/tmp/.autorest/@microsoft.azure_autorest-core@2.0.4417/node_modules/@microsoft.azure/autorest-core/dist/lib/pipeline/plugin-endpoint.js:110:41)
Emitted 'error' event on Socket instance at:
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
errno: -32,
code: 'EPIPE',
syscall: 'write'
I'll take a look at getting the csharp generation working. There was a commit to do this here:
https://github.com/kubernetes-client/gen/commit/74ee0c60948ecdc4af8613bcb0b658d0fdc1b821
But it got overwritten for some reason.
Taking a step back to the beginning, what is the motivation for upgrading to Java8/Maven 3.6? Is there something broken with the existing setup?
Taking a step back to the beginning, what is the motivation for upgrading to Java8/Maven 3.6? Is there something broken with the existing setup?
Mainly keeping things with up-to-date and supported versions.
Ok, given that there's no pressing need, I think I would like to delay this PR until we get csharp generating correctly. I'll try to get to that soon-ish. Apologies for the delay.
Ok, given that there's no pressing need, I think I would like to delay this PR until we get csharp generating correctly. I'll try to get to that soon-ish. Apologies for the delay.
Ok, given that there's no pressing need, I think I would like to delay this PR until we get csharp generating correctly. I'll try to get to that soon-ish. Apologies for the delay.
No problem at all. JS it not in my area of expertise, but I can do some more research and share what I find.
Tried to run autorest "natively" in my machine and it seems to go further, but finally fails with
DEBUG: [WRITING] ModelTemplate => Models/V1ValidatingWebhookConfigurationList.cs
DEBUG: [WRITING] ModelTemplate => Models/Corev1EventList.cs
DEBUG: [WRITING] ModelTemplate => Models/V1beta1MutatingWebhookConfigurationList.cs
DEBUG: csharp/generate - END
DEBUG: csharp/simplifier - START
No usable version of the libssl was found
FATAL: csharp/simplifier - FAILED
FATAL: Error: [Exception] AutoRest extension '@microsoft.azure/autorest.csharp' terminated.
Process() cancelled due to exception : [Exception] AutoRest extension '@microsoft.azure/autorest.csharp' terminated.
I have libssl installed, but probably not a compatible version, so I'll try to build a Debian VM. I noted that while running node starts listen on ports 12494 (LISTEN) and 32066 (LISTEN), I wonder if it could be related.
@abelsromero thanks for pursuing this. Definitely no obligation if you get bored/stuck I will get it done, but the assist is much appreciated!
Seeeing the interdependencies between tools and how these prevents other converters. I wonder if it would make sense to have different Dockerfiles. I know it would mean some duplication, but the fact that for one language we have to block the mantainance of of al the rest seems a high cost to me.
@abelsromero probably good observation. We could split them out and have them all depend on a shared base image, which would largely eliminate the duplication.
If this is blocking some work on java generation, let me know and I will increase the priority of fixing this.
@abelsromero: PR needs rebase.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closed this PR.
This PR begun with the intent to update the maven version used 3.5 (2018-06-21) on java8 by latest 3.6.3 (2019-11-25) in java11. But this broke other things and ended up requiring several changes in all generators.
Now, all but
csharp
work, which fails with the following error. I suspect it could be the ammount of types in the k8s API is too much.Note also that CSharp does not currently work neither because it downloads latest version of
autorest
which requires a newer version of dotnet.We could try to use the openapi maven plugin, based on this example, there's support for csharp https://openapi-generator.tech/docs/usage/, I cannot validate further than checking than some code is being generated. wdyt, should I replace current autorest usage?
Said, that this PR required the following changes:
openapi-generator-maven-plugin
for all generators to 4.3.1. This is the latest v4.x. There's a 5.x but didn't want ot push too much. I'd rather do it in separated PR.skipValidateSpec
option to several generations, otherwise the k8s was considered not valid.