Earlier  
Posted Nick Remark
#openstack-sdks - 2018-12-20
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
16:58:32 mrhillsman so just wait until the 10th gtema?
16:58:44 gtema yupp, that would be better
16:58:46 mrhillsman or sig leads?
16:59:13 mrhillsman ++
16:59:23 mrhillsman thx for the time it was great; ttyl
16:59:30 edleafe Thanks for coming!
16:59:34 elmiko mrhillsman: glad to help =)
16:59:41 mrhillsman really appreciate it
16:59:49 elmiko and in the new year we should add gtema to the official roster of the sig
17:01:57 elmiko later edleafe mordred gtema mrhillsman , have a nice holiday and new year =)
17:02:11 edleafe As the hour is up for the Office Hour, and I have to be somewhere soon, I'll see everyone in API and SDK land next year!
17:02:11 mrhillsman same to you!

Earlier   Later