Open Stack

On Thu, Dec 6, 2018 at 12:30 PM Artem Goncharov <artem.goncharov at gmail.com>
wrote:

>
>
> On Thu, 6 Dec 2018, 19:12 Melvin Hillsman, <mrhillsman at 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/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vtt9vnVJM
>>
>>
>> --
>> Kind regards,
>>
>> Melvin Hillsman
>> mrhillsman at gmail.com
>> mobile: (832) 264-2646
>>
>
> Regards,
> Artem Goncharov
> gtema
> OpenTelekomCloud
>
>>

-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181206/3b42587e/attachment-0001.html>