Thursday, 2018-12-20

*** slaweq has quit IRC00:02
*** bobh has joined #openstack-sdks00:15
*** bobh has quit IRC00:20
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Start using direct REST in normalize tests
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase
openstackgerritMonty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server
*** tosky has quit IRC00:43
*** bobh has joined #openstack-sdks00:53
*** mriedem has quit IRC01:18
*** bobh has quit IRC01:25
*** bobh has joined #openstack-sdks01:26
openstackgerritMerged openstack/openstacksdk master: Properly munch for resource sub-dicts
*** bobh has quit IRC01:40
*** markvoelker has quit IRC01:50
*** bobh has joined #openstack-sdks01:54
openstackgerritjacky06 proposed openstack/os-api-ref master: Remove support for py34
*** bobh has quit IRC04:06
openstackgerritDou Rui Yuan proposed openstack/python-openstackclient master: Remove testr.conf as it's been replaced by stestr
*** mgagne has quit IRC06:33
*** mgagne has joined #openstack-sdks06:40
*** annp has joined #openstack-sdks06:48
*** cdent has joined #openstack-sdks07:42
*** gkadam has joined #openstack-sdks07:49
*** slaweq has joined #openstack-sdks07:52
*** gtema has joined #openstack-sdks08:07
*** gtema has quit IRC08:20
*** tosky has joined #openstack-sdks08:24
*** jpena|off is now known as jpena08:31
*** jpich has joined #openstack-sdks08:54
*** markvoelker has joined #openstack-sdks08:56
*** jpich has quit IRC09:04
*** jpich has joined #openstack-sdks09:05
*** jpich has quit IRC09:21
*** jpich has joined #openstack-sdks09:23
*** ttsiouts has joined #openstack-sdks09:26
*** e0ne has joined #openstack-sdks09:53
*** e0ne has quit IRC10:29
*** e0ne has joined #openstack-sdks10:30
*** ttsiouts has quit IRC11:10
*** ttsiouts has joined #openstack-sdks11:11
*** ttsiouts has quit IRC11:15
fricklershade-ansible job looks broken for a couple of days, did anyone look into that yet?
fricklermordred: I rebased for you, seems that that would still be relevant to have as test coverage11:30
*** dave-mccowan has quit IRC11:42
*** dave-mccowan has joined #openstack-sdks11:43
*** cdent_ has joined #openstack-sdks11:44
*** cdent has quit IRC11:46
*** cdent_ is now known as cdent11:46
*** ttsiouts has joined #openstack-sdks11:52
*** jpena is now known as jpena|lunch11:59
fricklermordred: this pins to ansible==2.5.0, which seems to have a broken "user" module functionality on bionic, so this is fallout of the devstack bionic change. pinning to "ansible<2.6", which seems to have more of the intended effect anyway, solves the issue on my test machine.,unified12:53
openstackgerritJens Harbott (frickler) proposed openstack-infra/shade master: Fix ansible stable pin in tox test
fricklermordred: Shrews: ^^ that should fix the test failures12:56
*** markvoelker has quit IRC13:12
openstackgerritRajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable
*** jpena|lunch is now known as jpena13:16
*** e0ne has quit IRC13:19
mordredfrickler: awesome! thanks13:22
*** gkadam has quit IRC13:25
*** e0ne has joined #openstack-sdks13:33
*** mriedem has joined #openstack-sdks13:38
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase
openstackgerritMonty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server
*** e0ne has quit IRC14:11
*** e0ne_ has joined #openstack-sdks14:11
*** ttsiouts has quit IRC14:33
*** ttsiouts has joined #openstack-sdks14:34
*** ttsiouts has quit IRC14:38
*** ttsiouts has joined #openstack-sdks14:43
openstackgerritJens Harbott (frickler) proposed openstack/python-openstackclient master: Add osc repo to the base job definition
fricklermordred: ^ seems this is needed for the devstack change14:51
*** gtema has joined #openstack-sdks14:54
mordredfrickler: +A - I think that's a clear enough change14:56
openstackgerritMerged openstack/openstacksdk master: Start using direct REST in normalize tests
*** mriedem is now known as mriedem_afk15:11
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations
openstackgerritMerged openstack-infra/shade master: Fix ansible stable pin in tox test
Shrewsmordred: remind me why our ansible tox test is pinned?15:48
Shrewsoh, that's shade15:50
mordredShrews: yeah- and it was to test master of shade against stable of ansible15:54
edleafehe last API-SIG Office Hour of 2018 has begun16:00
edleafe*The last16:00
elmikodid you see the email that Artem sent to the list?16:02
elmikoi think he may join us today, not sure though16:02
gtemaHi, I am here16:02
elmikowelcome =)16:02
elmikoso, as i mentioned in the email thread, we don't have a standing "meeting" anymore just these office hours16:02
edleafeHi gtema16:02
gtemaedleafe: hi16:03
elmikothat 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
gtemaelmiko: it's not a problem16:03
gtemafrom what I see dtantsur is also part of API-SIG and an SDK core16:03
edleafeyes, he is16:04
elmikohey mrhillsman16:04
elmikogtema: 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 again16:04
gtemasure, no problem16:05
gtemauntil the Jan there would not be any real work anymore ;-)16:05
edleafegtema: what general time zone are you in?16:06
elmikoi'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 charter16:06
gtemaGermany (GMT+1/2)16:06
edleafeok, so closer to dtantsur's schedule16:06
elmikogtema: yeah, no real work until after holidays. i was hoping we could do a meet and greet today =)16:06
elmikogreat, i look forward to the new year and hopefully getting some sdk activity in the sig16:07
mrhillsmani am utc-6 until march 10, 2019 then i'll be utc-516:07
elmikomrhillsman or gtema, did either of you have any questions or ideas that we might consider for the next time we all meet up?16:08
gtemaI don't. But I agree there should be some plan on what to do16:09
gtemawhat we want to achieve is clear, but what would be the steps is not16:10
mrhillsmani pretty much laid out where i stand on things in the original post; just not particularly versed at laying out the steps16:10
mrhillsmanyes exactly16:10
edleafeIs the general idea to come up with a validation suite of tests to run against the various SDKs?16:10
gtemaI understand it as yes, but also to laying out results of validations to public. Isn't it mrhillsman?16:11
mrhillsmanthat is the current items working with gophercloud we were able to come up with16:12
mrhillsmanthe key being the outcome/scenarios in the first column16:12
elmikolooks like a decent starting point16:12
mrhillsmansomeone getting that to
edleafemrhillsman: 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:13
mrhillsmanchris hoge tossed out the idea of a state machine - i am not sure what that is16:14
mrhillsmanbut my understanding is16:14
openstackgerritMerged openstack/openstacksdk master: Drop self.conn from base.TestCase
mrhillsmancreate 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 tried16:16
elmikothat sounds reasonable, i imagine some sort of zuul scenario for testing all the different permutations16:16
mrhillsmani think because every SDK is different, it would be quite difficult to have something run for all languages16:17
elmikoi 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:17
gtemathat's clear, that one size fits all does not exist here, but I think the acceptance should try to test same things16:18
edleafemrhillsman: there would also have to be many intermediate checks, not just end state16:18
mrhillsmani think there could be parameters around the end state16:18
mrhillsmanlike for scenario create VM which links to read VM could be create VM with name cloud and then read (check) for VM with name cloud16:19
edleafeOne 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 action16:19
mrhillsmani think one additional consideration is how to incentivize these existing SDKs16:21
mrhillsmanis being listed on the project navigator enough?16:21
edleafeMaybe offer candy? :)16:22
elmikodepends how motivated the teams are ;)16:22
mrhillsmanor being labeled officially-supported vs community-maintained16:22
elmikoproject tags have been thrown around before as a sort of "carrot" approach, i'm not sure if it every really caught on though16:22
mrhillsmanone push back i got was around this a year or so ago, just something to think about, let me not sidetrack previous discussion16:22
mrhillsmani do have one question - how do we define an SDK - is that a thing we should pin down?16:24
edleafeI 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
elmikoedleafe: ++16:24
edleafeAs 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:26
edleafePeople 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:27
mrhillsmani agree with that definition; asked because some folks as i have been working on this consider terraform an SDK16:28
gtema?? - SDK is a binding for a programming language, not to the specific tool16:28
elmikogtema: ++16:29
elmikothat's how i interpret it also16:29
elmikosince 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 important16:30
edleafeyeah, terraform sounds more like Heat16:30
elmikothat said, are the terraform folks looking to have their stuff in this test infra?16:30
mrhillsmanas a user i would like to know a popular tool like terraform works with openstack16:30
mrhillsmanor rather what does/does not work16:31
mrhillsmanas an example16:31
elmikothat's fair16:31
gtemamrhillsman: I know, my users have same desire. But those are tools using an SDK16:31
mrhillsmani think however this is phase one16:31
mrhillsmanand should be language bindings16:31
mrhillsmannot something like terraform16:31
gtemaso here we can have 2 tables: SDKs and tools (like Ansible/Terraform)16:31
elmikomrhillsman: ++16:31
edleafemrhillsman: that's certainly valuable info for a potential terraform user, but it really isn't an SDK16:31
edleafegtema: yeah, good point - it's a tool, not an SDK16:32
mrhillsmantotally agree16:32
*** mriedem_afk is now known as mriedem16:32
mordredsame thing with openstacksdk and ansible-openstack-modules16:32
mrhillsmanjust want to be sure so when i get questions i can communicate properly16:33
mordredone depends on the other - but the ansible users don't really care about the sdk as much as the modules16:33
edleafelooking 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
mrhillsmani am willing to bet you all will get similar question(s)16:33
elmikomrhillsman: i think the position of starting small with the actual sdks is a good position16:33
edleafeSo terraform is an app that is built using the Gopherclooud SDK16:33
mordrededleafe: in the fullness of time I think we need a new word other than APP for terraform and ansible in this context16:34
mordredbut for now I think that's a fine sentence16:34
gtemaedleafe: yes, which might still not use all of the SDK caps16:34
edleafes/app/program ?16:34
edleafes/app/tool ?16:34
mordredwell - mostly that it's a $something that people use to build their actual thing16:34
mrhillsmanwould 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:34
edleafemrhillsman: that sounds about right16:35
mordredso it's sdk -> $something (terraform,ansible) -> end-user-app16:35
mordredmrhillsman: ++16:35
edleafethe one thing is that an SDK can also be opinionated16:35
mrhillsmani know it is a small thing but i think it can help set scope for now16:35
mrhillsmanok thx16:35
mordrededleafe: I don't know of any sdk's that fit that description :)16:35
edleafeIOW, 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 later16:36
mordredit might choose to not expose the concept of microversions to the end user at all16:36
edleafemordred: 'zactly16:36
edleafeIOW, it's not 1:1 to the HTTP API16:36
mordredbut - regardless of how it does it - it's still a wrapper around the HTTP API16:36
mordredso I think mrhillsman's sentence is still good16:36
mordredgophercloud has to do some transforms because of the nature of go16:37
mordredit's inevitable anywhere16:37
mordredalthough some of us are more aggressive than others16:38
edleafemordred: 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
mrhillsmani'll take the action of patch for navigator page16:39
elmikoi don't think we need to add "opinionated" in the description though, i like the way mrhillsman put it16:40
edleafeelmiko: sure. I just brought it up because that was an issue when I wrote pyrax.16:41
mordredyeah - in the future I could see making some distinctions between more direct api wrappers and api abstractions - that might be useful to end users16:41
elmikoedleafe: ack16:41
elmikoedleafe: were you asked to make it unopinionated or something?16:42
edleafeDevelopers in $LANGUAGE don't care about the API; they care about getting things done in $LANGUAGE16:42
mordredin 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 layer16:42
mordrededleafe: yup16:42
elmikothat totally makes sense to me edleafe16:42
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Rework orchestration to add update preview
mordredif they cared about the REST API itself, they'd use a direct rest client16:43
mordred(which, it turns out, is totally ok!)16:43
elmikoi just feel like /all/ SDKs are opinionated, which is why i'm kinda curious about edleafe's statement about pyrax =)16:43
mrhillsmanso another housekeeping thing, not sure how much time we have left, the SDKs themselves16:43
elmikomordred: 100% agree16:43
elmikomrhillsman: we hold office hours till the top of the hour16:44
mrhillsmani think having more than one per language in terms of officially vs community supported statement earlier16:44
mrhillsmanas a user is painful16:44
gtemasounds reasonable to me16:44
mrhillsmanin the initial post an sdk for each language was listed16:45
mrhillsmanno one pushed back on that list16:45
mrhillsmanany concern around having one per language16:45
edleafeelmiko: 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
mrhillsmanthere is like 3 for java16:46
mrhillsmanif openstack4j declined in what it supports would libcloud become an officially supported because it did not16:46
elmikoedleafe: makes good sense to me16:46
mrhillsmanjust something to think about16:47
elmikomrhillsman: 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" XD16:47
gtemaone might want to use libcloud, which means 2 python16:47
mrhillsmansorry, i meant jclouds16:47
mrhillsmanjava v java16:48
edleafegtema: you bring up another point. There are OpenStack-specific SDKs in python, and then cross-cloud SDKs like libcloud16:48
edleafeObviously the cross-cloud won't do everything that an OpenStack-specific SDK would16:49
edleafeSome people don't care about those things - they just want to spin up a VM, or store a blob16:49
edleafeHaving these validation tests would show what each SDK could do16:50
mordredyeah. if you're writing a multi-cloud thing, libcloud might make your life much easier16:50
mordredif 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 time16:51
mordredsame thing with jclouds vs openstack4j16:51
elmikowhat is this "more time" thing you speak of, it is an alien concept to me XD16:52
mordredit 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 layer16:52
mordredelmiko: ikr?16:52
mordredbecausr the cloud specific libraries can do a better job of taking advantage of features of the cloud to provide features of the app16:53
mordredthe multi-cloud-libraries seemed to be much more popular several years ago - but that's a totally unsupported by science16:53
mrhillsmanhave we identified any next steps?16:54
mrhillsmani know i have the project nav update16:54
mrhillsmanno meeting next thursday?16:55
mrhillsmanor office hours rather16:55
edleafeNot for the next 2 weeks for me16:55
edleafeNext one for me is Jan 10th16:55
elmikoedleafe: ++16:56
mrhillsmangtema i will follow your lead, next thursday is probably ok for me but not the 3rd16:56
mrhillsmantoo close to the 1st :)16:56
gtemamrhillsman: I would also like to skip next week, since I am moving to another house16:57
mrhillsmansorry flip that16:57
mrhillsmanok great16:58
mrhillsmanso just wait until the 10th gtema?16:58
gtemayupp, that would be better16:58
mrhillsmanor sig leads?16:58
mrhillsmanthx for the time it was great; ttyl16:59
*** e0ne_ has quit IRC16:59
edleafeThanks for coming!16:59
elmikomrhillsman: glad to help =)16:59
mrhillsmanreally appreciate it16:59
elmikoand in the new year we should add gtema to the official roster of the sig16:59
elmikolater edleafe mordred gtema mrhillsman , have a nice holiday and new year =)17:01
mrhillsmansame to you!17:02
edleafeAs 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
gtemathanks elmiko, you too17:02
gtemaedleafe, bye17:02
*** gtema has quit IRC17:10
*** jpich has quit IRC17:15
*** cdent has quit IRC17:20
*** gouthamr has quit IRC17:31
*** dmellado has quit IRC17:31
*** jpena is now known as jpena|off17:44
*** ttsiouts has quit IRC17:50
*** ttsiouts has joined #openstack-sdks17:51
*** ttsiouts has quit IRC17:55
*** dasp has quit IRC18:26
*** dasp has joined #openstack-sdks18:31
*** gouthamr_ has joined #openstack-sdks18:37
openstackgerritMerged openstack/python-openstackclient master: Add osc repo to the base job definition
*** dmellado has joined #openstack-sdks18:40
*** e0ne has joined #openstack-sdks18:49
*** e0ne_ has joined #openstack-sdks19:25
*** e0ne has quit IRC19:25
openstackgerritAndreas Jaeger proposed openstack/cliff master: Use template for lower-constraints
*** bobh has joined #openstack-sdks19:58
fricklermordred: 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.
openstackgerritAndreas Jaeger proposed openstack/keystoneauth master: Use template for lower-constraints
mordredfrickler: oh - you're probably right about that20:09
openstackgerritAndreas Jaeger proposed openstack/osc-lib master: Use template for lower-constraints
openstackgerritAndreas Jaeger proposed openstack/os-client-config master: Use template for lower-constraints
*** gouthamr_ is now known as gouthamr20:13
*** bobh has quit IRC21:09
*** e0ne_ has quit IRC21:21
*** bobh has joined #openstack-sdks21:47
*** bobh has quit IRC21:52
*** slaweq has quit IRC22:28
*** bobh has joined #openstack-sdks22:33
*** bobh has quit IRC22:34
*** bobh_ has joined #openstack-sdks22:35
*** bobh_ has quit IRC22:39
*** slaweq has joined #openstack-sdks22:44
*** slaweq has quit IRC22:49
openstackgerritMerged openstack/cliff master: Use template for lower-constraints
openstackgerritMerged openstack/osc-lib master: Use template for lower-constraints

Generated by 2.15.3 by Marius Gedminas - find it at!