search

MaximilianKoestler / hcloud-openapi

This is the unofficial OpenAPI description of the Hetzner Cloud API. It allows automatic code generation for the hcloud API.
MIT License
29 stars 5 forks source link

Images and volumes can be "unavailable" #14

Closed jcgruenhage closed 2 years ago

jcgruenhage commented 2 years ago

We have an issue over at https://gitlab.com/famedly/company/devops/tools/hcloud-prom-filesd/-/issues/4, where some servers cause problems in here, because the image that they were created from has been removed since. This means that the image has the status "unavailable", which causes serde to fail parsing the response.

I've checked the official OpenAPI spec, and it does support this properly. Considering that an official OpenAPI spec does exist now, what's still the purpose of this project? Not trying to be condescending here, I'm actually interested in what reasons still exist (because I'm nearly sure that there are reasons).

MaximilianKoestler commented 2 years ago

@jcgruenhage I will take a look and try to update the spec as soon as I have time - probably no later then the weekend.

I would love this project to be obsolete, but unfortunately the official OpenAPI spec was not suited for code generation when it was released and it looks like that has not improved. The official spec does not use components and therefore the code generator cannot determine if multiple path queries use the same objects. This is what the project provides. With this spec you will get the same type of object, no matter whether you query a list of servers or just a single one and that is not the case with the official spec (assuming the OpenAPI code generator has not significantly improved in this area by now).

jcgruenhage commented 2 years ago

Right, that makes sense. I did notice that I couldn't find the models separately from the requests themselves, but didn't think of considering that that might be because of that :D

Thanks for your work on this! If this was done until next weed, that'd be great, but no rush here, that was already open on our side for months, before we investigated what the problem was :D

MaximilianKoestler commented 2 years ago

@jcgruenhage I have just pushed release v0.5.0 that fixes this issue. The relevant commit for you is actually already from June, I just never had made a release from it.

The release of the Rust crate will follow shortly.

There were some major breaking changes in Hetzners own spec (see release notes) that I could not prevent from having an impact on the unofficial spec. If they prove to be relevant for your application, you should get pretty straightforward compiler errors that will guide you to resolve the issues.

MaximilianKoestler commented 2 years ago

I will close this issue now, feel free to reopen it if there are further changes required.