| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 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 | |
| 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 | |
| 16:43:30 | mordred | (which, it turns out, is totally ok!) | |
| 16:43:44 | elmiko | i just feel like /all/ SDKs are opinionated, which is why i'm kinda curious about edleafe's statement about pyrax =) | |
| 16:43:55 | mrhillsman | so another housekeeping thing, not sure how much time we have left, the SDKs themselves | |
| 16:43:59 | elmiko | mordred: 100% agree | |
| 16:44:18 | elmiko | mrhillsman: we hold office hours till the top of the hour | |
| 16:44:23 | mrhillsman | i think having more than one per language in terms of officially vs community supported statement earlier | |
| 16:44:40 | mrhillsman | as a user is painful | |
| 16:44:47 | gtema | sounds reasonable to me | |
| 16:45:01 | mrhillsman | in the initial post an sdk for each language was listed | |
| 16:45:10 | mrhillsman | no one pushed back on that list | |
| 16:45:54 | mrhillsman | any concern around having one per language | |
| 16:46:05 | edleafe | elmiko: it came up when I wrote the swift module. Their API had an inconsistency between calls to different things, and I didn't like that, so I standardized on what I thought was the more typical use case. | |
| 16:46:06 | mrhillsman | there is like 3 for java | |
| 16:46:40 | mrhillsman | if openstack4j declined in what it supports would libcloud become an officially supported because it did not | |
| 16:46:44 | elmiko | edleafe: makes good sense to me | |
| 16:47:17 | mrhillsman | just something to think about | |
| 16:47:22 | elmiko | mrhillsman: might make the list much easier to consume when we have a bar that says "above this line pass all tests, below not so much" XD | |
| 16:47:26 | gtema | one might want to use libcloud, which means 2 python | |
| 16:47:52 | mrhillsman | sorry, i meant jclouds | |
| 16:48:02 | mrhillsman | java v java | |
| 16:48:34 | edleafe | gtema: you bring up another point. There are OpenStack-specific SDKs in python, and then cross-cloud SDKs like libcloud | |
| 16:49:06 | edleafe | Obviously the cross-cloud won't do everything that an OpenStack-specific SDK would | |