Re: [Openstack-operators] [Openstack] 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 : openst...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



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

Re: [Openstack-operators] [Openstack] 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 : openst...@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



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

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack] 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 : openst...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] Certifying SDKs

2017-12-14 Thread 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.


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

___
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-operators] [Openstack] Certifying SDKs

2017-12-14 Thread 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.


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 : openst...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] Certifying SDKs

2017-12-10 Thread 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.

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