| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 16:08:46 | elmiko | mrhillsman or gtema, did either of you have any questions or ideas that we might consider for the next time we all meet up? | |
| 16:09:28 | gtema | I don't. But I agree there should be some plan on what to do | |
| 16:10:01 | gtema | what we want to achieve is clear, but what would be the steps is not | |
| 16:10:08 | elmiko | ++ | |
| 16:10:13 | mrhillsman | i pretty much laid out where i stand on things in the original post; just not particularly versed at laying out the steps | |
| 16:10:23 | mrhillsman | yes exactly | |
| 16:10:26 | edleafe | Is the general idea to come up with a validation suite of tests to run against the various SDKs? | |
| 16:11:33 | gtema | I understand it as yes, but also to laying out results of validations to public. Isn't it mrhillsman? | |
| 16:11:33 | mrhillsman | https://ethercalc.org/q4nklltf21nz | |
| 16:12:11 | mrhillsman | that is the current items working with gophercloud we were able to come up with | |
| 16:12:47 | mrhillsman | the key being the outcome/scenarios in the first column | |
| 16:12:57 | elmiko | looks like a decent starting point | |
| 16:13:09 | mrhillsman | someone getting that to https://www.openstack.org/software/project-navigator/sdks | |
| 16:13:28 | edleafe | mrhillsman: Sure, those are reasonable expectations for any SDK. What I'm wondering is if there is any thought about something that could be run for all languages. FWIW, I have no idea how to achieve that :) | |
| 16:14:30 | mrhillsman | chris hoge tossed out the idea of a state machine - i am not sure what that is | |
| 16:14:34 | mrhillsman | but my understanding is | |
| 16:15:44 | openstackgerrit | Merged openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115 | |
| 16:16:16 | mrhillsman | create VM with devstack, drop SDK on it, check state of cloud, run SDKs acceptance tests, check state of cloud, validate against expected scenarios, but yes, no actual implementation has been tried | |
| 16:16:56 | elmiko | that sounds reasonable, i imagine some sort of zuul scenario for testing all the different permutations | |
| 16:17:09 | mrhillsman | i think because every SDK is different, it would be quite difficult to have something run for all languages | |
| 16:17:45 | elmiko | i would think you would need to make explicit tests for each sdk, is this something that the individual sdk teams might take on or would there need to be an "sdk test master" or something? | |
| 16:18:02 | gtema | that's clear, that one size fits all does not exist here, but I think the acceptance should try to test same things | |
| 16:18:09 | elmiko | right | |
| 16:18:13 | edleafe | mrhillsman: there would also have to be many intermediate checks, not just end state | |
| 16:18:53 | mrhillsman | i think there could be parameters around the end state | |
| 16:19:41 | mrhillsman | like for scenario create VM which links to read VM could be create VM with name cloud and then read (check) for VM with name cloud | |
| 16:19:55 | edleafe | One thing I would also like to see: for each action in the validation suite, a link to the docs for that SDK that explain how to do that particular action | |
| 16:20:17 | mrhillsman | += | |
| 16:20:21 | mrhillsman | ++ | |
| 16:20:23 | gtema | ++ | |
| 16:21:19 | mrhillsman | i think one additional consideration is how to incentivize these existing SDKs | |
| 16:21:42 | mrhillsman | is being listed on the project navigator enough? | |
| 16:22:00 | edleafe | Maybe offer candy? :) | |
| 16:22:06 | mrhillsman | or being labeled officially-supported vs community-maintained | |
| 16:22:06 | elmiko | depends how motivated the teams are ;) | |
| 16:22:13 | mrhillsman | i.e. https://kubernetes.io/docs/reference/using-api/client-libraries/ | |
| 16:22:49 | elmiko | project tags have been thrown around before as a sort of "carrot" approach, i'm not sure if it every really caught on though | |
| 16:22:51 | mrhillsman | one push back i got was around this a year or so ago, just something to think about, let me not sidetrack previous discussion | |
| 16:24:12 | mrhillsman | i do have one question - how do we define an SDK - is that a thing we should pin down? | |
| 16:24:20 | edleafe | I tend to think of this validation as a way for an SDK team to prioritize development, and not so much a "marketing" advantage. People use SDKs because they do the job, not because of some label. | |
| 16:24:40 | elmiko | edleafe: ++ | |
| 16:24:44 | mrhillsman | ++ | |
| 16:25:01 | gtema | definitely | |
| 16:26:28 | edleafe | As far as a definition goes, I don't feel it's that important to pin down exactly. They are language-specific wrappers around the OpenStack HTTP API. | |
| 16:27:07 | edleafe | People use them so that everyone writing an app that uses OpenStack in, say, golang, doesn't have to re-invent all the exception handling, retries, etc. | |
| 16:28:04 | mrhillsman | i agree with that definition; asked because some folks as i have been working on this consider terraform an SDK | |
| 16:28:48 | gtema | ?? - SDK is a binding for a programming language, not to the specific tool | |
| 16:29:05 | elmiko | gtema: ++ | |
| 16:29:15 | elmiko | that's how i interpret it also | |
| 16:30:01 | elmiko | since we aren't getting into guidance for sdks, and mainly sticking with testing and related topics for now, i don't think the definition is quite as important | |
| 16:30:09 | edleafe | yeah, terraform sounds more like Heat | |
| 16:30:18 | elmiko | that said, are the terraform folks looking to have their stuff in this test infra? | |
| 16:30:50 | mrhillsman | as a user i would like to know a popular tool like terraform works with openstack | |
| 16:31:10 | mrhillsman | or rather what does/does not work | |
| 16:31:16 | mrhillsman | as an example | |
| 16:31:17 | elmiko | that's fair | |
| 16:31:33 | gtema | mrhillsman: I know, my users have same desire. But those are tools using an SDK | |
| 16:31:34 | mrhillsman | i think however this is phase one | |
| 16:31:38 | mrhillsman | and should be language bindings | |
| 16:31:43 | mrhillsman | not something like terraform | |
| 16:31:52 | gtema | so here we can have 2 tables: SDKs and tools (like Ansible/Terraform) | |
| 16:31:55 | elmiko | mrhillsman: ++ | |
| 16:31:57 | edleafe | mrhillsman: that's certainly valuable info for a potential terraform user, but it really isn't an SDK | |
| 16:32:06 | mrhillsman | ^ | |
| 16:32:16 | edleafe | gtema: yeah, good point - it's a tool, not an SDK | |
| 16:32:20 | mrhillsman | totally agree | |
| 16:32:41 | mordred | ++ | |
| 16:32:52 | mordred | same thing with openstacksdk and ansible-openstack-modules | |
| 16:33:08 | mrhillsman | just want to be sure so when i get questions i can communicate properly | |
| 16:33:14 | edleafe | looking at terraform, they say: "This provider uses Gophercloud as the Go OpenStack SDK. All API interaction between this provider and an OpenStack cloud is done exclusively with Gophercloud. | |
| 16:33:14 | mordred | one depends on the other - but the ansible users don't really care about the sdk as much as the modules | |
| 16:33:27 | mrhillsman | i am willing to bet you all will get similar question(s) | |
| 16:33:31 | elmiko | mrhillsman: i think the position of starting small with the actual sdks is a good position | |
| 16:33:35 | edleafe | So terraform is an app that is built using the Gopherclooud SDK | |
| 16:33:35 | mordred | ++ | |
| 16:34:05 | mordred | edleafe: in the fullness of time I think we need a new word other than APP for terraform and ansible in this context | |
| 16:34:14 | mordred | but for now I think that's a fine sentence | |
| 16:34:16 | gtema | edleafe: yes, which might still not use all of the SDK caps | |
| 16:34:27 | edleafe | s/app/program ? | |
| 16:34:33 | edleafe | s/app/tool ? | |
| 16:34:41 | mordred | well - mostly that it's a $something that people use to build their actual thing | |
| 16:34:45 | mrhillsman | would it be reasonable to action updating the project navigator to have under the SDKs header, "SDKs are language-specific wrappers around the OpenStack HTTP API." | |
| 16:35:03 | edleafe | mrhillsman: that sounds about right | |
| 16:35:15 | elmiko | ++ | |
| 16:35:17 | gtema | ++ | |
| 16:35:18 | mordred | so it's sdk -> $something (terraform,ansible) -> end-user-app | |
| 16:35:20 | mordred | mrhillsman: ++ | |
| 16:35:27 | edleafe | the one thing is that an SDK can also be opinionated | |
| 16:35:33 | mrhillsman | i know it is a small thing but i think it can help set scope for now | |
| 16:35:42 | mrhillsman | ok thx | |
| 16:35:56 | mordred | edleafe: I don't know of any sdk's that fit that description :) | |
| 16:36:00 | edleafe | IOW, it might choose not to support every single microversion that Nova ever released. It might choose to use a specific microversion, and possibly update it later | |
| 16:36:17 | mordred | it might choose to not expose the concept of microversions to the end user at all | |
| 16:36:25 | edleafe | mordred: 'zactly | |
| 16:36:37 | edleafe | IOW, it's not 1:1 to the HTTP API | |
| 16:36:44 | mordred | but - regardless of how it does it - it's still a wrapper around the HTTP API | |
| 16:36:48 | mrhillsman | ^ | |
| 16:36:52 | mordred | so I think mrhillsman's sentence is still good | |
| 16:37:25 | mordred | gophercloud has to do some transforms because of the nature of go | |
| 16:37:34 | mordred | it's inevitable anywhere | |