[Openstack-operators] [Openstack] Certifying SDKs
joe at topjian.net
Fri Dec 15 19:45:29 UTC 2017
I've been meaning to reply to this thread. Volodymyr, your reply reminded
I agree with what you said that the SDK should support everything that the
API supports. In that way, one could simply review the API reference docs
and create a checklist for each possible action. I've often thought about
doing this for Gophercloud so devs/users can see its current state of
what's supported and what's missing.
But Melvin highlighted the word "guaranteed", so I think he's looking for
the most common scenarios/actions rather than an exhaustive list. For that,
I can recommend the suite of Terraform acceptance tests. I've added a test
each time a user has either reported a bug or requested a feature, so
they're scenarios that I know are being used "in the wild".
You can find these tests here:
Each file that begins with "resource" and ends in "_test.go" will contain
various scenarios at the bottom. For example, compute instances:
This contains tests for:
* Basic launch of an instance
* Able to add and remove security groups from an existing instance
* Able to boot from a new volume or an existing volume
* Able to edit metadata of an instance.
* Able to create an instance with multiple ephemeral disks
* Able to create an instance with multiple NICs, some of which are on the
same network, some of which are defined as ports.
Terraform is not an SDK, but it's a direct consumer of Gophercloud and is
more user-facing, so I think it's quite applicable here. The caveat being
that if Terraform or Gophercloud does not support something, it's not
available as a test. :)
Melvin, if this is of interest, I can either post a raw list of these
tests/scenarios here or edit the sheet directly.
On Fri, Dec 15, 2017 at 12:43 AM, Volodymyr Litovka <doka.ua at gmx.com> wrote:
> Hi Melvin,
> isn't SDK the same as Openstack REST API? In my opinion (can be erroneous,
> though), SDK should just support everything that API supports, providing
> some basic checks of parameters (e.g. verify compliancy of passed parameter
> to IP address format, etc) before calling API (in order to decrease load of
> Openstack by eliminating obviously broken requests).
> On 12/11/17 8:35 AM, Melvin Hillsman wrote:
> Hey everyone,
> On the path to potentially certifying SDKs we would like to gather a list
> of scenarios folks would like to see "guaranteed" by an SDK.
> Some examples - boot instance from image, boot instance from volume,
> attach volume to instance, reboot instance; very much like InterOp works to
> ensure OpenStack clouds provide specific functionality.
> Here is a document we can share to do this - https://docs.google.com/
> Kind regards,
> Melvin Hillsman
> mrhillsman at gmail.com
> mobile: (832) 264-2646
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Volodymyr Litovka
> "Vision without Execution is Hallucination." -- Thomas Edison
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators