Earlier  
Posted Nick Remark
#openstack-sdks - 2018-12-20
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!
17:02:13 gtema thanks elmiko, you too
17:02:37 gtema edleafe, bye
18:39:39 openstackgerrit Merged openstack/python-openstackclient master: Add osc repo to the base job definition https://review.openstack.org/626590
19:51:20 openstackgerrit Andreas Jaeger proposed openstack/cliff master: Use template for lower-constraints https://review.openstack.org/626673
20:03:20 frickler mordred: if I read the failure correctly, we need to revert the pin in sdk first, and reqs after that? so the other way round than what the deps say now. http://logs.openstack.org/93/624993/6/check/requirements-tox-py27-check-uc/c854690/
20:03:59 openstackgerrit Andreas Jaeger proposed openstack/keystoneauth master: Use template for lower-constraints https://review.openstack.org/626691
20:09:02 mordred frickler: oh - you're probably right about that
20:12:24 openstackgerrit Andreas Jaeger proposed openstack/osc-lib master: Use template for lower-constraints https://review.openstack.org/626702
20:13:12 openstackgerrit Andreas Jaeger proposed openstack/os-client-config master: Use template for lower-constraints https://review.openstack.org/626703
22:52:11 openstackgerrit Merged openstack/cliff master: Use template for lower-constraints https://review.openstack.org/626673
23:16:38 openstackgerrit Merged openstack/osc-lib master: Use template for lower-constraints https://review.openstack.org/626702
#openstack-sdks - 2018-12-21
00:26:47 openstackgerrit Merged openstack/python-openstackclient master: Update the URL in doc https://review.openstack.org/604632
01:36:49 openstackgerrit Merged openstack/python-openstackclient master: Remove testr.conf as it's been replaced by stestr https://review.openstack.org/626492
03:14:43 openstackgerrit Merged openstack/keystoneauth master: Use template for lower-constraints https://review.openstack.org/626691
08:53:03 openstackgerrit Jens Harbott (frickler) proposed openstack/openstacksdk master: Unpin dogpile.cache https://review.openstack.org/625759
14:36:50 tobiash mordred: I just tried to install the openstackclient into a fresh venv (mac os, py37) and 'openstack server list' fails with this: http://paste.openstack.org/show/737821/
14:37:02 tobiash it pulled in openstacksdk 0.22.0
14:38:11 tobiash image list works however
14:44:00 frickler tobiash: oh, I think that that is a known py37 issue. let me see if we have a patch for that somewhere
14:46:52 frickler tobiash: https://review.openstack.org/618137 , not sure whether this has been released yet
14:47:55 tobiash frickler: ah thanks :)
14:49:34 tobiash frickler: the last release is 5 months ago so probably not

Earlier   Later