Add cluster version type

[samuelorji]

Description

Add a concrete type for the cluster version info, such that clients can parse the json like this:

client.info().send().await?.json::<ClusterInfo>().await?

But according to this, we shouldn't modify the file, so what will be the best way to go about it. Do we add this to the code generation ? . And if we do, do we create a module where we store the structure of possible typed responses, thereby setting a foundation for more type safety ?

Issues Resolved

#94

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

Merging #187 (90db4b0) into main (5a70fe5) will decrease coverage by 0.05%.
Report is 2 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #187      +/-   ##
==========================================
- Coverage   73.86%   73.82%   -0.05%     
==========================================
  Files         401      402       +1     
  Lines       63702    63733      +31     
==========================================
- Hits        47055    47049       -6     
- Misses      16647    16684      +37     

Flag	Coverage Δ
integration	73.82% <ø> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 13 files with indirect coverage changes

[dblock]

There's some mention of generating APIs from spec in https://github.com/opensearch-project/opensearch-rs/blob/main/DEVELOPER_GUIDE.md#cargo-make. I think we need something more thorough that explains how code generation works, where the templates are, etc.

[samuelorji]

There's some mention of generating APIs from spec in https://github.com/opensearch-project/opensearch-rs/blob/main/DEVELOPER_GUIDE.md#cargo-make. I think we need something more thorough that explains how code generation works, where the templates are, etc.

Thanks for the review, do you think it's better to add concrete types to the code generator, or make it static in the opensearch module ?

[samuelorji]

@dblock , I'm thinking of adding a models.rs file to the opensearch where concrete json response types can live. Will that be a good idea

[dblock]

I don't know enough about this to answer @samuelorji, but I bet @Xtansia does?

[Xtansia]

The generator will need at least 2 stages, first modifying the existing generator to read OpenAPI specs rather than legacy ones, then modify generator to generate request/response bodies. The generation of req/resp bodies is somewhat distant due to the spec not-yet containing all the information for them and we'd want to carefully consider and design how we'd tie the body types to the request actions.

As such I think it's fine to add some hand-written body structures now that users can take advantage of if it improves DX sooner, we'll just need to put them in separate files (may want to re-organize the layout into folders?) and modify the generator template to re-export the types out of the correct module (via pub use)

[Xtansia]

This should not be inside the http module, as it's not specific to the http implementation/transport layer.

I'd maybe lay it out something like:

opensearch
|- src
    |- models
        |- mod.rs

Because then we can also eventually put namespace specific models like for cluster etc under models

[Xtansia]

Let's rename this to InfoResponse so it's a bit more obvious what action it relates to.

[Xtansia]

Remove this blank line

[Xtansia]

Most other clients (and server) refer to this as OpenSearchVersionInfo

[Xtansia]

Looks good, you just need to add a line to the CHANGELOG.md file under the ### Added header, following the format of the other lines ie. - Added InfoResponse structure ([#pr](https://....))