| *** kragniz has quit IRC | 00:02 | |
| notmyname | jeblair: doesn't look like it got re-enqueued to the gate queue | 00:02 |
|---|---|---|
| notmyname | jeblair: https://review.openstack.org/#/c/69187/ | 00:02 |
| notmyname | jeblair: a re-approval should kick it in now, right? | 00:03 |
| *** kragniz has joined #openstack-swift | 00:03 | |
| jeblair | notmyname: yep, that's the bug. another approval should get it. | 00:03 |
| notmyname | jeblair: thanks. got it | 00:04 |
| openstackgerrit | Samuel Merritt proposed a change to openstack/swift: Fix GETs of SLOs and DLOs with If-Modified-Since https://review.openstack.org/73448 | 00:05 |
| *** mkollaro has joined #openstack-swift | 00:14 | |
| *** booi has joined #openstack-swift | 00:21 | |
| *** mdonohoe has joined #openstack-swift | 00:35 | |
| *** markd has quit IRC | 00:38 | |
| openstackgerrit | A change was merged to openstack/swift: Don't create bin/* files magically https://review.openstack.org/73037 | 00:41 |
| openstackgerrit | A change was merged to openstack/python-swiftclient: Port to python-requests https://review.openstack.org/69187 | 00:41 |
| torgomatic | notmyname: looks like it's time to tag swiftclient? | 00:42 |
| notmyname | tag time | 00:42 |
| notmyname | yup doing it now. and I'll send an email either tonight or tomorrow | 00:42 |
| torgomatic | cool | 00:42 |
| notmyname | 0c7264c21d06d37de5db0beee677c4e026dc8f45 is 1.9 | 00:43 |
| notmyname | 19d7e1812a99d73785146667ae2f3a7156f06898 is 2.0 | 00:43 |
| notmyname | torgomatic: can you confirm that those commit SHAs look right? | 00:46 |
| notmyname | as the tag locations | 00:46 |
| notmyname | jeblair: still around? | 00:49 |
| torgomatic | notmyname: yeah, those look right | 00:50 |
| notmyname | torgomatic: thanks | 00:50 |
| notmyname | jeblair: clarkb: FYI I'll be pushing tags for python-swiftclient momentarily for versions 1.9 and 2.0. We do not anticipate than any other project depending on python-swiftclient will be affected (ie I don't think they are relying on any feature that changed), but I will check in the morning to see if anything got flagged | 00:51 |
| notmyname | tags pushed. waiting for zuul to pick it up and do the pypi push | 00:53 |
| notmyname | mordred: FYI too ^^ | 00:53 |
| notmyname | there it is https://pypi.python.org/pypi/python-swiftclient/1.9.0 and https://pypi.python.org/pypi/python-swiftclient/2.0 | 00:54 |
| torgomatic | just in time for web 3.1 | 00:55 |
| *** mkollaro has quit IRC | 01:00 | |
| *** shri has quit IRC | 01:12 | |
| openstackgerrit | Samuel Merritt proposed a change to openstack/swift: Merge remote-tracking branch 'upstream/master' into feature/ec https://review.openstack.org/73471 | 01:39 |
| torgomatic | merge ahoy! | 01:39 |
| *** nosnos has joined #openstack-swift | 01:39 | |
| torgomatic | This one was actually quite easy, which was nice. Still a few conflicts, but they were all pretty simple to resolve. | 01:40 |
| *** jergerber has quit IRC | 01:42 | |
| *** csd has quit IRC | 02:06 | |
| *** zul has quit IRC | 02:12 | |
| *** rongze has joined #openstack-swift | 02:28 | |
| luisbg | torgomatic, hi. why do you have to ask Jenkins if the commit was approved? | 02:35 |
| torgomatic | luisbg: that commit *should* have gone in the gate queue on its own, but it didn't, so I hit +1 Approved on it in hopes of moving it along | 02:35 |
| torgomatic | the text was just to let folks know that I was poking at Jenkins | 02:36 |
| luisbg | torgomatic, ahhh, it's going to miss the tag time by very little :P | 02:36 |
| torgomatic | luisbg: well, that was a python-swiftclient tag anyway, not swift, so it doesn't matter for this | 02:36 |
| luisbg | torgomatic, oh, got it | 02:36 |
| luisbg | torgomatic, thanks for the +1 approve to push it again | 02:37 |
| torgomatic | no problem | 02:37 |
| *** rongze has quit IRC | 02:52 | |
| *** hurrican_ has joined #openstack-swift | 02:57 | |
| *** hurricanerix has quit IRC | 03:00 | |
| *** hurrican_ has quit IRC | 03:01 | |
| *** csd has joined #openstack-swift | 03:06 | |
| luisbg | torgomatic, now the jenkins build failed? weird | 03:09 |
| *** vkdrao has joined #openstack-swift | 03:17 | |
| *** csd has quit IRC | 03:17 | |
| *** gyee has quit IRC | 03:26 | |
| *** csd has joined #openstack-swift | 03:42 | |
| *** CrackerJackMack has quit IRC | 03:49 | |
| *** CrackerJackMack has joined #openstack-swift | 03:50 | |
| *** vkdrao has quit IRC | 03:51 | |
| *** chandan_kumar has joined #openstack-swift | 04:11 | |
| *** lpabon has quit IRC | 04:31 | |
| *** saju_m has joined #openstack-swift | 04:39 | |
| *** dmorita has joined #openstack-swift | 04:41 | |
| *** chandan_kumar has quit IRC | 04:52 | |
| *** chandan_kumar has joined #openstack-swift | 05:14 | |
| *** basha has joined #openstack-swift | 05:14 | |
| basha | zaitcev: there? | 05:15 |
| zaitcev | basha: somewhat | 05:15 |
| *** yuan has joined #openstack-swift | 05:16 | |
| *** csd has quit IRC | 05:23 | |
| *** csd has joined #openstack-swift | 05:24 | |
| *** csd_ has joined #openstack-swift | 05:25 | |
| *** nshaikh has joined #openstack-swift | 05:28 | |
| *** csd_ has quit IRC | 05:29 | |
| *** csd has quit IRC | 05:29 | |
| *** csd_ has joined #openstack-swift | 05:29 | |
| *** csd_ has quit IRC | 05:36 | |
| *** zackf has quit IRC | 05:39 | |
| notmyname | hmm..how do you feel about a python-swiftclient 2.0.1 | 05:49 |
| *** chandankumar_ has joined #openstack-swift | 05:54 | |
| *** saju_m has quit IRC | 05:58 | |
| *** chandankumar_ has quit IRC | 06:00 | |
| torgomatic | notmyname: what broke? | 06:01 |
| notmyname | torgomatic: glad you're up. looks like the cert validation for v1 auth doesn't plumb through the insecure parameter. my mistake for not catching that earlier | 06:01 |
| notmyname | https://gist.github.com/notmyname/b249a2a4dd9dd39b68f2 <-- current WIP patch. working on the test case now (that's not passing) | 06:02 |
| torgomatic | well, that should be a straightforward fix at leeast | 06:02 |
| notmyname | torgomatic: ya, but it seems we don't have a "fake v1.0 endpoint" for testing at all | 06:07 |
| *** basha has quit IRC | 06:09 | |
| *** basha has joined #openstack-swift | 06:10 | |
| notmyname | ...progress...maybe... | 06:14 |
| *** chandan_kumar has quit IRC | 06:15 | |
| torgomatic | notmyname: you might consider something like this https://gist.github.com/smerritt/8996613 | 06:25 |
| torgomatic | same code you have, but a test that seems to pass/fail depending on if the code is there or not | 06:25 |
| notmyname | ya, but it just tests that "insecure" was passed, right? it doesn't test if that actually works. see the v2 tests | 06:26 |
| notmyname | https://gist.github.com/notmyname/e6b422b230072091ef06 <<-- almost there, I think. but this also adds some better faking of a v1 endpoint | 06:27 |
| notmyname | the only thing I'm missing right now is when to raise the client exception. the v2 stub does that based on auth_url.endswith | 06:28 |
| torgomatic | eh, those just look at kwargs['insecure'] and the path component of the auth URL | 06:28 |
| torgomatic | six of one, half dozen of the other IMO | 06:28 |
| torgomatic | but then, I haven't been in the client code much at all lately | 06:28 |
| notmyname | swifterdarrell: FYI current options for tests ^^ | 06:30 |
| *** chandan_kumar has joined #openstack-swift | 06:32 | |
| openstackgerrit | Samuel Merritt proposed a change to openstack/python-swiftclient: Only run flake8 on swiftclient code https://review.openstack.org/73507 | 06:36 |
| notmyname | torgomatic: I'm currently looking for the place to put in auth_url path detection in the v1 auth connection | 06:36 |
| swifterdarrell | notmyname: the question is how to get those ClientExceptions in the right places? | 06:36 |
| notmyname | ya, exactly | 06:37 |
| notmyname | we have a fake conneciton object. and get_auth_v1 calls .request() on it. but I don't see where that goes yet | 06:37 |
| notmyname | ah, i think I know where it goes | 06:39 |
| swifterdarrell | notmyname: maybe stub out get_auth_1_0 a la the way get_keystoneclient_2_0 is stubbed out for testing? | 06:43 |
| swifterdarrell | notmyname: that'll get you plumbing coverage, at least, but not the bits inside get_auth_1_0 i guess | 06:44 |
| swifterdarrell | notmyname: but even there, you just need plumbing to prove the insecure flag is passed into http_connection | 06:45 |
| swifterdarrell | notmyname: while you're in there, can you update Connection.__init__'s docstring for "insecure"? | 06:47 |
| swifterdarrell | notmyname: it only mentions Keystone, which is no longer fully accurate | 06:47 |
| notmyname | k | 06:47 |
| notmyname | current rev https://gist.github.com/notmyname/fa0822ef9558f1124462 | 06:47 |
| zaitcev | I missed that part about v1 either, but honestly I was somewhat demoralized and note reviewing anything properly for days | 06:48 |
| zaitcev | s/ note / not / | 06:48 |
| notmyname | swifterdarrell: done | 06:49 |
| zaitcev | that gist looks reasonable at first look | 06:49 |
| notmyname | https://gist.github.com/notmyname/d3f07ab9f39c30421f15 | 06:49 |
| zaitcev | I'm going to go cry myself to sleep now | 06:49 |
| notmyname | zaitcev: tests don't pass yet :-) | 06:49 |
| swifterdarrell | notmyname: thx | 06:50 |
| notmyname | swifterdarrell: good catch | 06:50 |
| swifterdarrell | zaitcev: lol | 06:50 |
| notmyname | last test still fails. not raising the exception | 06:51 |
| swifterdarrell | notmyname: isn't the logic backward on line 117? | 06:53 |
| swifterdarrell | if insecure_ok, why raise exception? | 06:53 |
| notmyname | what fine? | 06:53 |
| notmyname | thanks | 06:54 |
| swifterdarrell | notmyname: OTOH, wouldn't it be "self.insecure_ok = insecure" in the __init__? | 06:55 |
| notmyname | I think I see where my problem is | 06:56 |
| notmyname | https://gist.github.com/notmyname/a849babc2fe8a1dd1acb but self.insecure_ok is always None | 07:02 |
| notmyname | chmouel: I see you doing LP stuff (emails gave you away). are you here? | 07:04 |
| chmouel | notmyname: hey there | 07:04 |
| notmyname | chmouel: read traceback please | 07:04 |
| notmyname | *playback | 07:04 |
| chmouel | authurl detection? | 07:05 |
| notmyname | chmouel: insecure isn't honored for v1 auth | 07:05 |
| chmouel | let me test | 07:07 |
| *** chandan_kumar has quit IRC | 07:18 | |
| chmouel | ok i can reproduce and i think the fix should be easy | 07:18 |
| openstackgerrit | Chmouel Boudjnah proposed a change to openstack/python-swiftclient: Fix insecure https://review.openstack.org/73512 | 07:19 |
| chmouel | notmyname: any chance to test if that works for you ^ | 07:20 |
| *** chandan_kumar has joined #openstack-swift | 07:21 | |
| openstackgerrit | Yuan Zhou proposed a change to openstack/python-swiftclient: Fixes segmented uploading to non-default storage policy container https://review.openstack.org/73513 | 07:21 |
| notmyname | chmouel: I think that's different from what I saw. I wasn't messing with cacert bundles at all | 07:25 |
| notmyname | but no tests ;-) | 07:25 |
| *** saju_m has joined #openstack-swift | 07:25 | |
| chmouel | yeah was just up for testing :) | 07:26 |
| chmouel | notmyname: works for me with my patch and your patch | 07:30 |
| notmyname | I think I got it | 07:32 |
| notmyname | took too long because it's too late ;-) | 07:32 |
| chmouel | heh and me it's too early ;-) | 07:32 |
| openstackgerrit | John Dickinson proposed a change to openstack/python-swiftclient: Fix --insecure option on auth v1 https://review.openstack.org/73517 | 07:33 |
| notmyname | swifterdarrell: torgomatic: chmouel: can you take a look? | 07:33 |
| notmyname | chmouel: I didn't add your cacert one | 07:33 |
| chmouel | notmyname: the cacert fix with 2.0 8-) | 07:34 |
| notmyname | chmouel: ah, is there something broken there too? | 07:34 |
| notmyname | ?!?! | 07:34 |
| chmouel | notmyname: with the CLI yeah | 07:34 |
| notmyname | ugh | 07:34 |
| chmouel | that slipped in during the review iterations :( | 07:35 |
| chmouel | we need some functional tests for https i think | 07:35 |
| chmouel | wonder if we can use portante self serving test for that | 07:36 |
| notmyname | swifterdarrell: torgomatic: chmouel: I'll add in the cacert to my patch too | 07:36 |
| chmouel | cool tks will abandon the other one | 07:36 |
| torgomatic | notmyname: seems to work as expected for v1 | 07:36 |
| openstackgerrit | John Dickinson proposed a change to openstack/python-swiftclient: Fix --insecure option on auth https://review.openstack.org/73517 | 07:37 |
| chmouel | notmyname: is that needed https://review.openstack.org/#/c/73517/1/tests/utils.py ? | 07:39 |
| notmyname | chmouel: a drive-by to check more than "auth didn't blow up" | 07:40 |
| notmyname | chmouel: but no, not technically needed for this patch. I didn't like the assertEquals(url, None) lines though | 07:40 |
| notmyname | especially when v2 is actually testing a dummy return (as is right, IMO) | 07:41 |
| chmouel | cool make sense | 07:41 |
| torgomatic | alright, sleep time | 07:41 |
| notmyname | torgomatic: thanks :-) | 07:42 |
| notmyname | swifterdarrell: thanks | 07:42 |
| notmyname | chmouel: thanks :-) | 07:42 |
| notmyname | chmouel: go ahead and merge | 07:43 |
| notmyname | then I'll tag | 07:43 |
| notmyname | 2.0.1 | 07:43 |
| chmouel | notmyname: thanks to you sorry that slipped in will see how we can do functional tests for SSL | 07:43 |
| chmouel | notmyname: done | 07:43 |
| notmyname | thanks | 07:44 |
| notmyname | ya. we've got to not let this happen | 07:44 |
| notmyname | I'll fully accept responsibility for the rush tonight on it, since I'm the one who merged the requests port this afternoon | 07:44 |
| chmouel | i am the one who was pressing you :) | 07:45 |
| chmouel | presurring | 07:45 |
| chmouel | anyway coffee now :) | 07:45 |
| openstackgerrit | A change was merged to openstack/python-swiftclient: Fix --insecure option on auth https://review.openstack.org/73517 | 07:57 |
| *** mkollaro has joined #openstack-swift | 08:04 | |
| *** bvandenh has joined #openstack-swift | 08:22 | |
| *** xga has joined #openstack-swift | 08:23 | |
| *** mmcardle has joined #openstack-swift | 08:53 | |
| *** basha_ has joined #openstack-swift | 08:53 | |
| *** basha has quit IRC | 08:56 | |
| *** basha_ is now known as basha | 08:56 | |
| *** nacim has joined #openstack-swift | 08:57 | |
| *** xga_ has joined #openstack-swift | 09:07 | |
| *** xga has quit IRC | 09:07 | |
| tristanC | sorry guys about that swift authentication that wasn't covered. Many thanks for the fix! | 09:08 |
| *** joeljwri1 has joined #openstack-swift | 09:26 | |
| *** joeljwri1 has quit IRC | 09:29 | |
| *** joeljwright has joined #openstack-swift | 09:29 | |
| *** ppai has joined #openstack-swift | 09:31 | |
| tristanC | About SSL functional tests, do you know where does belong ? I'm not sure how to reconfigure proxy-server with different certs and run tests against it... | 09:33 |
| *** nshaikh has quit IRC | 09:38 | |
| *** fbo_away is now known as fbo | 09:38 | |
| *** foexle has joined #openstack-swift | 09:38 | |
| *** kris_ha has joined #openstack-swift | 09:43 | |
| *** xga_ has quit IRC | 09:44 | |
| *** xga has joined #openstack-swift | 09:44 | |
| *** dmorita has quit IRC | 09:46 | |
| *** saju_m has quit IRC | 09:51 | |
| *** kris_ha is now known as kris_h | 09:52 | |
| saurabh_ | I have a question---> how does swift monitor it's services? | 09:52 |
| *** nshaikh has joined #openstack-swift | 10:04 | |
| *** Midnightmyth has joined #openstack-swift | 10:06 | |
| *** nacim has quit IRC | 10:07 | |
| *** mmcardle has quit IRC | 10:14 | |
| *** mmcardle has joined #openstack-swift | 10:16 | |
| *** nosnos has quit IRC | 10:21 | |
| *** nacim has joined #openstack-swift | 10:22 | |
| *** ccorrigan has joined #openstack-swift | 10:26 | |
| *** kragniz has quit IRC | 10:33 | |
| *** basha has quit IRC | 10:35 | |
| *** kragniz has joined #openstack-swift | 10:40 | |
| *** joeljwright has quit IRC | 10:41 | |
| *** joeljwright has joined #openstack-swift | 10:41 | |
| *** joeljwright has joined #openstack-swift | 10:41 | |
| *** joeljwright has quit IRC | 10:42 | |
| *** joeljwright has joined #openstack-swift | 10:42 | |
| *** joeljwright has quit IRC | 10:42 | |
| *** joeljwright has joined #openstack-swift | 10:43 | |
| *** joeljwright has quit IRC | 10:43 | |
| *** joeljwright has joined #openstack-swift | 10:43 | |
| *** joshwambua has joined #openstack-swift | 10:44 | |
| *** joeljwright has quit IRC | 10:45 | |
| *** joeljwright has joined #openstack-swift | 10:45 | |
| *** joeljwri1 has joined #openstack-swift | 10:51 | |
| *** joeljwri1 has quit IRC | 10:51 | |
| *** joeljwri1 has joined #openstack-swift | 10:51 | |
| *** joeljwright has quit IRC | 10:54 | |
| *** joeljwri1 has quit IRC | 10:56 | |
| *** joeljwright has joined #openstack-swift | 10:56 | |
| *** joeljwright has quit IRC | 10:59 | |
| *** joshwambua has quit IRC | 11:09 | |
| *** joeljwright has joined #openstack-swift | 11:11 | |
| *** xga has quit IRC | 11:13 | |
| *** joeljwright has left #openstack-swift | 11:16 | |
| *** joeljwright has joined #openstack-swift | 11:16 | |
| tristanC | houston, we got a problem... swiftclient download is not right, it add data around the object | 11:21 |
| *** xga has joined #openstack-swift | 11:22 | |
| *** nacim has quit IRC | 11:24 | |
| tristanC | the port to requests added --[hash] Content-Disposition: form-data; name="file"; filename="file" | 11:25 |
| tristanC | around the actual data :( | 11:25 |
| *** mkollaro has quit IRC | 11:31 | |
| *** nshaikh has quit IRC | 11:43 | |
| *** chandan_kumar has quit IRC | 11:58 | |
| *** dmsimard has joined #openstack-swift | 12:01 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Remove multipart/form-data file upload https://review.openstack.org/73585 | 12:02 |
| *** a1|away is now known as JelleB | 12:02 | |
| tristanC | the bug is referenced there: https://bugs.launchpad.net/openstack-ci/+bug/1280072 | 12:20 |
| *** nacim has joined #openstack-swift | 12:39 | |
| *** derekh has joined #openstack-swift | 12:40 | |
| derekh | hi, looks like python-swiftclinet is using up a lot more memory then it used to https://bugs.launchpad.net/tripleo/+bug/1280275 | 12:41 |
| derekh | anybody else seeing this? | 12:42 |
| *** ppai has quit IRC | 12:43 | |
| tristanC | derekh: there is also a corruption bug for swift upload | 12:44 |
| derekh | tristanC: thanks, I see there is a patch up for it, I'll try it out | 12:49 |
| derekh | tristanC: didn't seem to work for me, added comment to the review, I applied the patch on top of the swiftclient glance is using | 13:03 |
| derekh | tristanC: gotta pop out for an hour but if you want me to try anything when I come back let me know | 13:04 |
| tristanC | derekh: Thanks you very much | 13:04 |
| tristanC | I'm still looking for a workaround... | 13:06 |
| *** mkollaro has joined #openstack-swift | 13:08 | |
| *** tdasilva has left #openstack-swift | 13:11 | |
| *** mmcardle has quit IRC | 13:20 | |
| *** Midnightmyth has quit IRC | 13:25 | |
| *** joeljwright has quit IRC | 13:30 | |
| *** annegentle has quit IRC | 13:32 | |
| *** joeljwright has joined #openstack-swift | 13:34 | |
| *** hurricanerix has joined #openstack-swift | 13:34 | |
| *** mmcardle has joined #openstack-swift | 13:54 | |
| *** bvandenh has quit IRC | 14:00 | |
| *** xga has quit IRC | 14:05 | |
| *** Midnightmyth has joined #openstack-swift | 14:09 | |
| *** annegentle has joined #openstack-swift | 14:14 | |
| *** xga has joined #openstack-swift | 14:28 | |
| *** xga has quit IRC | 14:36 | |
| notmyname | I'm awake. what' going on? | 14:36 |
| tristanC | hello | 14:37 |
| tristanC | notmyname: the port to requests that have been merge add extra data to content, which appear as a corruption | 14:38 |
| notmyname | what extra data? | 14:38 |
| tristanC | Content-Disposition: form-data; name="file"; filename="test" | 14:38 |
| tristanC | wrapped around "--hash" | 14:38 |
| tristanC | this I have fixed in https://review.openstack.org/73585 | 14:39 |
| tristanC | but now, there is another trouble, somewhere along the glance code path, "Transfer-Encoding: chunked" is being added to bulk upload | 14:39 |
| tristanC | so swift server try to decode the chunk length but there is only data there | 14:39 |
| tristanC | and now, we just found the root cause. https://github.com/kennethreitz/requests/blob/master/requests/models.py#L430 there you can see requests add the chunked encoding | 14:41 |
| tristanC | the super_len method used is not able to find the length of a glance.common.utils.CooperativeReader | 14:42 |
| notmyname | is glance using chunked transfer encoding? | 14:43 |
| tristanC | no, it set content_length to put_object, so it assume swift will do a raw encoding | 14:43 |
| *** xga has joined #openstack-swift | 14:45 | |
| *** byeager has joined #openstack-swift | 14:49 | |
| *** Trixboxer has joined #openstack-swift | 14:50 | |
| notmyname | tristanC: ok https://review.openstack.org/73585 works, in that I can run the CLI and see the change. but what about any tests? | 14:57 |
| notmyname | at this point I'm wondering about any sort of "undo", but I don't know if that's possible now | 14:57 |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Remove multipart/form-data file upload https://review.openstack.org/73585 | 14:58 |
| tristanC | notmyname: what do you mean ? | 15:02 |
| *** xga has quit IRC | 15:02 | |
| notmyname | hold that. I'm looking at the chunked thing now | 15:04 |
| *** tdasilva has joined #openstack-swift | 15:05 | |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Remove multipart/form-data file upload https://review.openstack.org/73585 | 15:05 |
| tristanC | for what it worth, that last patch fixes the gate. | 15:12 |
| tristanC | I guess it is now time for either revert the port or push this fix | 15:13 |
| notmyname | ya, that's what I meant earlier | 15:14 |
| *** tdasilva has quit IRC | 15:15 | |
| notmyname | also it seems that we have no (effective) tests for swiftclient right now. eg without your patch all tests pass. additionally, your patch doesn't add any tests to ensure that it doesn't get broken again | 15:16 |
| notmyname | eg that's what I had to do on on the auth thing last night | 15:16 |
| *** krtaylor has quit IRC | 15:16 | |
| tristanC | notmyname: I understand, it have been a rough day for me seing the gate all broken and I worked hard to find a solution. | 15:17 |
| *** krtaylor has joined #openstack-swift | 15:17 | |
| *** mtreinish has joined #openstack-swift | 15:19 | |
| notmyname | I'm not trying to blame anyone (other than myself). just stating the state of things | 15:19 |
| tristanC | I now understand there wasn't any functional test on swiftclient and sadly there was an un-expected interaction with out glance used it | 15:19 |
| notmyname | ya, and that lack of symmetric tests. which mtreinish has proposed | 15:19 |
| notmyname | so that issue is resolved | 15:19 |
| notmyname | *being resolved | 15:20 |
| *** therve has joined #openstack-swift | 15:20 | |
| notmyname | I'm not sure how realistic reverting the requests port is. or rather, we've already got the 2.X series public, so it's kinda hard to erase that from the internet | 15:21 |
| tristanC | it's a tough called, either we revert the port to requests, makes it more tested and merged with the symmetric tests, but then loosing certificate verification | 15:21 |
| *** nshaikh has joined #openstack-swift | 15:21 | |
| notmyname | the symmetric tests are orthogonal | 15:22 |
| tristanC | oh yes, and that 2.x release | 15:22 |
| notmyname | (I thought fungi was coming in here--been waiting for him to be here to say stuff) | 15:22 |
| * mordred is already here | 15:22 | |
| *** apevec has joined #openstack-swift | 15:22 | |
| notmyname | k | 15:22 |
| *** fungi has joined #openstack-swift | 15:23 | |
| mordred | and there's fungi | 15:23 |
| fungi | sorry, just catching up... so the current thinking is that 69187 is causing file corruption for glance's swift backing store in tempest tests (at least), and 73585 is the current proposed solution? | 15:23 |
| notmyname | fungi: mordred: one option is to freeze the openstack swiftclient version at 1.9 now | 15:23 |
| notmyname | while we get stuff sorted for 2.x | 15:24 |
| mordred | that does not seem unreasonable to me | 15:24 |
| notmyname | I'm not sure how realistic "undoing" the 2.x release is | 15:24 |
| notmyname | ie removing the tag and pulling off of pypi | 15:25 |
| therve | notmyname, The gate seems to be using master in some places at least | 15:25 |
| fungi | i believe we integration test with the master branches of all the official clients to (normally) prevent them from being able to release breaking changes (which 70378 would hopefully have ensured) | 15:25 |
| notmyname | because anyone who already got it won't be able to upgrate | 15:25 |
| luisbg | any core reviewers have one minute for a gerrit/jenkins question? | 15:25 |
| notmyname | luisbg: not now. in the middle of other stuff | 15:25 |
| notmyname | luisbg: try -dev or -101 for the time being | 15:26 |
| luisbg | notmyname, no worries :) asking here to see if any other has time | 15:26 |
| mordred | hrm. well, (thinking out loud here) | 15:26 |
| notmyname | therve: should be what the requirements file is, right? | 15:26 |
| mordred | we could push a 2.1 tag that's effectively the same as 1.9 | 15:26 |
| mordred | notmyname: no - devstack uses master | 15:26 |
| notmyname | mordred: but that fully burns the entire 2.x series | 15:26 |
| mordred | notmyname: you could still work on master and release a 2.2 | 15:27 |
| fungi | do we think it was the 2.0 release which broke it, or the merging of 69187 to master? | 15:27 |
| notmyname | well except that the change from 2.1 (non-requests) to 2.2 (requests redux) would have breaking CLI changes again, needing to bump the rev number | 15:28 |
| mordred | notmyname: also, re therve, the devstack gate uses master | 15:28 |
| mordred | notmyname: nod | 15:28 |
| therve | fungi, "It depends"? I think the merge broke devstack, but the release broke the gate | 15:29 |
| notmyname | fungi: if devstack is just using master, then it was that patch and not the 2.x release | 15:29 |
| therve | Or something like that | 15:29 |
| zaitcev | yeah, don't oscillate, please. So it's a zero-day bug in a x.0 release, big deal. You know how it was a rule in some shops never use Red Hat Linux x.0 anything, always wait for x.2. :-) | 15:29 |
| mordred | zaitcev: :) | 15:29 |
| notmyname | zaitcev: no. I don't want to do that | 15:29 |
| notmyname | mordred: fungi: so no way to use the "lastest stable" ie what's in requirements? | 15:30 |
| mordred | not without patching devstack | 15:31 |
| *** vkmc has joined #openstack-swift | 15:31 | |
| fungi | notmyname: we avoid that intentionally, so that clients don't release broken versions. the problem here, depending on how you look at it, is either that tempest was using swiftclient or that we weren't gating swiftclient changes on tempest | 15:31 |
| *** vkmc has left #openstack-swift | 15:31 | |
| notmyname | fungi: mordred: also, mtreinish's patch to make gates symmetrical, if that looks good, should probably go ahead and land. but only if we'll then be able to jump to the head of the queue for tristanC's patch | 15:31 |
| fungi | i would also be okay entertaining a revert of the changes to tempest which started using swiftclient | 15:31 |
| mordred | does tristanC's patch fix the bug? | 15:32 |
| notmyname | fungi: that seems...significant | 15:32 |
| notmyname | mordred: I'm told so. but it has zero tests | 15:32 |
| fungi | notmyname: it does, but no more significant than you reverting your release train | 15:32 |
| tristanC | mordred: it have been coocked in a hurry, it does fixes the upload corruption and glance failure, but it is dirty and have no tests | 15:32 |
| mordred | nod | 15:32 |
| notmyname | "lgtm" but I'm also the one who merged the requests port to start with :-/ | 15:33 |
| fungi | so, we could land the change to symmetricify the gating, and then recheck 73585 | 15:33 |
| mtreinish | fungi: that tempest revert wouldn't be so simple because of glance. | 15:33 |
| notmyname | fungi: ya, that's what I'm thinking too | 15:33 |
| mordred | as much as I don't normally think that solving a missing-tests related issue with another patch with no tests ... in this case it doesn't seem likely to make things worse | 15:33 |
| fungi | mtreinish: oh, i didn't say i thought it would be trivial | 15:33 |
| mtreinish | fungi: it be more to change devstack to switch the glance backend | 15:34 |
| notmyname | mordred: just tests missing in a different place | 15:34 |
| notmyname | ;-) | 15:34 |
| fungi | mtreinish: got it | 15:34 |
| mordred | and just pushing forward with that seems like less outbound pain than the various revert strategies | 15:34 |
| mtreinish | there is only one scenario test that uses swiftclient | 15:34 |
| mtreinish | I don't think its anywhere else in tempest | 15:34 |
| * fungi approves 70378 since we can always rip it back out if it leaves us with no good path forward | 15:35 | |
| cschwede | I'm wondering why this wasn't catched in "check-swift-dsvm-functional" - looks like glance didn't use the patch during tests? | 15:35 |
| notmyname | fungi: when that lands, can you recheck https://review.openstack.org/#/c/73585/ with it? | 15:35 |
| fungi | yep. i'm hovering on it now | 15:36 |
| notmyname | cschwede: because swift doesn't use swiftclient any more. and the functests don't use glance AFAIK | 15:36 |
| fungi | cschwede: right, the place we would catch this is in the jobs being added by 70378 | 15:36 |
| cschwede | fungi: ah, ok, now i understand. thanks | 15:37 |
| notmyname | fungi: and then when/if that passes, we can land tristanC's patch to get the rest of the projects going again | 15:37 |
| notmyname | then it's "just" our problem again for the tests | 15:37 |
| notmyname | ie the tests of swiftclient | 15:37 |
| cschwede | notmyname: well swiftclient is used in the tests: http://logs.openstack.org/85/73585/3/check/check-swift-dsvm-functional/3f5cbfe/logs/pip-freeze.txt.gz thats why i was wondering | 15:38 |
| fungi | cschwede: it's installed, but may not actually be invoked for anything | 15:38 |
| notmyname | cschwede: probably just was in the requirements file somewhere? just not excercised? | 15:38 |
| notmyname | ok, I see that it landed | 15:39 |
| fungi | yep, rechecking | 15:39 |
| fungi | once i confirm zuul got the reload | 15:39 |
| notmyname | so 45 minutes? ;-) | 15:40 |
| notmyname | to do the recheck | 15:40 |
| fungi | well, we should see pretty quickly whether it's helping... i think the jobs were failing way more quickly than that | 15:40 |
| fungi | i'm going to speed up zuul getting that updated layout.yaml | 15:40 |
| notmyname | ok | 15:40 |
| fungi | Last reconfigured: Fri Feb 14 2014 15:42:18 GMT+0000 (UTC) | 15:42 |
| fungi | rechecking now | 15:42 |
| notmyname | ok, I see it going (and some queued jobs) | 15:43 |
| fungi | yeah, waiting for it to get devstack nodes assigned for the tempest jobs | 15:43 |
| notmyname | so that leaves 2 issues, in my mind: | 15:44 |
| notmyname | 1) mordred: fungi: why can we only test master in the clients? | 15:44 |
| fungi | notmyname: we need to test both master and most recent release | 15:44 |
| notmyname | 2) tristanC: can you prioritize working on tests for swiftclient? | 15:44 |
| fungi | notmyname: but we started out making sure we at least caught breaking changes before they got released this way | 15:45 |
| tristanC | notmyname: absolutely yes | 15:45 |
| mordred | notmyname: the gate is designed to test master of the projects against master of the other projects | 15:45 |
| notmyname | tristanC: thanks. | 15:45 |
| fungi | notmyname: we want to add most recent release version to a set of tests as well so we confirm that we don't release software which depends on other unreleased software, but that was a lower-priotity problem to solve | 15:45 |
| notmyname | fungi: ah, k | 15:45 |
| mordred | yah, what fungi said | 15:46 |
| notmyname | in a clear and eloquent manner :-) | 15:46 |
| mordred | he's better with the wordface | 15:46 |
| fungi | also, if/when we get to the point of being able to gerrit review tags themselves, we can potentially run tests before allowing a tag to merge and trigger release machinery | 15:46 |
| notmyname | ah, yes | 15:47 |
| fungi | but that depends on some additional gerriting we lack (probably more features we'd need to upstream) | 15:47 |
| derekh | while ye are deciding what todo is the extra memory usage I've seen related/important https://bugs.launchpad.net/tripleo/+bug/1280275 | 15:47 |
| cschwede | derekh: it's fixed with that patch also (at least in my tests) | 15:48 |
| notmyname | cschwede: do you have details? why is it fixed? | 15:48 |
| derekh | cschwede: ok, cool, thanks just wanted to double check | 15:49 |
| tristanC | notmyname: the 'files' requests parameter was a bad move as it causes the file to be read in memory before being sent | 15:50 |
| cschwede | notmyname: because if you use 'files={"file": contents}' as arg for requests it iterates over all files, building the data in memory | 15:50 |
| notmyname | oh, that's bad | 15:50 |
| notmyname | fungi: if tristanC updates the commit message to include a reference to the memory bug, then what happens to gate jobs? | 15:51 |
| fungi | notmyname: tristanC: they'll get restarted | 15:51 |
| fungi | notmyname: tristanC: but we can update the commit message prior to approving | 15:51 |
| notmyname | ok. don't do that. we can add the reference manually in LP | 15:51 |
| fungi | for those following along, https://jenkins02.openstack.org/job/check-tempest-dsvm-full/9145/console | 15:56 |
| notmyname | ok, while those check jobs are running, I'm going upstairs to get a cup of coffee | 15:56 |
| * tristanC crosses fingers | 15:58 | |
| notmyname | back | 15:59 |
| notmyname | at least I have good coffee. so I've got that going for me | 16:01 |
| tristanC | notmyname: so, to be clear on swiftclient tests, should I mimic what is done on the swift server (ie: python-swiftclient/tests/functionnal) ? | 16:04 |
| notmyname | tristanC: the existing unit tests seem to simply see that something was returned. not that the right thing was returned. we'll need functional tests too, but I'd like to see accurate unit tests first | 16:04 |
| tristanC | notmyname: alright! | 16:06 |
| *** ChanServ changes topic to "Current Swift Release: 1.12.0 | Priority Reviews: https://wiki.openstack.org/wiki/Swift/PriorityReviews | Channel Logs: http://eavesdrop.openstack.org/irclogs/%23openstack-swift/" | 16:07 | |
| notmyname | fungi: networking issue on the check gate? https://jenkins02.openstack.org/job/gate-python-swiftclient-python26/326/console | 16:09 |
| *** dhellmann has joined #openstack-swift | 16:09 | |
| *** Diddi has joined #openstack-swift | 16:10 | |
| fungi | yarg | 16:11 |
| fungi | we've been seeing dns resolution problems in rackspace of late. i think we want to install a caching resolver on our servers and prime it at the start of tests with a bunch of openstack.org subdomain records | 16:11 |
| notmyname | well, that's not a confounding issue (yet). the py26 checks weren't in the question | 16:11 |
| notmyname | ok | 16:12 |
| notmyname | fungi: it seems that one of the jobs I see failing is the -cells one. but that's not added to the swiftclient gate | 16:13 |
| notmyname | is that functionality covered in the others (from the swiftclient perspective)? | 16:13 |
| fungi | notmyname: i think they're failing in the same way though. mtreinish should we gate swiftclient on cells jobs too? i think we set those voting after your initial change was proposed | 16:13 |
| notmyname | I'm not a fan of testing twice when it's just the same test (ie no new info), so if it's not needed that's fine | 16:14 |
| mtreinish | fungi: I'm not sure it adds anything here, it's nonvoting still I think | 16:15 |
| fungi | mtreinish: no, it's voting on other projects now, but i think that happened just in the past week or so | 16:15 |
| *** xga has joined #openstack-swift | 16:16 | |
| mtreinish | oh if it's voting I guess we should add it then | 16:16 |
| *** russellb is now known as rustlebee | 16:16 | |
| fungi | but anyway, it's tangential to the current situation | 16:16 |
| fungi | so in positive news, the -full run is at this point well past where we were seeing errors on the failing runs, i believe | 16:20 |
| notmyname | ya, and -neutron and -grenade seem to be nearly done too | 16:20 |
| notmyname | about 10 minutes left on the run (that timer is great) | 16:21 |
| *** tdasilva has joined #openstack-swift | 16:23 | |
| fungi | if only it could be more accurate, but clouds vary too much for any real precision timing | 16:23 |
| *** xga_ has joined #openstack-swift | 16:25 | |
| *** xga has quit IRC | 16:25 | |
| fungi | all tempest/grenade runs successful except the two which are still going | 16:26 |
| notmyname | yay | 16:29 |
| *** xga_ has quit IRC | 16:30 | |
| notmyname | fungi: ugh. I just realized because of the py26 dns issue these are going to all have to run again before it gets to the gate. right? | 16:30 |
| *** xga has joined #openstack-swift | 16:31 | |
| tristanC | notmyname: that would be the good time to update the commit message too | 16:31 |
| fungi | notmyname: we reverted the change yesterday to require successful check jobs because we still seem to have either a logic error in the config or a bug we need to fix in it | 16:31 |
| notmyname | fungi: ok. so approving the patch won't require the check jobs to be rerun? | 16:31 |
| fungi | notmyname: nope. it should be safe to approve when you're comfortable | 16:32 |
| notmyname | ok | 16:32 |
| notmyname | tristanC: ok, so don't update the commit message. I'll comment on the other bug manually | 16:32 |
| notmyname | tristanC: oh, wait. scratch that | 16:32 |
| fungi | and if/when you approve it, i'll go ahead and promote it to the front of the gate pipeline so we don't have to let the other changes already in there suffer the same bug | 16:32 |
| notmyname | tristanC: yes, when the check jobs finish (successfully), add another reference to https://bugs.launchpad.net/tripleo/+bug/1280275 in the commit message | 16:33 |
| notmyname | tristanC: then I'll approve it | 16:33 |
| tristanC | should be good in a couple of minute | 16:33 |
| *** mrsnivvel has quit IRC | 16:34 | |
| *** zackf has joined #openstack-swift | 16:35 | |
| *** nshaikh has quit IRC | 16:35 | |
| *** csd has joined #openstack-swift | 16:36 | |
| notmyname | fungi: this is like waiting for the windows progress bar... ;-) | 16:37 |
| *** kris_h has quit IRC | 16:37 | |
| fungi | notmyname: i vaguely remember what that was like... so very, very long ago now | 16:37 |
| notmyname | likewise | 16:37 |
| openstackgerrit | Tristan Cacqueray proposed a change to openstack/python-swiftclient: Remove multipart/form-data file upload https://review.openstack.org/73585 | 16:38 |
| fungi | check-tempest-dsvm-postgres-full succeeded and was uploading when it got aborted. check-tempest-dsvm-full was on its way to succeeding as well--since the jobs had been failing on the same bug i think it's safe to say it would have passed | 16:39 |
| notmyname | aborted because of tristanC new patch set? | 16:40 |
| fungi | yep | 16:40 |
| tristanC | arf, no! | 16:40 |
| fungi | anyway, i'm all set to bump it to the front once it's approved, but it looks like it will probably have the gate to itself anyway | 16:41 |
| notmyname | fungi: done | 16:42 |
| notmyname | https://review.openstack.org/#/c/73585/ | 16:42 |
| notmyname | fungi: once that lands, will there be a way to recheck all the stuff that's failed since last night? | 16:43 |
| fungi | i've pushed it in front of the failing nova change, so at least it's granted a stay | 16:43 |
| notmyname | thanks | 16:43 |
| fungi | notmyname: working with qa to get a signature for the failure into elastic-recheck would allow it to comment on the failures with the bug number i think? or that might only be of it had been classified before they failed. at any rate, probably just a message to the -dev ml would suffice | 16:44 |
| notmyname | ya, I'll send out a post-mortem when this lands | 16:44 |
| fungi | though jog0 or sdague or mtreinish might be able to cook up a logstash query to get a list of changes which failed on it | 16:45 |
| apevec | tristanC, btw, I tried to assign 1280072 to you but LP says No items matched "tristan-cacqueray". ? | 16:45 |
| apevec | tristanC, can you just grab it? | 16:45 |
| notmyname | ok, while the gate is running, I'm going to take a shower | 16:46 |
| notmyname | when it lands I'll tag a 2.0.2 release for swiftclient (and send announce emails) and also write up and send out the post mortem of this issue | 16:46 |
| notmyname | fungi: ^ | 16:46 |
| notmyname | mordred: ^ | 16:47 |
| mordred | notmyname: awesome | 16:47 |
| tristanC | notmyname: Great! thanks!! | 16:47 |
| tristanC | apevec: ok, I did it | 16:47 |
| fungi | notmyname: tristanC: thanks! | 16:47 |
| apevec | tristanC, notmyname - thanks guys! | 16:48 |
| fungi | i need to step out and take my gf to lunch in celebration of st. hallmark's day. can't really ditch her this time, i don't think | 16:48 |
| fungi | but things seem on track at this point | 16:49 |
| mtreinish | fungi: if you add a query after all the fails it won't mark them, but it's used for the recheck page. You can push it as resolved query | 16:53 |
| *** otherjon_ has joined #openstack-swift | 16:53 | |
| *** saju_m has joined #openstack-swift | 16:54 | |
| *** jog0 has joined #openstack-swift | 17:06 | |
| jog0 | whats the ETA until the gate bug is fixed? | 17:21 |
| notmyname | jog0: zuul says "0 minutes" | 17:21 |
| notmyname | jog0: it's the top of the gate queue now | 17:22 |
| jog0 | notmyname: thanks so the follow up question: how did this get past the gate? | 17:22 |
| notmyname | jog0: post mortem coming later | 17:22 |
| jog0 | notmyname: when things are working can you send a email out to the ML | 17:22 |
| jog0 | notmyname: excellent thanks! | 17:22 |
| notmyname | mordred: should I be worried that the last 2 jobs haven't finished yet? | 17:27 |
| notmyname | mordred: https://jenkins06.openstack.org/job/gate-tempest-dsvm-full/885/console and https://jenkins05.openstack.org/job/gate-tempest-dsvm-postgres-full/770/console | 17:27 |
| notmyname | ah. maybe not. looks like just a slow test | 17:28 |
| * mordred blames postgres | 17:29 | |
| notmyname | well the good news is all the stuff in the queue after it seems to be working | 17:31 |
| *** byeager has quit IRC | 17:31 | |
| notmyname | mordred: looks like errors just got reported | 17:32 |
| tristanC | notmyname: hopefully false alarm... | 17:33 |
| notmyname | or not? /me doesn't know | 17:33 |
| mtreinish | notmyname: that's just the log messages | 17:33 |
| notmyname | hmm -full reported success | 17:34 |
| mtreinish | all the tests pass | 17:34 |
| openstackgerrit | A change was merged to openstack/python-swiftclient: Remove multipart/form-data file upload https://review.openstack.org/73585 | 17:34 |
| notmyname | so the log error thing isn't a thing yet? | 17:34 |
| mtreinish | there is a script that runs after tempest that looks for errors/tracebacks in the logs | 17:34 |
| notmyname | yay, landed | 17:34 |
| mtreinish | notmyname: we used to gate on the log messages but some bugs slipped through and it got too flaky | 17:34 |
| mtreinish | the fail message is because we've never changed the script to not print it | 17:35 |
| notmyname | ok, got to take care of a couple of normal morning things now that disaster seems averted. I'll write up my post-mortem later todoay | 17:35 |
| jog0 | notmyname: can you respond to the ML thread saying gate is working | 17:35 |
| notmyname | jog0: what thread? I didn't see anything about that this morning | 17:36 |
| jog0 | [openstack-dev] [Nova][Gate] qemu: linux kernel too old to load a ram disk | 17:36 |
| jog0 | someone marked it as nova which was downright wrong | 17:36 |
| jog0 | but yeah | 17:36 |
| jog0 | or maybe just a new thread or something | 17:36 |
| notmyname | no, I'll start a new thread | 17:37 |
| notmyname | afk for a bit | 17:37 |
| jog0 | thanks | 17:37 |
| tristanC | notmyname: thank you for following this, I leave now for today and the rest of the week end | 17:38 |
| tristanC | have a good day folks! | 17:38 |
| *** xga_ has joined #openstack-swift | 17:39 | |
| *** xga has quit IRC | 17:39 | |
| *** fbo is now known as fbo_away | 17:48 | |
| *** xga_ has quit IRC | 17:52 | |
| *** byeager has joined #openstack-swift | 18:02 | |
| *** derekh has quit IRC | 18:04 | |
| *** apevec has left #openstack-swift | 18:05 | |
| *** shri has joined #openstack-swift | 18:05 | |
| *** nacim has quit IRC | 18:06 | |
| *** mkollaro has quit IRC | 18:10 | |
| *** markd has joined #openstack-swift | 18:10 | |
| *** byeager has quit IRC | 18:10 | |
| *** basha has joined #openstack-swift | 18:15 | |
| *** tongli has joined #openstack-swift | 18:16 | |
| *** mmcardle has quit IRC | 18:31 | |
| *** basha has quit IRC | 18:36 | |
| *** basha has joined #openstack-swift | 18:36 | |
| *** basha has quit IRC | 18:41 | |
| *** gyee has joined #openstack-swift | 18:48 | |
| anticw_ | zaitcev: got your email | 18:51 |
| anticw_ | zaitcev: i will check it out, the thing is once i uninstalled wads of cruft the issue went away ... so i have to get in the hosed state again to check your fix(es) | 18:52 |
| zaitcev | anticw_: As you can see, we're still ironing issues with the "new-new" swiftclient, so I thought I'd just make you an interim version that addresses your immediate concerns. I need to know how it performs, in particular if any tracebacks with EBADF occur. | 18:52 |
| zaitcev | anticw_: oh, okay. | 18:53 |
| zaitcev | anticw_: But your symptom description was a good match for the known issues: #1 wildcard matching, #2 EBADF | 18:54 |
| *** kris_h has joined #openstack-swift | 19:01 | |
| *** Kim-Chi-San has joined #openstack-swift | 19:05 | |
| *** Kim-Chi-San is now known as tburnes | 19:05 | |
| *** byeager has joined #openstack-swift | 19:07 | |
| *** byeager has quit IRC | 19:11 | |
| *** saju_m has quit IRC | 19:11 | |
| *** byeager has joined #openstack-swift | 19:20 | |
| *** zul has joined #openstack-swift | 19:20 | |
| *** marcusvrn has quit IRC | 19:21 | |
| *** zul has quit IRC | 19:22 | |
| *** marcusvrn has joined #openstack-swift | 19:23 | |
| notmyname | well...that was fun(*) | 19:26 |
| notmyname | *"fun" void where prohibited | 19:26 |
| torgomatic | void* where C | 19:26 |
| notmyname | chmouel: FYI, I do not want to see any py3 changes merged into swiftclient until we get the testing sorted out | 19:35 |
| markd | hey there swift folks, I have a question: if the swift write has been changed to 1 copy, and there is only one storage node/swift server and the disk goes bad. Do I lose my data? | 19:38 |
| notmyname | markd: yes, probably | 19:38 |
| markd | OK, so my next question then: if there is only one node like above and a second disk is added to the swift store. Does swift automatically try to balance the image store across the two disks? | 19:39 |
| notmyname | markd: yes | 19:41 |
| markd | great, thanks for the quck replies. | 19:41 |
| *** xga has joined #openstack-swift | 19:49 | |
| *** joeljwright has quit IRC | 19:52 | |
| *** gvernik has joined #openstack-swift | 19:53 | |
| *** xga has quit IRC | 19:54 | |
| cschwede | notmyname: do you know if anyone else is working on swiftclient tests? maybe we should put a note somewhere who is working on it (to avoid duplicate work) | 19:55 |
| *** mjseger has joined #openstack-swift | 20:02 | |
| notmyname | cschwede: I actually think that's the problem ;-) | 20:14 |
| notmyname | cschwede: I don't know of anyone working on swiftclient tests | 20:15 |
| notmyname | (you could probably leave out "tests" and still be accurate) ;-) | 20:15 |
| *** joeljwright has joined #openstack-swift | 20:23 | |
| *** joeljwright1 has joined #openstack-swift | 20:24 | |
| mjseger | notmyname: I just installed the new swiftclient with the hopes of seeing if nagel is disabled and that 1K puts are faster, but... I get I get errors when running the swift command, no doubt because I didn't do everything I needed to | 20:27 |
| mjseger | is it worth documenting exactly what needs to be done for those of us who only occasionally install this stuff via a tarball? | 20:27 |
| *** joeljwright has quit IRC | 20:28 | |
| mjseger | I'm certainly wiling to play the newbie in this exercise ;) | 20:28 |
| *** gvernik has quit IRC | 20:29 | |
| mjseger | hmm, seems to be working correctly now so I'm not sure what happened. sorry about that... | 20:34 |
| *** joeljwright1 has quit IRC | 20:35 | |
| notmyname | mjseger: no worries. glad you got it working, and thanks for looking at that | 20:38 |
| mjseger | notmyname: so here's the deal now, wrt nagel - it's NOT disabled | 20:42 |
| mjseger | according to one of my colleagues, there are apparently a number of pieces of various versions and if you get the right combination., nagel WILL be, but as for the way I installed this it isn't | 20:43 |
| mjseger | I think he had said you needed the latest request library and somethign about having to install at least some things with pip | 20:44 |
| openstackgerrit | Christian Schwede proposed a change to openstack/python-swiftclient: Add tests for bin/swift https://review.openstack.org/73710 | 20:47 |
| cschwede | notmyname: ok, thanks - I think tristanC will work on tests, and I'm working also on some tests | 20:51 |
| *** joeljwright has joined #openstack-swift | 20:52 | |
| *** tongli has quit IRC | 20:55 | |
| *** joeljwright has quit IRC | 20:56 | |
| *** csd has quit IRC | 20:57 | |
| *** gyee has quit IRC | 21:04 | |
| *** byeager has quit IRC | 21:04 | |
| *** byeager has joined #openstack-swift | 21:05 | |
| *** krtaylor has quit IRC | 21:08 | |
| *** byeager has quit IRC | 21:09 | |
| mjseger | notmyname: eureka! I dug through my notes and here's the deal. you need to download requests-2.2.1.tar.gz and install it with pip. I did that and my 1K object put IOPS doubled!!! | 21:13 |
| *** dhellmann has left #openstack-swift | 21:17 | |
| portante | nice | 21:26 |
| *** csd has joined #openstack-swift | 21:30 | |
| *** byeager has joined #openstack-swift | 21:34 | |
| *** byeager has quit IRC | 21:38 | |
| notmyname | mjseger: great to hear! | 21:45 |
| notmyname | cschwede: thanks :-) | 21:45 |
| * notmyname is back from lunch, as you can see | 21:45 | |
| *** dmsimard has quit IRC | 21:50 | |
| *** joeljwright has joined #openstack-swift | 21:53 | |
| peluse | mjseger: so coming in on the tail end of this... what did you do/use to double your 1K PUTs and why/how does it work? | 21:55 |
| *** joeljwright has quit IRC | 21:59 | |
| creiht | notmyname: not sure if anyone has started project ipa yet, but I have it in progress | 22:06 |
| notmyname | creiht: not AFAIK. thanks! | 22:07 |
| *** hurrican_ has joined #openstack-swift | 22:07 | |
| * torgomatic is about ready to go start an IPA project, but that's something else entirely | 22:08 | |
| notmyname | torgomatic: did you finally get your brewing parts cleaned up again? | 22:09 |
| torgomatic | notmyname: one of these weekends I'll have to give it a go... but my current goal is to reduce the amount of beer in the world :) | 22:09 |
| *** zackf has quit IRC | 22:10 | |
| luisbg | torgomatic, IPA! | 22:10 |
| *** hurricanerix has quit IRC | 22:10 | |
| luisbg | start by reducing those | 22:10 |
| *** hurrican_ has quit IRC | 22:11 | |
| *** krtaylor has joined #openstack-swift | 22:14 | |
| *** tdasilva has left #openstack-swift | 22:17 | |
| notmyname | now time to go screw drives into drive trays... | 22:23 |
| *** joeljwright has joined #openstack-swift | 22:55 | |
| *** joeljwright has quit IRC | 23:02 | |
| notmyname | 12 drives done. 36 to go | 23:07 |
| creiht | notmyname: sounds like you need an ops team :) | 23:08 |
| notmyname | heh :-) | 23:08 |
| glange | sounds like you got screwed | 23:08 |
| creiht | haha | 23:08 |
| notmyname | I did bring my power drill to the office today | 23:08 |
| notmyname | peluse: around? | 23:11 |
| creiht | notmyname: ok so for ipa, how do you want to do the versioning? | 23:17 |
| creiht | just drop pbr.version all together, and update the versions? | 23:17 |
| creiht | or check if pbr is availabe, if so use pbr | 23:17 |
| *** krtaylor has quit IRC | 23:24 | |
| creiht | I'll start with the later | 23:25 |
| notmyname | creiht: ok | 23:25 |
| notmyname | creiht: while I still | 23:25 |
| notmyname | ugh. typing | 23:25 |
| notmyname | creiht: while I still _really_ like the concept of version numbers in VCS, the implementation, especially with milestone-proposed, actually makes it both complex and somewhat inaccurate | 23:26 |
| creiht | notmyname: so what would you like? | 23:26 |
| creiht | for version | 23:27 |
| notmyname | creiht: so I want to do one thing, not either thing. you should have the same version in /info no matter what you have installed on your build box | 23:27 |
| creiht | k | 23:27 |
| notmyname | creiht: so let's move back to the version in the file. it means there will always be a patch dance at release time (which will be especially painful in the face of gate issues), it keeps think simple | 23:27 |
| notmyname | creiht: thoughts? | 23:27 |
| creiht | that's fine with me | 23:28 |
| creiht | I was just a little worried that might break something with the ci stuff | 23:28 |
| creiht | if it was looking for the git commit hash tag in the version | 23:28 |
| notmyname | shouldn't as long as we keep version numbers going up | 23:28 |
| creiht | k | 23:28 |
| notmyname | creiht: we'll probably also have to burn a version number on this so we have the incrementing versions | 23:28 |
| creiht | so what should the current version be? | 23:28 |
| notmyname | assuming it landed today, the hard-coded version would be 1.13-dev (we're currently 1.12.foo.pbr.stuff) | 23:29 |
| creiht | k | 23:29 |
| notmyname | hmm...so that would still make the next release 1.13, which doesn't use up a version number | 23:30 |
| notmyname | ugh. it also means we (I) need to know the next version number at the current release time. ie minor vers increment or rev number increment. oh well. | 23:30 |
| clarkb | you can contineu to do post versioning | 23:31 |
| notmyname | clarkb: tell me more :-) | 23:31 |
| clarkb | notmyname: pbr says current version is 1.12.stuff. stuff comes from the number of commits since 1.12 and a git sha | 23:31 |
| clarkb | so do 1.12.1-dev | 23:32 |
| clarkb | as the current version | 23:32 |
| creiht | notmyname: even if we label it 1.13-dev, and you decide later to release as 1.14, acn't you just go ahead and do that? | 23:32 |
| clarkb | (or similar would actually need to check the pypi version number rules before settling on someting) | 23:32 |
| notmyname | creiht: yes, but I couldn't do 1.12.1 | 23:32 |
| creiht | ahh | 23:32 |
| creiht | yeah then we do what clarkb says | 23:32 |
| creiht | :) | 23:32 |
| notmyname | right. that's what we were doing pre-pbr. at least I think we finally settled on that | 23:33 |
| notmyname | clarkb: well, in the special case of this patch, we'll still need to move to 1.13. since we're already past 1.12.1 | 23:33 |
| creiht | '1.12.0.55' | 23:33 |
| creiht | that's what it is right now | 23:33 |
| notmyname | ah | 23:33 |
| creiht | well .somerev | 23:33 |
| notmyname | so 1.12.1-dev works, then. do that :-) | 23:33 |
| creiht | k | 23:33 |
| notmyname | ok, back to screwing | 23:34 |
| notmyname | creiht: unless you have something else? | 23:34 |
| creiht | don't think so | 23:34 |
| notmyname | k | 23:34 |
| creiht | should have the merge prop up shortly | 23:34 |
| notmyname | cool. we should beat on it, then I want to make sure that -infra is aware and can work with it | 23:35 |
| creiht | yeah | 23:35 |
| notmyname | clarkb: so no need to go -1 it right after creiht submits is ;-) | 23:35 |
| creiht | lol | 23:35 |
| creiht | I've kept setup.cfg and read the values from that in setup.py | 23:36 |
| clarkb | notmyname: it will work fine as long as python setup.py stuff uses the old pbr version | 23:36 |
| creiht | so if you have to use a pbr based setup.py, you can still | 23:36 |
| creiht | clarkb: I'll send it up to see what you think | 23:37 |
| * mordred raises his hand - curious as to what the approach is intended to be and whether or not it's duplicative (or could be) of work discussed for pbr | 23:37 | |
| creiht | mordred: if a single list comprehension is deplicative, then I'm not worried about it :) | 23:38 |
| mordred | I'm not worries - I'm just curious | 23:38 |
| mordred | worried | 23:38 |
| creiht | sure | 23:38 |
| creiht | it will be up shortly | 23:38 |
| mordred | cool | 23:39 |
| mordred | I look forward to reading it | 23:39 |
| openstackgerrit | Chuck Thier proposed a change to openstack/swift: Make PBR based setup completely optional https://review.openstack.org/73738 | 23:39 |
| creiht | there you go | 23:40 |
| creiht | mordred: we still use setup.cfg, so if you throw the generated setup.py to use pbr, it should still work | 23:40 |
| creiht | but pbr isn't used by default | 23:40 |
| creiht | clarkb, mordred -^ | 23:41 |
| creiht | let me know your thoughts | 23:41 |
| mordred | ok. just fyi - the thing I was looking at doing next with pbr was generating a pure python setup.py that didn't consume pbr if you were consuming from the source tarball. not sure if you'll care or not when that lands | 23:41 |
| *** kris_h has quit IRC | 23:41 | |
| clarkb | creiht: it should be used by default | 23:42 |
| creiht | clarkb: why | 23:42 |
| clarkb | otehrwise all of the CI tooling will need to be changed | 23:42 |
| creiht | so here's the thing | 23:42 |
| creiht | the standard way to install stuff with python is | 23:43 |
| mordred | broken | 23:43 |
| creiht | sudo pyton setup.py install | 23:43 |
| creiht | which all deployers are going to do | 23:43 |
| creiht | I want to optimize for not causing deployers issues | 23:43 |
| creiht | even if that requires a little work on the ci side | 23:43 |
| mordred | sudo pip install . is what all deployers shoudl do | 23:43 |
| mordred | because it doesn't break due to easy_isntall being broken | 23:43 |
| creiht | mordred: not at all | 23:43 |
| mordred | easy_install is insecure. you should never touch it any more for installation, unless you want to get p0wned | 23:44 |
| creiht | if you drop in the autogenerated setup.py everything should still work | 23:44 |
| * creiht sighs | 23:44 | |
| creiht | this has nothing to do with that | 23:44 |
| mordred | just saying | 23:44 |
| mordred | it does | 23:44 |
| mordred | because you're putting things into install_requires | 23:44 |
| mordred | and then suggesting that python setup.py install should be used | 23:44 |
| mordred | that causes easy_install to get triggered for dependency resolution | 23:45 |
| mordred | which is insecure | 23:45 |
| mordred | that said - I do not believe your patch will break the gate | 23:47 |
| creiht | if you are worried about the security, I can remove the requires= like it was a long time ago | 23:47 |
| creiht | I've never been a fan of the auto install dependencies stuff anyways | 23:47 |
| clarkb | mordred: I am more concered about the tarball and pypi jobs instead of the gate | 23:48 |
| creiht | clarkb: so what do we need to make sure the tarball and pypi jobs don't have issues | 23:48 |
| mordred | well, it'll certainly make that work even more different | 23:48 |
| clarkb | creiht: consistency in versioning | 23:51 |
| clarkb | creiht: so that the intermediate tarballs don't generate cruft | 23:51 |
| clarkb | and are upgradable as expected and so on | 23:51 |
| clarkb | the version question is actualy a fun one | 23:52 |
| creiht | when are tarballs generated? | 23:53 |
| creiht | clarkb: -^ | 23:55 |
| clarkb | after every commit | 23:55 |
| creiht | ok | 23:56 |
| clarkb | * every merge | 23:56 |
| creiht | and what do you mean by they have to be upgradeable? | 23:56 |
| creiht | if you run setup.py of the same version it still installs that version | 23:56 |
| *** joeljwright has joined #openstack-swift | 23:57 | |
| clarkb | I am thinking from the perspective of pip, but pip will require an override in either case now that I think about it so that may not be an issue | 23:57 |
| *** Midnightmyth has quit IRC | 23:57 | |
| creiht | mordred, clarkb -> I will also be happy to migrate this to distutils2 once it gets in to a stable state (if that helps any) | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!