| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 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 | elmiko | depends how motivated the teams are ;) | |
| 16:22:06 | mrhillsman | or being labeled officially-supported vs community-maintained | |
| 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 | mordred | one depends on the other - but the ansible users don't really care about the sdk as much as the modules | |
| 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: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 | mordred | ++ | |
| 16:33:35 | edleafe | So terraform is an app that is built using the Gopherclooud SDK | |
| 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 | |
| 16:38:04 | mordred | although some of us are more aggressive than others | |
| 16:39:22 | mrhillsman | hehe | |
| 16:39:26 | edleafe | mordred: hence the term "opnionated". A Python SDK might want to do things more Pythonically than a Go SDK (and that's a good thing) | |
| 16:39:33 | mrhillsman | i'll take the action of patch for navigator page | |
| 16:40:40 | elmiko | i don't think we need to add "opinionated" in the description though, i like the way mrhillsman put it | |
| 16:40:49 | mrhillsman | ++ | |
| 16:41:23 | edleafe | elmiko: sure. I just brought it up because that was an issue when I wrote pyrax. | |
| 16:41:29 | mordred | yeah - in the future I could see making some distinctions between more direct api wrappers and api abstractions - that might be useful to end users | |
| 16:41:57 | elmiko | edleafe: ack | |
| 16:42:16 | elmiko | edleafe: were you asked to make it unopinionated or something? | |
| 16:42:18 | edleafe | Developers in $LANGUAGE don't care about the API; they care about getting things done in $LANGUAGE | |
| 16:42:19 | mordred | in fact- developing words there would help me talk about the different layers in openstacksdk - since we have complete passthrough REST calls, a more direct api mapping, and an aggressive abstraction layer | |
| 16:42:23 | mordred | edleafe: yup | |
| 16:42:54 | elmiko | that totally makes sense to me edleafe | |
| 16:42:59 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Rework orchestration to add update preview https://review.openstack.org/621154 | |
| 16:43:04 | mordred | if they cared about the REST API itself, they'd use a direct rest client | |
| 16:43:11 | elmiko | right | |