| *** slaweq has quit IRC | 00:02 | |
| *** bobh has joined #openstack-sdks | 00:15 | |
| *** bobh has quit IRC | 00:20 | |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Start using direct REST in normalize tests https://review.openstack.org/626379 | 00:33 |
|---|---|---|
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115 | 00:33 |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server https://review.openstack.org/626380 | 00:33 |
| *** tosky has quit IRC | 00:43 | |
| *** bobh has joined #openstack-sdks | 00:53 | |
| *** mriedem has quit IRC | 01:18 | |
| *** bobh has quit IRC | 01:25 | |
| *** bobh has joined #openstack-sdks | 01:26 | |
| openstackgerrit | Merged openstack/openstacksdk master: Properly munch for resource sub-dicts https://review.openstack.org/625923 | 01:27 |
| *** bobh has quit IRC | 01:40 | |
| *** markvoelker has quit IRC | 01:50 | |
| *** bobh has joined #openstack-sdks | 01:54 | |
| openstackgerrit | jacky06 proposed openstack/os-api-ref master: Remove support for py34 https://review.openstack.org/626300 | 02:07 |
| *** bobh has quit IRC | 04:06 | |
| openstackgerrit | Dou Rui Yuan proposed openstack/python-openstackclient master: Remove testr.conf as it's been replaced by stestr https://review.openstack.org/626492 | 06:10 |
| *** mgagne has quit IRC | 06:33 | |
| *** mgagne has joined #openstack-sdks | 06:40 | |
| *** annp has joined #openstack-sdks | 06:48 | |
| *** cdent has joined #openstack-sdks | 07:42 | |
| *** gkadam has joined #openstack-sdks | 07:49 | |
| *** slaweq has joined #openstack-sdks | 07:52 | |
| *** gtema has joined #openstack-sdks | 08:07 | |
| *** gtema has quit IRC | 08:20 | |
| *** tosky has joined #openstack-sdks | 08:24 | |
| *** jpena|off is now known as jpena | 08:31 | |
| *** jpich has joined #openstack-sdks | 08:54 | |
| *** markvoelker has joined #openstack-sdks | 08:56 | |
| *** jpich has quit IRC | 09:04 | |
| *** jpich has joined #openstack-sdks | 09:05 | |
| *** jpich has quit IRC | 09:21 | |
| *** jpich has joined #openstack-sdks | 09:23 | |
| *** ttsiouts has joined #openstack-sdks | 09:26 | |
| *** e0ne has joined #openstack-sdks | 09:53 | |
| *** e0ne has quit IRC | 10:29 | |
| *** e0ne has joined #openstack-sdks | 10:30 | |
| *** ttsiouts has quit IRC | 11:10 | |
| *** ttsiouts has joined #openstack-sdks | 11:11 | |
| *** ttsiouts has quit IRC | 11:15 | |
| frickler | shade-ansible job looks broken for a couple of days, did anyone look into that yet? http://zuul.openstack.org/builds?job_name=shade-ansible-functional-devstack | 11:22 |
| frickler | mordred: I rebased https://review.openstack.org/526115 for you, seems that that would still be relevant to have as test coverage | 11:30 |
| *** dave-mccowan has quit IRC | 11:42 | |
| *** dave-mccowan has joined #openstack-sdks | 11:43 | |
| *** cdent_ has joined #openstack-sdks | 11:44 | |
| *** cdent has quit IRC | 11:46 | |
| *** cdent_ is now known as cdent | 11:46 | |
| *** ttsiouts has joined #openstack-sdks | 11:52 | |
| *** jpena is now known as jpena|lunch | 11:59 | |
| frickler | mordred: 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. https://review.openstack.org/#/c/570680/1/tox.ini,unified | 12:53 |
| openstackgerrit | Jens Harbott (frickler) proposed openstack-infra/shade master: Fix ansible stable pin in tox test https://review.openstack.org/626568 | 12:55 |
| frickler | mordred: Shrews: ^^ that should fix the test failures | 12:56 |
| *** markvoelker has quit IRC | 13:12 | |
| openstackgerrit | Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore output 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860 | 13:16 |
| *** jpena|lunch is now known as jpena | 13:16 | |
| *** e0ne has quit IRC | 13:19 | |
| mordred | frickler: awesome! thanks | 13:22 |
| *** gkadam has quit IRC | 13:25 | |
| *** e0ne has joined #openstack-sdks | 13:33 | |
| *** mriedem has joined #openstack-sdks | 13:38 | |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115 | 13:46 |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Compute location properly in server https://review.openstack.org/626380 | 13:46 |
| *** e0ne has quit IRC | 14:11 | |
| *** e0ne_ has joined #openstack-sdks | 14:11 | |
| *** ttsiouts has quit IRC | 14:33 | |
| *** ttsiouts has joined #openstack-sdks | 14:34 | |
| *** ttsiouts has quit IRC | 14:38 | |
| *** ttsiouts has joined #openstack-sdks | 14:43 | |
| openstackgerrit | Jens Harbott (frickler) proposed openstack/python-openstackclient master: Add osc repo to the base job definition https://review.openstack.org/626590 | 14:51 |
| frickler | mordred: ^ seems this is needed for the devstack change | 14:51 |
| *** gtema has joined #openstack-sdks | 14:54 | |
| mordred | frickler: +A - I think that's a clear enough change | 14:56 |
| openstackgerrit | Merged openstack/openstacksdk master: Start using direct REST in normalize tests https://review.openstack.org/626379 | 15:00 |
| *** mriedem is now known as mriedem_afk | 15:11 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations https://review.openstack.org/621153 | 15:18 |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Add possibility to override base_path for resource operations https://review.openstack.org/621153 | 15:21 |
| openstackgerrit | Merged openstack-infra/shade master: Fix ansible stable pin in tox test https://review.openstack.org/626568 | 15:45 |
| Shrews | mordred: remind me why our ansible tox test is pinned? | 15:48 |
| Shrews | oh, that's shade | 15:50 |
| mordred | Shrews: yeah- and it was to test master of shade against stable of ansible | 15:54 |
| edleafe | he last API-SIG Office Hour of 2018 has begun | 16:00 |
| edleafe | *The last | 16:00 |
| elmiko | hello/ | 16:01 |
| edleafe | hola | 16:01 |
| elmiko | did you see the email that Artem sent to the list? | 16:02 |
| elmiko | i think he may join us today, not sure though | 16:02 |
| gtema | Hi, I am here | 16:02 |
| elmiko | hey! | 16:02 |
| elmiko | welcome =) | 16:02 |
| gtema | thanks | 16:02 |
| elmiko | so, as i mentioned in the email thread, we don't have a standing "meeting" anymore just these office hours | 16:02 |
| edleafe | Hi gtema | 16:02 |
| gtema | edleafe: hi | 16:03 |
| 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 |
| gtema | elmiko: it's not a problem | 16:03 |
| mrhillsman | o/ | 16:03 |
| gtema | from what I see dtantsur is also part of API-SIG and an SDK core | 16:03 |
| elmiko | yes | 16:04 |
| edleafe | yes, he is | 16:04 |
| elmiko | hey mrhillsman | 16:04 |
| 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:04 |
| gtema | sure, no problem | 16:05 |
| gtema | until the Jan there would not be any real work anymore ;-) | 16:05 |
| edleafe | gtema: what general time zone are you in? | 16:06 |
| 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 |
| gtema | Germany (GMT+1/2) | 16:06 |
| edleafe | ok, so closer to dtantsur's schedule | 16:06 |
| gtema | yupp | 16:06 |
| elmiko | gtema: yeah, no real work until after holidays. i was hoping we could do a meet and greet today =) | 16:06 |
| gtema | sure | 16:06 |
| elmiko | great, i look forward to the new year and hopefully getting some sdk activity in the sig | 16:07 |
| mrhillsman | i am utc-6 until march 10, 2019 then i'll be utc-5 | 16:07 |
| elmiko | ack | 16:08 |
| 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:08 |
| gtema | I don't. But I agree there should be some plan on what to do | 16:09 |
| gtema | what we want to achieve is clear, but what would be the steps is not | 16:10 |
| elmiko | ++ | 16:10 |
| 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 |
| mrhillsman | yes exactly | 16:10 |
| edleafe | Is the general idea to come up with a validation suite of tests to run against the various SDKs? | 16:10 |
| mrhillsman | https://ethercalc.org/q4nklltf21nz | 16:11 |
| gtema | I understand it as yes, but also to laying out results of validations to public. Isn't it mrhillsman? | 16:11 |
| mrhillsman | that is the current items working with gophercloud we were able to come up with | 16:12 |
| mrhillsman | the key being the outcome/scenarios in the first column | 16:12 |
| elmiko | looks like a decent starting point | 16:12 |
| mrhillsman | someone getting that to https://www.openstack.org/software/project-navigator/sdks | 16:13 |
| 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:13 |
| mrhillsman | chris hoge tossed out the idea of a state machine - i am not sure what that is | 16:14 |
| mrhillsman | but my understanding is | 16:14 |
| openstackgerrit | Merged openstack/openstacksdk master: Drop self.conn from base.TestCase https://review.openstack.org/625115 | 16:15 |
| 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 |
| elmiko | that sounds reasonable, i imagine some sort of zuul scenario for testing all the different permutations | 16:16 |
| mrhillsman | i think because every SDK is different, it would be quite difficult to have something run for all languages | 16:17 |
| 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:17 |
| 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 |
| elmiko | right | 16:18 |
| edleafe | mrhillsman: there would also have to be many intermediate checks, not just end state | 16:18 |
| mrhillsman | i think there could be parameters around the end state | 16:18 |
| 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 |
| 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:19 |
| mrhillsman | += | 16:20 |
| mrhillsman | ++ | 16:20 |
| gtema | ++ | 16:20 |
| mrhillsman | i think one additional consideration is how to incentivize these existing SDKs | 16:21 |
| mrhillsman | is being listed on the project navigator enough? | 16:21 |
| edleafe | Maybe offer candy? :) | 16:22 |
| elmiko | depends how motivated the teams are ;) | 16:22 |
| mrhillsman | or being labeled officially-supported vs community-maintained | 16:22 |
| mrhillsman | i.e. https://kubernetes.io/docs/reference/using-api/client-libraries/ | 16:22 |
| 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 |
| 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:22 |
| mrhillsman | i do have one question - how do we define an SDK - is that a thing we should pin down? | 16:24 |
| 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 |
| elmiko | edleafe: ++ | 16:24 |
| mrhillsman | ++ | 16:24 |
| gtema | definitely | 16:25 |
| 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:26 |
| 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:27 |
| mrhillsman | i agree with that definition; asked because some folks as i have been working on this consider terraform an SDK | 16:28 |
| gtema | ?? - SDK is a binding for a programming language, not to the specific tool | 16:28 |
| elmiko | gtema: ++ | 16:29 |
| elmiko | that's how i interpret it also | 16:29 |
| 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 |
| edleafe | yeah, terraform sounds more like Heat | 16:30 |
| elmiko | that said, are the terraform folks looking to have their stuff in this test infra? | 16:30 |
| mrhillsman | as a user i would like to know a popular tool like terraform works with openstack | 16:30 |
| mrhillsman | or rather what does/does not work | 16:31 |
| mrhillsman | as an example | 16:31 |
| elmiko | that's fair | 16:31 |
| gtema | mrhillsman: I know, my users have same desire. But those are tools using an SDK | 16:31 |
| mrhillsman | i think however this is phase one | 16:31 |
| mrhillsman | and should be language bindings | 16:31 |
| mrhillsman | not something like terraform | 16:31 |
| gtema | so here we can have 2 tables: SDKs and tools (like Ansible/Terraform) | 16:31 |
| elmiko | mrhillsman: ++ | 16:31 |
| edleafe | mrhillsman: that's certainly valuable info for a potential terraform user, but it really isn't an SDK | 16:31 |
| mrhillsman | ^ | 16:32 |
| edleafe | gtema: yeah, good point - it's a tool, not an SDK | 16:32 |
| mrhillsman | totally agree | 16:32 |
| *** mriedem_afk is now known as mriedem | 16:32 | |
| mordred | ++ | 16:32 |
| mordred | same thing with openstacksdk and ansible-openstack-modules | 16:32 |
| mrhillsman | just want to be sure so when i get questions i can communicate properly | 16:33 |
| mordred | one depends on the other - but the ansible users don't really care about the sdk as much as the modules | 16:33 |
| 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 |
| mrhillsman | i am willing to bet you all will get similar question(s) | 16:33 |
| elmiko | mrhillsman: i think the position of starting small with the actual sdks is a good position | 16:33 |
| mordred | ++ | 16:33 |
| edleafe | So terraform is an app that is built using the Gopherclooud SDK | 16:33 |
| 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 |
| mordred | but for now I think that's a fine sentence | 16:34 |
| gtema | edleafe: yes, which might still not use all of the SDK caps | 16:34 |
| edleafe | s/app/program ? | 16:34 |
| edleafe | s/app/tool ? | 16:34 |
| mordred | well - mostly that it's a $something that people use to build their actual thing | 16:34 |
| 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:34 |
| edleafe | mrhillsman: that sounds about right | 16:35 |
| elmiko | ++ | 16:35 |
| gtema | ++ | 16:35 |
| mordred | so it's sdk -> $something (terraform,ansible) -> end-user-app | 16:35 |
| mordred | mrhillsman: ++ | 16:35 |
| edleafe | the one thing is that an SDK can also be opinionated | 16:35 |
| mrhillsman | i know it is a small thing but i think it can help set scope for now | 16:35 |
| mrhillsman | ok thx | 16:35 |
| mordred | edleafe: I don't know of any sdk's that fit that description :) | 16:35 |
| 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 |
| mordred | it might choose to not expose the concept of microversions to the end user at all | 16:36 |
| edleafe | mordred: 'zactly | 16:36 |
| edleafe | IOW, it's not 1:1 to the HTTP API | 16:36 |
| mordred | but - regardless of how it does it - it's still a wrapper around the HTTP API | 16:36 |
| mrhillsman | ^ | 16:36 |
| mordred | so I think mrhillsman's sentence is still good | 16:36 |
| mordred | gophercloud has to do some transforms because of the nature of go | 16:37 |
| mordred | it's inevitable anywhere | 16:37 |
| mordred | although some of us are more aggressive than others | 16:38 |
| mrhillsman | hehe | 16:39 |
| 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 |
| mrhillsman | i'll take the action of patch for navigator page | 16:39 |
| elmiko | i don't think we need to add "opinionated" in the description though, i like the way mrhillsman put it | 16:40 |
| mrhillsman | ++ | 16:40 |
| edleafe | elmiko: sure. I just brought it up because that was an issue when I wrote pyrax. | 16:41 |
| 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 |
| elmiko | edleafe: ack | 16:41 |
| elmiko | edleafe: were you asked to make it unopinionated or something? | 16:42 |
| edleafe | Developers in $LANGUAGE don't care about the API; they care about getting things done in $LANGUAGE | 16:42 |
| 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 |
| mordred | edleafe: yup | 16:42 |
| elmiko | that totally makes sense to me edleafe | 16:42 |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Rework orchestration to add update preview https://review.openstack.org/621154 | 16:42 |
| mordred | if they cared about the REST API itself, they'd use a direct rest client | 16:43 |
| elmiko | right | 16:43 |
| mordred | (which, it turns out, is totally ok!) | 16:43 |
| elmiko | i just feel like /all/ SDKs are opinionated, which is why i'm kinda curious about edleafe's statement about pyrax =) | 16:43 |
| mrhillsman | so another housekeeping thing, not sure how much time we have left, the SDKs themselves | 16:43 |
| elmiko | mordred: 100% agree | 16:43 |
| elmiko | mrhillsman: we hold office hours till the top of the hour | 16:44 |
| mrhillsman | i think having more than one per language in terms of officially vs community supported statement earlier | 16:44 |
| mrhillsman | as a user is painful | 16:44 |
| gtema | sounds reasonable to me | 16:44 |
| mrhillsman | in the initial post an sdk for each language was listed | 16:45 |
| mrhillsman | no one pushed back on that list | 16:45 |
| mrhillsman | any concern around having one per language | 16:45 |
| 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 |
| mrhillsman | there is like 3 for java | 16:46 |
| mrhillsman | if openstack4j declined in what it supports would libcloud become an officially supported because it did not | 16:46 |
| elmiko | edleafe: makes good sense to me | 16:46 |
| mrhillsman | just something to think about | 16:47 |
| 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 |
| gtema | one might want to use libcloud, which means 2 python | 16:47 |
| mrhillsman | sorry, i meant jclouds | 16:47 |
| mrhillsman | java v java | 16:48 |
| edleafe | gtema: you bring up another point. There are OpenStack-specific SDKs in python, and then cross-cloud SDKs like libcloud | 16:48 |
| edleafe | Obviously the cross-cloud won't do everything that an OpenStack-specific SDK would | 16:49 |
| edleafe | Some people don't care about those things - they just want to spin up a VM, or store a blob | 16:49 |
| edleafe | Having these validation tests would show what each SDK could do | 16:50 |
| mordred | yeah. if you're writing a multi-cloud thing, libcloud might make your life much easier | 16:50 |
| 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 |
| gtema | :D | 16:51 |
| mordred | same thing with jclouds vs openstack4j | 16:51 |
| elmiko | what is this "more time" thing you speak of, it is an alien concept to me XD | 16:52 |
| 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 |
| mordred | elmiko: ikr? | 16:52 |
| 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 |
| mordred | the multi-cloud-libraries seemed to be much more popular several years ago - but that's a totally unsupported by science | 16:53 |
| mrhillsman | hehe | 16:54 |
| elmiko | lol | 16:54 |
| mrhillsman | have we identified any next steps? | 16:54 |
| mrhillsman | i know i have the project nav update | 16:54 |
| mrhillsman | no meeting next thursday? | 16:55 |
| mrhillsman | or office hours rather | 16:55 |
| edleafe | Not for the next 2 weeks for me | 16:55 |
| edleafe | Next one for me is Jan 10th | 16:55 |
| elmiko | edleafe: ++ | 16:56 |
| mrhillsman | gtema i will follow your lead, next thursday is probably ok for me but not the 3rd | 16:56 |
| mrhillsman | too close to the 1st :) | 16:56 |
| gtema | mrhillsman: I would also like to skip next week, since I am moving to another house | 16:57 |
| mrhillsman | sorry flip that | 16:57 |
| mrhillsman | ok great | 16:58 |
| mrhillsman | so just wait until the 10th gtema? | 16:58 |
| gtema | yupp, that would be better | 16:58 |
| mrhillsman | or sig leads? | 16:58 |
| mrhillsman | ++ | 16:59 |
| mrhillsman | thx for the time it was great; ttyl | 16:59 |
| *** e0ne_ has quit IRC | 16:59 | |
| edleafe | Thanks for coming! | 16:59 |
| elmiko | mrhillsman: glad to help =) | 16:59 |
| mrhillsman | really appreciate it | 16:59 |
| elmiko | and in the new year we should add gtema to the official roster of the sig | 16:59 |
| elmiko | later edleafe mordred gtema mrhillsman , have a nice holiday and new year =) | 17:01 |
| mrhillsman | same to you! | 17:02 |
| 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 |
| gtema | thanks elmiko, you too | 17:02 |
| gtema | edleafe, bye | 17:02 |
| *** gtema has quit IRC | 17:10 | |
| *** jpich has quit IRC | 17:15 | |
| *** cdent has quit IRC | 17:20 | |
| *** gouthamr has quit IRC | 17:31 | |
| *** dmellado has quit IRC | 17:31 | |
| *** jpena is now known as jpena|off | 17:44 | |
| *** ttsiouts has quit IRC | 17:50 | |
| *** ttsiouts has joined #openstack-sdks | 17:51 | |
| *** ttsiouts has quit IRC | 17:55 | |
| *** dasp has quit IRC | 18:26 | |
| *** dasp has joined #openstack-sdks | 18:31 | |
| *** gouthamr_ has joined #openstack-sdks | 18:37 | |
| openstackgerrit | Merged openstack/python-openstackclient master: Add osc repo to the base job definition https://review.openstack.org/626590 | 18:39 |
| *** dmellado has joined #openstack-sdks | 18:40 | |
| *** e0ne has joined #openstack-sdks | 18:49 | |
| *** e0ne_ has joined #openstack-sdks | 19:25 | |
| *** e0ne has quit IRC | 19:25 | |
| openstackgerrit | Andreas Jaeger proposed openstack/cliff master: Use template for lower-constraints https://review.openstack.org/626673 | 19:51 |
| *** bobh has joined #openstack-sdks | 19:58 | |
| 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 |
| openstackgerrit | Andreas Jaeger proposed openstack/keystoneauth master: Use template for lower-constraints https://review.openstack.org/626691 | 20:03 |
| mordred | frickler: oh - you're probably right about that | 20:09 |
| openstackgerrit | Andreas Jaeger proposed openstack/osc-lib master: Use template for lower-constraints https://review.openstack.org/626702 | 20:12 |
| openstackgerrit | Andreas Jaeger proposed openstack/os-client-config master: Use template for lower-constraints https://review.openstack.org/626703 | 20:13 |
| *** gouthamr_ is now known as gouthamr | 20:13 | |
| *** bobh has quit IRC | 21:09 | |
| *** e0ne_ has quit IRC | 21:21 | |
| *** bobh has joined #openstack-sdks | 21:47 | |
| *** bobh has quit IRC | 21:52 | |
| *** slaweq has quit IRC | 22:28 | |
| *** bobh has joined #openstack-sdks | 22:33 | |
| *** bobh has quit IRC | 22:34 | |
| *** bobh_ has joined #openstack-sdks | 22:35 | |
| *** bobh_ has quit IRC | 22:39 | |
| *** slaweq has joined #openstack-sdks | 22:44 | |
| *** slaweq has quit IRC | 22:49 | |
| openstackgerrit | Merged openstack/cliff master: Use template for lower-constraints https://review.openstack.org/626673 | 22:52 |
| openstackgerrit | Merged openstack/osc-lib master: Use template for lower-constraints https://review.openstack.org/626702 | 23:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!