Open Stack

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)