On Thu, Dec 6, 2018 at 12:30 PM Artem Goncharov <artem.goncharov@gmail.com> wrote:
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
Yes this is definitely something to consider; public cloud tricks and extensions. An idea that was floated is to have an upstream cloud to run against that passes all interop powered programs to run the SDKs against. Even though SDKs provide more coverage an SDK that works against a service that is certified should work in any cloud that is certified?
1. 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
Same, just wanted to get it out there and hopefully get API SIG members feedback so as not to hijack any of their agendas or creep on their scope without consent.
1. Bi-weekly discussions a good cadence?
Yes. The regular communication is a requirement.
1. Who is interested in tackling this together?
I do, but not alone
Haha, agreed, but we definitely should work on it and be consistent even if the initial set of folks is small. We have a large community to lean on and should rather than simply going at it 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/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vt...
-- Kind regards,
Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646
Regards, Artem Goncharov gtema OpenTelekomCloud
-- Kind regards, Melvin Hillsman mrhillsman@gmail.com mobile: (832) 264-2646