Re: [Openstack] [Openstack-operators] Certifying SDKs

2017-12-15 Thread 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
mrhills...@gmail.com
mobile: +1 (832) 264-2646
irc: mrhillsman

On 12/15/17, 1:53 PM, "Davanum Srinivas"  wrote:

Joe,

+1 to edit the sheet directly.

Thanks,
Dims

On Fri, Dec 15, 2017 at 2:45 PM, Joe Topjian  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  
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
>>
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



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

Re: [Openstack] [Openstack-operators] Certifying SDKs

2017-12-15 Thread Davanum Srinivas 
Joe,

+1 to edit the sheet directly.

Thanks,
Dims

On Fri, Dec 15, 2017 at 2:45 PM, Joe Topjian  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  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
>>
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



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

___
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

Re: [Openstack] [Openstack-operators] Certifying SDKs

2017-12-15 Thread Joe Topjian 
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  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