new package name and module base for generated code

[guoshimin]

New package name: kubernetes-openapi
New module base: Kubernetes.OpenAPI

Generated using kubernetes-client/gen@8237ccb

On my system I had to run the command under sudo:

sudo ${GEN_REPO_BASE}/openapi/haskell.sh kubernetes settings

[guoshimin]

@denibertovic can you review this PR? Thanks!

[jkachmar]

Is there anything that can be done to help with this? I'm interested in using this library, and it'd be nice to have some of the moving parts get settled before it gets pushed to Hackage.

[guoshimin]

You can review this PR :)

…

On Thu, Feb 21, 2019, 12:42 PM Joe Kachmar ***@***.***> wrote: Is there anything that can be done to help with this? I'm interested in using this library, and it'd be nice to have some of the moving parts get settled before it gets pushed to Hackage. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALPcHY8nPq8JZ08FBLEOUMaIf3H8u-s5ks5vPwSggaJpZM4abEUB> .

[jkachmar]

Okay, so I did a brief review of the changes (since this nearly all generated code), as well as having run this locally.

This seems like a good update, however there are two things that concern me in general:

1. the divergence between the haskell-http-client swagger-codegen and openapi-generator modules
2. support for newer Kubernetes APIs beyond v1.9

Parts of (1) discussed in #28; unfortunately I can't seem to get the openapi-generator to run successfully, so I'm not sure how to proceed here. So long as this library is locked to swagger-codegen it is unable to support newer Stackage snapshots and/or updated library versions, which will definitely be problematic (if it isn't already).

I'm unsure what the best way to approach (2) is; is the Kubernetes API backwards compatible between minor versions (e.g. v1.9 -> v1.11)? If so, then this project should probably follow a similar model to the python client's compatibility matrix.

[guoshimin]

@jkachmar Thanks for taking a look!

For openapi-generator, I think we need to wait for kubernetes-client/gen#93 to be resolved. I took a look a while ago, and it didn't seem easy to switch to openapi-genenrator just for haskell.

For 2) I think we should absolutely generate code for a more recent API version. Didn't do it here because I didn't want the two changes to be mixed together.

[jonschoning]

It looks like kubernetes-client/gen#95 was already merged to switch python-asyncio, but we need to understand the cause of the previously linked build errors first.

[jkachmar]

@jonschoning I think that might have been my error; I was using an old commit hash for openapi-generator, and it may have been missing some updates.

I'm trying to rerun all this now, but I'm unfortunately running into this when trying to build the Dockerfile:

Log Snippet

Err:6 https://packages.microsoft.com/debian/9/prod stretch/main amd64 Packages
  Writing more data than expected (38208 > 37999)
  Hashes of expected file:
   - Filesize:37999 [weak]
   - SHA512:194ded11a350aab88b7fc1c5fee5dd6746a6bd0136ee96ad2290fc9459086daf75fbeda376ab00c0455cbeab6e64fa405f82ef0991b28322f29f30dab2aaaede
   - SHA256:369f15b8a43c29e6adf6db3329576366123c6bb749ee311f5099752de06474ea
   - SHA1:87f67045f0db46ee582998ba1d432b47900f5992 [weak]
   - MD5Sum:38eeded94abf10a911e570233047151b [weak]
  Release file created at: Tue, 19 Feb 2019 18:30:09 +0000
Fetched 3232 B in 0s (6361 B/s)                          
Reading package lists... Done
E: Failed to fetch https://packages.microsoft.com/debian/9/prod/dists/stretch/main/binary-amd64/Packages.bz2  Writing more data than expected (38208 > 37999)
   Hashes of expected file:
    - Filesize:37999 [weak]
    - SHA512:194ded11a350aab88b7fc1c5fee5dd6746a6bd0136ee96ad2290fc9459086daf75fbeda376ab00c0455cbeab6e64fa405f82ef0991b28322f29f30dab2aaaede
    - SHA256:369f15b8a43c29e6adf6db3329576366123c6bb749ee311f5099752de06474ea
    - SHA1:87f67045f0db46ee582998ba1d432b47900f5992 [weak]
    - MD5Sum:38eeded94abf10a911e570233047151b [weak]
   Release file created at: Tue, 19 Feb 2019 18:30:09 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

[jonschoning]

kubernetes-client-helper and kubernetes-watch libraries in this repo would also need to be updated to depend on the new package name and module base, with this PR they would no longer compile.

Perhaps they need to be renamed as well e.g. kubernetes-openapi-client-helper & kubernetes-openapi-watch

not sure if the files & folder structure at the root should also be updated, but would certainly at least be more consistient.

let me know if you'd like me to help out cleaning stuff up & add commits

[jkachmar]

Agh, you're right I didn't even think to look in either of those modules, they'd break with the new naming scheme for sure 😞

---

Regarding packaging, this comment seems to lay out a fairly good structure.

Assuming I'm interpreting it correctly:

• kubernetes-openapi-client-core / kubernetes-openapi-client-gen
  • this would contain the generated code
• kubernetes-openapi-client
  • this would subsume the kubeconfig, kubernetes-openapi-client-helper and kubernetes-openapi-watch, as well as include/re-export the generated code

This way if someone wants to use just the bindings, they're capable of doing so, but for most people the happy path of a batteries included Kubernetes client is easily accessible.

[jonschoning]

That is a bit more structured and uses different package names than what guoshimin proposed, and isn't what is in this PR currently, but I do like the ergonomics of it better.

Re-exporting the codegen under a single package definitely would make discoverability much easier, than having know there are several related-but-differently-named packages that need to be used together.

[guoshimin]

@jkachmar Your proposal is better. I'll change this PR to do that!

[guoshimin]

PTAL

[jkachmar]

Looks good!

I suppose it makes the most sense to merge this PR, then restructure the module hierarchy?

After that, if we can reconcile with the new openapi-generator, then it will (hopefully) be somewhat straightforward to cut an updated release and publish to Hackage.

[guoshimin]

What do you mean by restructure the module hierarchy? I will combine the other packages into a single one, is there something else?

[jkachmar]

What I meant by this comment was that it might be more ergonomic to have a single package for the generated code (i.e. kubernetes-openapi-client-gen), and a single package that contains all the functionality of the kubeconfig, -watch, and -client-helper packages (i.e. kubernetes-openapi-client).

Rather than containing/publishing four separate packages, this repository could contain two:

• the -gen module itself
• the -client module, which provides a nice entry point for all the helper functionality that's built around -gen

Does this make sense?

[guoshimin]

Yeah, sounds good!

[brendandburns]

/lgtm

[guoshimin]

/approve

[brendandburns]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, guoshimin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [brendandburns]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment