Certifying SDKs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Certifying SDKs

Melvin Hillsman
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.


--
Kind regards,

Melvin Hillsman
[hidden email]
mobile: (832) 264-2646

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack] Certifying SDKs

Volodymyr Litovka
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.


--
Kind regards,

Melvin Hillsman
[hidden email]
mobile: (832) 264-2646


_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [hidden email]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack] Certifying SDKs

Joe Topjian-2
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".


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 <[hidden email]> 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.


--
Kind regards,

Melvin Hillsman
[hidden email]
mobile: <a href="tel:(832)%20264-2646" value="+18322642646" target="_blank">(832) 264-2646


_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [hidden email]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack] Certifying SDKs

Davanum Srinivas
Joe,

+1 to edit the sheet directly.

Thanks,
Dims

On Fri, Dec 15, 2017 at 2:45 PM, Joe Topjian <[hidden email]> wrote:

> 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 <[hidden email]> 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
>> [hidden email]
>> mobile: (832) 264-2646
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : [hidden email]
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>> --
>> Volodymyr Litovka
>>   "Vision without Execution is Hallucination." -- Thomas Edison
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> [hidden email]
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> [hidden email]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



--
Davanum Srinivas :: https://twitter.com/dims

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|

Re: [Openstack] Certifying SDKs

Melvin Hillsman
+1 to editing the sheet as well and because you are spot on with your assessment of what I meant; scenarios we can “guarantee” an SDK allows/affords a tool to deliver on.
--
Kind regards,

Melvin Hillsman
[hidden email]
mobile: +1 (832) 264-2646
irc: mrhillsman

On 12/15/17, 1:53 PM, "Davanum Srinivas" <[hidden email]> wrote:

    Joe,
   
    +1 to edit the sheet directly.
   
    Thanks,
    Dims
   
    On Fri, Dec 15, 2017 at 2:45 PM, Joe Topjian <[hidden email]> wrote:
    > 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 <[hidden email]> 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
    >> [hidden email]
    >> mobile: (832) 264-2646
    >>
    >>
    >> _______________________________________________
    >> Mailing list:
    >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
    >> Post to     : [hidden email]
    >> Unsubscribe :
    >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
    >>
    >>
    >> --
    >> Volodymyr Litovka
    >>   "Vision without Execution is Hallucination." -- Thomas Edison
    >>
    >>
    >> _______________________________________________
    >> OpenStack-operators mailing list
    >> [hidden email]
    >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
    >>
    >
    >
    > _______________________________________________
    > OpenStack-operators mailing list
    > [hidden email]
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
    >
   
   
   
    --
    Davanum Srinivas :: https://twitter.com/dims
   
    _______________________________________________
    OpenStack-operators mailing list
    [hidden email]
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
   



_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators