Re: [Openstack] [Openstack-operators] Certifying SDKs
+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
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
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
Re: [Openstack] Neutron/OpenVswitch problem
Hi again I've discovered that this error in raised only when the environment has neutron-fwaas extension enabled. Without it, everything is ok. Any ideas on the relation between fwaas and /Port not present in bridge br-int /? On 14/12/17 18:54, magicb...@gmail.com wrote: Hi everyone, I'm testing the upgrade process from Ocata to Pike in lab, and after upgrading the environment, when I try to launch a new instance, nova fails to launch the instance. nova-compute.log reports: /BuildAbortException: Build of instance a7054a4a-7d4a-49f0-ba32-1507d271822b aborted: Failed to allocate the network(s), not rescheduling. / neutron-openvswitch-agent.log /INFO neutron.agent.common.ovs_lib [req-a8a13dca-330f-4e18-ac2c-7a7aac98aa3d - - - - -] Port 932c5eb6-210f-42c4-a2c4-df47fe8a1834 not present in bridge br-int/ Anyone can give a clue? :) Thanks in advance, J. ___ 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] Help needed to understand keystone
Hi Chengwei, You can create as much roles as you want and create/modify rules in policy.json (can be found in /etc/keystone and other configuration directories of Openstack modules) to put these roles into reality And there is no notion 'project admin'. Unfortunately, in Keystone everybody who has role 'admin' is entire Openstack admin, not project's. Be aware :) On 10/19/17 8:22 AM, Chengwei Yang wrote: Hi list, I'm recently learn keystone and got some questions below, thanks any reply in advance! 1. It seems that there are only 2 kinds of roles, regardless how many roles you created, all of them should be non-admin or admin, am I right? 2. If I was wrong, how to create a role with specific capabilities? 3. Is it possible to assign some project admin privileges to user or group? so far I see only the admin created by keystone-bootstrap with capabilities to manage project(create, delete and etc.) ___ 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
