| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 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 | |
| 16:49:28 | edleafe | Some people don't care about those things - they just want to spin up a VM, or store a blob | |
| 16:50:00 | edleafe | Having these validation tests would show what each SDK could do | |
| 16:50:53 | mordred | yeah. if you're writing a multi-cloud thing, libcloud might make your life much easier | |
| 16:51:22 | mordred | if I had more time, I'd start sending libcloud patches to use openstacksdk for their underlying layer and let them just be the mutli-cloud-abstraction layer - but I do not have such time | |
| 16:51:39 | gtema | :D | |
| 16:51:41 | mordred | same thing with jclouds vs openstack4j | |
| 16:52:04 | elmiko | what is this "more time" thing you speak of, it is an alien concept to me XD | |
| 16:52:29 | mordred | it seems like people are leaning more towards use of cloud-specific libraries with app plugins - sort of like how terraform uses gophercloud and doesnt' try to use a cloud abstraction layer | |
| 16:52:37 | mordred | elmiko: ikr? | |
| 16:53:04 | mordred | becausr the cloud specific libraries can do a better job of taking advantage of features of the cloud to provide features of the app | |
| 16:53:42 | mordred | the multi-cloud-libraries seemed to be much more popular several years ago - but that's a totally unsupported by science | |
| 16:54:25 | mrhillsman | hehe | |
| 16:54:45 | elmiko | lol | |
| 16:54:50 | mrhillsman | have we identified any next steps? | |
| 16:54:59 | mrhillsman | i know i have the project nav update | |
| 16:55:10 | mrhillsman | no meeting next thursday? | |
| 16:55:16 | mrhillsman | or office hours rather | |
| 16:55:19 | edleafe | Not for the next 2 weeks for me | |
| 16:55:43 | edleafe | Next one for me is Jan 10th | |
| 16:56:08 | elmiko | edleafe: ++ | |
| 16:56:25 | mrhillsman | gtema i will follow your lead, next thursday is probably ok for me but not the 3rd | |
| 16:56:34 | mrhillsman | too close to the 1st :) | |
| 16:57:41 | gtema | mrhillsman: I would also like to skip next week, since I am moving to another house | |
| 16:57:44 | mrhillsman | sorry flip that | |
| 16:58:01 | mrhillsman | ok great | |