| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 16:03:15 | elmiko | that said, if you would like to represent the sdk side of the house within the api-sig then i am all for it =) | |
| 16:03:28 | gtema | elmiko: it's not a problem | |
| 16:03:55 | mrhillsman | o/ | |
| 16:03:56 | gtema | from what I see dtantsur is also part of API-SIG and an SDK core | |
| 16:04:07 | elmiko | yes | |
| 16:04:08 | edleafe | yes, he is | |
| 16:04:20 | elmiko | hey mrhillsman | |
| 16:04:57 | elmiko | gtema: i would imagine that we will continue with the office hours pattern in the near term, but if the need arises for us to organize more (especially around sdk work), then it seems perfectly acceptable for us to discuss starting a meeting time again | |
| 16:05:15 | gtema | sure, no problem | |
| 16:05:44 | gtema | until the Jan there would not be any real work anymore ;-) | |
| 16:06:03 | edleafe | gtema: what general time zone are you in? | |
| 16:06:09 | elmiko | i'm not sure if you or mrhillsman have any ideas about information you might want up on the api-sig wiki or specs site (i know we have lots of sdk stuff up on the web), but it would be great to create some linkages and maybe add something about sdks to the sig charter | |
| 16:06:16 | gtema | Germany (GMT+1/2) | |
| 16:06:41 | edleafe | ok, so closer to dtantsur's schedule | |
| 16:06:45 | gtema | yupp | |
| 16:06:47 | elmiko | gtema: yeah, no real work until after holidays. i was hoping we could do a meet and greet today =) | |
| 16:06:57 | gtema | sure | |
| 16:07:46 | elmiko | great, i look forward to the new year and hopefully getting some sdk activity in the sig | |
| 16:07:50 | mrhillsman | i am utc-6 until march 10, 2019 then i'll be utc-5 | |
| 16:08:18 | elmiko | ack | |
| 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 | mrhillsman | https://ethercalc.org/q4nklltf21nz | |
| 16:11:33 | gtema | I understand it as yes, but also to laying out results of validations to public. Isn't it mrhillsman? | |
| 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 | 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 ? | |