| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-20 | |||
| 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 | |
| 14:51:59 | tobiash | frickler: thanks, I can confirm that latest master fixes my issue :) | |
| 14:55:57 | frickler | tobiash: thanks for confirming, we should get a release for that early next year, then. | |
| 14:56:22 | tobiash | thanks | |
| 15:12:23 | mordred | frickler, tobiash: oh good. I was worried it was another sdk fail | |
| 16:01:51 | slaweq | dtroyer: hi, can You take a look at backport of https://review.openstack.org/#/c/624191/1/ if You will have time? | |
| 16:01:54 | slaweq | thx in advance | |
| 16:32:27 | finucannot | Given the sheer amount of bugs in argparse, I'm really starting to think we should just vendor it for cliff | |
| 16:33:17 | finucannot | The latest beauty: not being able to combine optionals with varying amounts of arguments and positionals https://bugs.python.org/issue9338 | |
| 16:50:22 | openstackgerrit | Stephen Finucane proposed openstack/python-openstackclient master: Make 'destination' optional for live migration https://review.openstack.org/626949 | |
| 23:59:11 | openstackgerrit | Merged openstack/python-openstackclient master: More volume functional test fixes https://review.openstack.org/626020 | |
| #openstack-sdks - 2018-12-24 | |||
| 12:00:03 | openstackgerrit | Merged openstack/python-openstackclient master: Support enable/disable uplink status propagation https://review.openstack.org/586684 | |
| 14:27:49 | openstackgerrit | Kailun Qin proposed openstack/python-openstackclient master: Add network segment range command object https://review.openstack.org/625544 | |
| 16:42:24 | openstackgerrit | Merged openstack/os-client-config master: Use template for lower-constraints https://review.openstack.org/626703 | |