Melvin Hillsman wrote:
We have spent some time working to get an idea of what official SDKs would look like. We had some sessions during the Berlin summit[0][1] and there was a lot of great feedback.
Currently the following SDKs are generally considered usable for their respective language; there are others of course:
openstacksdk (Python) gophercloud (Go) pkgcloud (JavaScript) openstack4j (Java) rust-openstack (Rust) fog-openstack (Ruby) php-opencloud (PHP)
As a sidenote, we also want to show those SDKs on openstack.org/software alongside openstacksdk, so having validation that they actually do what they are supposed to do is really critical.
After many discussions it seems SDK validation essentially should be about confirming cloud state pre/post SDK interaction rather than API support. An example is that when I use pkgcloud and ask that a VM be created, does the VM exist, in the way I asked it exist, rather than are there specific API calls that are being hit along the way to creating my VM.
I am putting this email out to keep the community informed of what has been discussed in this space but also and most importantly to get feedback and support for this work. It would be great to get a set of official and community SDKs, get them setup with CI testing for validation (not changing their current CI for unit/functional/acceptance testing; unless asked to help do this), and connect the results to the updated project navigator SDK section. A list of scenarios has been provided as a good starting point for cloud state checks.[2]
Essentially the proposal is to deploy OpenStack from upstream (devstack or other), stand up a VM within the cloud, grab all the SDKs, run acceptance tests, report pass/fail results, update project navigator. Of course there are details to be worked out and I do have a few questions that I hope would help get everyone interested on the same page via this thread.
1. Does this make sense?
Yes.
2. Would folks be interested in a SDK SIG or does it make more sense to request an item on the API SIG's agenda?
As others mentioned, there is lots of overlap between API SIG and SDK work, but that would be a stretch of the API SIG mission, which they might or might not be interested in doing. If they'd rather have the groups separated, I still think the SIG group format applies better than a "workgroup" as caring about SDKs and their quality will be an ongoing effort, it's not just about setting up tests and then forgetting about them. So I'd encourage the formation of a SDK SIG if that work can't be included in the existing API SIG.
3. Bi-weekly discussions a good cadence?
No strong opinion, but bi-weekly sounds good.
4. Who is interested in tackling this together?
As mentioned above, I'll be involved in the promotion of the result of that effort, by making sure the openstack.org/software pages evolve a way to list "verified" SDKs alongside the one that is produced locally. -- Thierry Carrez (ttx)