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

feat: Initial project implementation #1

Closed
wants to merge 8 commits into from

Conversation

thiagopena
Copy link
Collaborator

No description provided.

@diogobaeder
Copy link
Member

Sorry for the long delay to review this, @thiagopena , my bad.

First of all, thank you so much for the effort to put up this PR! I see that you were very careful with the tests and organization of the code.

However it's in a different direction that I wanted to take when I thought about the project initially; What I'd like to have is a library that already contains all the core Kubernetes models in it, and not a library whose only purpose is to generate that code. If you take, for example, the kubernetes library, or pulumi, they both contain models ready to use (without Pydantic though), you don't need to run anything to generate them for those libraries. The idea is that whoever uses our library only has to install it and will be able to use the models right away.

So here's a few recommendations for what to do:

  • We can get the OpenAPI specs for K8s from here for example: https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec/v3 - instead of having to run Kubernetes locally in order to have them available. With them I think we might be able to generate the models.
  • Having the models generated, we should commit them to the library to have them available as part of the package, and not ignore them from version control.
  • We could setup scheduled workflows in GHA to generate them automatically for us, to make sure we'll be able to automatically get API updates transformed into models (but we may want to set this up later, to reduce the burden of having a first released version).

What do you think?

@thiagopena
Copy link
Collaborator Author

No worries @diogobaeder .
You mean something more like this, correct? #2

@diogobaeder
Copy link
Member

No worries @diogobaeder .
You mean something more like this, correct? #2

Exactly! Should we close this PR in favor of the second one then?

@thiagopena
Copy link
Collaborator Author

Closed in favor of: #2

@thiagopena thiagopena closed this Apr 28, 2024
@thiagopena thiagopena deleted the feat/first-implementation branch April 28, 2024 13:34
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.

2 participants