On Thu, 6 Dec 2018, 19:12 Melvin Hillsman, <mrhillsman@gmail.com> wrote:

Hi everyone,

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)

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?

As a representative of a public cloud operator I say yes. It definitely makes sense to let users know, which SDKs are certified to work to have understanding what they can use. However then comes the question, that each public operator has own "tricks" and possibly even extension services, which make SDK behave not as expected. I do really see a need to provide a regular way in each of those SDKs to add and (I really don't want this, but need unfortunately) sometimes override services implementation if those are changed in some way.

So the certification make sense, but the CI question probably goes in the direction of OpenLab

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?

Both has pro and cons, but I am neutral here

3. Bi-weekly discussions a good cadence?

Yes. The regular communication is a requirement.

 

4. Who is interested in tackling this together?

I do, but not alone

[0] https://etherpad.openstack.org/p/BER-better-expose-what-we-produce

[1] https://etherpad.openstack.org/p/BER-sdk-certification

[2] https://docs.google.com/spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vtt9vnVJM

--

Kind regards,

Melvin Hillsman

mrhillsman@gmail.com
mobile: (832) 264-2646

Regards,

Artem Goncharov

gtema

OpenTelekomCloud