Hi all, I've been meaning to reply to this thread. Volodymyr, your reply reminded me :)
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: https://github.com/terraform-providers/terraform-provider-openstack/tree/master/openstack Each file that begins with "resource" and ends in "_test.go" will contain various scenarios at the bottom. For example, compute instances: https://github.com/terraform-providers/terraform-provider-openstack/blob/master/openstack/resource_openstack_compute_instance_v2_test.go#L637-L1134 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. Thanks, Joe On Fri, Dec 15, 2017 at 12:43 AM, Volodymyr Litovka <doka...@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). > > Thanks. > > > 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/ > spreadsheets/d/1cdzFeV5I4Wk9FK57yqQmp5JJdGfKzEOdB3Vtt9vnVJM/edit#gid=0 > > -- > Kind regards, > > Melvin Hillsman > mrhills...@gmail.com > mobile: (832) 264-2646 > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@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-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
