21:00:01 <notmyname> #startmeeting swift
21:00:02 <openstack> Meeting started Wed Jul 29 21:00:01 2015 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:07 <openstack> The meeting name has been set to 'swift'
21:00:12 <notmyname> who's here for the swift meeting?
21:00:15 <jrichli> o/
21:00:16 <cschwede> o/
21:00:17 <ho> o/
21:00:18 <hurricanerix> o/
21:00:18 <blmartin> o/
21:00:20 <redbo> \o
21:00:20 <joeljwright> I'm here
21:00:23 <brnelson> o/
21:00:26 <kota_> o/
21:00:29 <clayg> :P
21:00:33 <clayg> joeljwright: !
21:00:35 <torgomatic> <-
21:00:37 <mattoliverau> o/
21:00:44 <notmyname> great!
21:00:51 <notmyname> agenda this week is
21:00:53 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:15 <notmyname> a few patches to go over, but first some general logisitics
21:01:31 <notmyname> #topic general
21:01:36 <tdasilva> hi
21:01:59 <notmyname> hackathon etherpad was set up by hurricanerix and can be used to collect some thoughts and topics before we get to austin
21:02:01 <notmyname> #link https://etherpad.openstack.org/p/swift-midcycle-aug-2015
21:02:11 <notmyname> so if you've got stuff you want to discuss, please add it
21:02:26 <haypo> o/
21:02:34 <notmyname> we'll do the same we've done in the past by making a big list of things on the first morning, but this can seed that list
21:02:46 <notmyname> so as you think of stuff, write it down!
21:03:06 <minwoob_> o/
21:03:08 <notmyname> also, the ops midcycle is coming up https://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-17703258924
21:03:18 <notmyname> any questions from anyone on either of those?
21:03:59 <notmyname> ok, let's move on to the meaty stuff
21:04:10 <notmyname> #topic patches: flake8 changes
21:04:14 * peluse_ likes meat
21:04:17 <notmyname> #link https://review.openstack.org/#/c/205977/
21:04:31 <notmyname> this is part of the general move to support py3 set of stuff
21:04:44 <notmyname> however this one has some implications
21:04:57 <notmyname> first, why this patch?
21:05:20 <haypo> notmyname: is it a question? :-p
21:05:30 <notmyname> yeah, I was trying to type up where it started
21:05:42 <haypo> notmyname: the main idea is to reduce technical debt in swift
21:05:46 <clayg> I don't like blacklists, and I don't understand who broke - i would prefer to not merge without other information
21:05:48 <haypo> hacking 0.8 is now quite old
21:06:00 <haypo> technically, hacking 0.8 is incompatible with pbr 1.0
21:06:17 <haypo> but we need pbr >= 1.0 since yesterday, environment markers are now used on dnspython
21:06:28 <notmyname> ah, that's it
21:06:28 <haypo> the "; python_version == '2.7'" prat
21:06:29 <haypo> part
21:06:52 <notmyname> dnspython is using pbr? or just newer env markers?
21:06:56 <haypo> clayg: " I don't understand who broke" sorry, could you please elaborate?
21:07:14 <haypo> my patch doesn't disable existing tests, but it enables more (new) tests
21:07:20 <haypo> notmyname: env markers
21:07:20 <sigmavirus24> clayg: the break was in pep8 between 1.4.5 and 1.4.6
21:07:21 <notmyname> so py3 needs new dnspython which needs newer pbr which needs newer hacking
21:07:27 <sigmavirus24> haypo's link in his commit message is the wrong line though
21:07:28 <haypo> notmyname: you need pbr in swift to support env markers
21:07:57 <clayg> remember when we used to just need setuptools 0.6 and like *everyone* already had setuptools 0.6 - those were the days
21:07:57 <notmyname> ok, so that's the "why was this patch even proposed", ultimately
21:08:06 <haypo> notmyname: hum, even for python 2, you will need pbr >= 1.0 to get new global requirements
21:08:07 <clayg> notmyname: got it!
21:08:16 <redbo> need is such a strong word
21:08:30 <clayg> "to get global requirements" isn't really an value prop :\
21:08:34 <notmyname> but the implication is that now the flake8 tests are a blacklist of things to not test instead of a whitelist
21:08:41 <notmyname> that's the big part I want to discuss
21:08:49 <sigmavirus24> notmyname: right and that's for the foreseeable future
21:08:55 <clayg> ^ that feels like a break, i used to use the tool like this, but it won't let you do that anymore
21:09:03 <notmyname> clayg: I tend to agree
21:09:05 <haypo> notmyname: technically, i didn't try to keep the existing approach (whitelist)
21:09:06 <sigmavirus24> clayg: "now" for 2 years
21:09:17 <notmyname> clayg: well, wait, that's not actually true
21:09:20 <sigmavirus24> haypo: that would be more verbose
21:09:22 <notmyname> here's what happened
21:09:34 <haypo> notmyname: the practical problem is that hacking 0.10 adds a lot of new checks, like in the E category, and i wanted to propose a short patch
21:09:56 <haypo> not propose a patch upgrading hacking 0.10 and modifying 1000 files to fix new checks
21:10:02 <notmyname> newer flake8 has newer tests, at least one of which we dont' want. but we can't have both select and ignore (even with the current state of things--we just aren't ignoring a subset now)
21:10:18 <sigmavirus24> notmyname: correct
21:10:38 <notmyname> so to ignore the newer Fxxx test, we have to list all the ones we ignore instead of selecting the ones we want to check
21:10:38 <clayg> hacking adds "E" checks!?  I thought hacking added "H" checks?
21:10:43 <sigmavirus24> and while that fix will land in pep8 hopefully after I get time to fix it, it'll be released in 1.6.x which hacking 0.10.x won't use
21:11:00 <haypo> clayg: "E" comes from pep8, "H" comes from hacking
21:11:01 <sigmavirus24> clayg: pep8 adds checks during each 1.y release
21:11:04 <notmyname> haypo: which was the Fxxx test we talked about ignoring
21:11:14 <notmyname> ?
21:11:26 <clayg> haypo: oh, so i mis read "hacking 0.10 adds a lot of new checks, like in the E category"
21:11:37 <sigmavirus24> notmyname:  probably redefinition of a var inside a list comprehension
21:11:43 <notmyname> yeah, that one
21:11:55 <sigmavirus24> (which is only a problem on Py2)
21:12:09 <haypo> notmyname: my patch ignores 7 new E checks and 2 new F checks, https://review.openstack.org/#/c/205977/6/tox.ini
21:12:13 <notmyname> so we could scrub the repo for it so it passes. would that allow us to keep the blacklist method?
21:12:16 <notmyname> haypo: ah, o
21:12:25 <clayg> I'm fine with this change uprades the test requirement from pep8 1.2.3 to pep8 1.3.1 and fixes all the breaks
21:12:42 <haypo> i'm volunteer to fix checks which make sense, if you will accept such changes
21:13:03 <haypo> (well, docstring is not my first target for example)
21:13:11 <notmyname> clayg: did you accidentally a word?
21:13:11 <clayg> "redefinition of a var inside a list comprehension" <- that's a flake8 check not pep8 check right?
21:13:16 <clayg> I'm fine to ignore flake8 checks
21:13:16 <notmyname> correct
21:13:24 <sigmavirus24> clayg: that's a pyflakes check
21:13:29 <haypo> clayg: pep8 comes from hacking. we don't specify pep8 requirement directly
21:13:48 <haypo> clayg: hacking is a meta-package for pep8+flake8 (and pyflakes), which defines the expected version
21:13:52 <clayg> haypo: well... i guess that's one way to do it
21:14:40 <clayg> haypo: I am aware of that point, I also know that the version requirements in hacking are loose and you can *install* a version of pep8 that will acctually break your pep8 checks on the swift code base but still be "compatible" with hacking
21:14:40 <haypo> clayg: upgrading pep8 alones will not fix the issue of pbr version (support pbr >= 1.0)
21:14:54 <sigmavirus24> clayg: actually hacking pins pep8
21:15:01 <clayg> ok, well - i think you're saying these are seperate issues and they agree
21:15:17 <haypo> sigmavirus24: hum, we may add a line _after_ the hacking dependency?
21:15:30 <sigmavirus24> clayg: hacking 0.8.0 is incompatible with pbr 1.x and that's why haypo is doing this
21:15:31 <clayg> sigmavirus24: was that always true!  it's quite possible I have misremembered fucking around trying to get flake8+pep8+hacking to all line up and not yell at me while hacking on swift!
21:15:36 <haypo> but i'm not a fan of trying to downgrade pep8 after hacking installed a newer version
21:15:51 <sigmavirus24> haypo: there's been discussion of hacking handling those deps directly and removing them from g-r/test-requirements.txt
21:16:03 <sigmavirus24> haypo: that shouldn't happen
21:16:04 <haypo> notmyname: sorry, but what is your main concern about the blacklist approach?
21:16:19 <clayg> i'd rather opt into F and H checks
21:16:20 <haypo> notmyname: do you fear that hacking adds new checks which will break gates?
21:16:21 <sigmavirus24> haypo: I think notmyname's concern is new checks will be added and slip in on an upgrade
21:16:23 <notmyname> haypo: sigmavirus24: so is one option to ignore the F checks entirely?
21:16:26 <clayg> <- personally
21:16:38 <sigmavirus24> notmyname: if you want no checks from pyflakes at all, that will work
21:16:46 <haypo> notmyname: you mean E and F and H?
21:16:52 <sigmavirus24> pyflakes warns about unused imports, vars, and other things
21:17:00 <haypo> notmyname: if you ignore E, F and H, ... hum, no more checks are executed?
21:17:18 <haypo> notmyname: my patch ignores checks in categories E, F and H :-/ -- https://review.openstack.org/#/c/205977/6/tox.ini
21:17:24 <zaitcev> I am against opting in, for the reason in haypo's words "Blacklisting checks permits to detect new bugs when upgrading the tools."
21:18:03 <haypo> zaitcev, notmyname : sorry, i don't know how hacking handles upgrades, but i expect that *no* new test is added in minor releases
21:18:08 <haypo> 0.10.x
21:18:16 <zaitcev> That presumes a certain goodwill on the part of toolmakers, however. If they start loading us up with moronic useless checks, I'm going to change my mind.
21:18:16 <clayg> zaitcev: did i read that correctly?  "new version of tool, can't commit to swift until you add a change to ignore the new rule you care about" is a +2 from zaitcev?
21:18:29 <notmyname> the difference is a blacklist will keep the code from unexpectedly breaking if the gate updates a dependency. the whitelist approach is that we automatically are tested against every new changes that's added
21:18:30 <sigmavirus24> haypo: correct
21:18:33 <haypo> please remind that nova, cinder, neutron, etc. are all using hacking 0.10 with the blacklist config
21:18:56 <haypo> it would be a major outage to add random new test in nova, cinder, neutron, etc.
21:19:00 <clayg> zaitcev: we currently think most H rules are - well I wouldn't call them "moronic" - just we've explicitly decided they don't apply to improving the maintainability of swift
21:19:00 <torgomatic> Eh, I don't think it's that big a deal. If we lock down the hacking version (and we do), then no new version can sneak in, hence no new tests to break stuff. When we upgrade hacking, we blacklist all the new checks.
21:19:23 <sigmavirus24> torgomatic: right
21:19:26 <haypo> that's why the requirements is : hacking<0.11,>=0.10: it's a deliberate choice to block hacking 0.11.x
21:19:26 <zaitcev> clayg: Yes. Basically I'm betting that the scenario you're describing isn't going to be happening often, or that we opt to fix the bugs it finds instead of adding ignore rules.
21:19:37 <clayg> torgomatic: ok i like that - but we currently give hacking a window - not a pin
21:19:48 <haypo> i don't understand why you expect issues specific to Swift
21:19:55 <sigmavirus24> clayg: as hacking core I can guarantee 0.10.x will see no new rules
21:19:56 <clayg> torgomatic: and this is just us trying to move to the next window (technically we managed to skip one)
21:19:58 <haypo> all openstack are now using hacking with the same config
21:20:04 <torgomatic> It's a little more work, but we upgrade hacking every year or two at most, so meh
21:20:19 <clayg> sigmavirus24: oh fair enough - but full me tiwce ;)
21:20:28 <clayg> torgomatic: +2 I can live
21:20:29 <sigmavirus24> clayg: I only became a core at the summit so
21:20:29 <haypo> hacking is part of OpenStack, it's different of projets which are managed outside OpenStack
21:20:44 <haypo> hacking developers is well aware of the mess of broken gates ;-)
21:20:53 <notmyname> haypo: not "expect", but this is the repo we deal with, so we want to avoid setting potential land mines for ourselves
21:20:54 <haypo> sigmavirus24: hey, congrats :)
21:21:10 <sigmavirus24> Thanks ... if congratulations is the right thing to offer =P
21:21:19 <haypo> notmyname: if someone goes bad, you can now complain to sigmavirus24 :-D
21:21:30 <haypo> oops
21:21:35 <haypo> if something*
21:21:38 <sigmavirus24> as you would with flake8, pep8, mccabe, pyflakes, requests, ... ,etc
21:21:51 <acoles> regardless of blacklist or whitelist, my concern with the patch is that it ignores Exxx rules that are not ignored on master e.g. E113 so it weakens the test
21:21:51 <haypo> sorry, i'm tired. it's 23:21 here :-) (if something goes wrong, ...)
21:22:13 <peluse_> Im' tired too - its 2:21pm here :)
21:22:21 <haypo> acoles: oh, please tell me if you see checks which are ignored with my patch, but not ignored before
21:22:24 <notmyname> ok, so as I hear it right now, zaitcev thinks it's fine, torgomatic thinks it's unlikely to happen often, and clayg got beat down. cschwede: tdasilva: kota_: acoles: what do you thing?
21:22:24 <acoles> haypo already fixed the patch to include E251, which was being ignored
21:22:31 <acoles> haypo: E113
21:22:35 <haypo> acoles: from my understanding, some E rules became more strict
21:22:48 <peluse_> hey what about what I think??
21:22:50 <sigmavirus24> ^ that's a possibility with pep8
21:22:51 <acoles> haypo: maybe but we shoudlnt just switch them off if they got stricter
21:22:53 <haypo> acoles: and i'm volunteer to fix quickly new (and old) checks :)
21:23:00 <clayg> haypo: i doubt there's a new pep8 - probably the tool got better at enforcing it
21:23:21 <haypo> acoles: agreed. that's why i already updated my patch to E251 checks
21:23:34 <clayg> acoles: +2, let make the change that says "install latest pep8 and fix all the breaks" - might make this next part easier?
21:23:37 <cschwede> notmyname: no big objections from my side
21:23:39 <acoles> haypo: but how do i know what was not ignored before and now is without trial and error - where is there a list of new Exxx codes for hacking 0.10
21:23:40 <acoles> ?
21:23:43 * notmyname notices the discrepancy between "they won't go break checks on you" and "we ignore these now because they got stricter"
21:23:59 <sigmavirus24> notmyname: hacking didn't break that. pep8 did
21:24:03 <clayg> lol
21:24:12 <sigmavirus24> probably back in early 1.5.xs
21:24:13 <notmyname> I don't care who breaks it. it keeps my code from landing
21:24:14 <clayg> sigmavirus24: but hacking PINS pep8?
21:24:19 <notmyname> lol
21:24:22 <sigmavirus24> clayg: correct
21:24:31 <haypo> acoles: i would prefer to propose separated patches for fix issues
21:24:41 <sigmavirus24> y'all don't need hacking in the gate =P
21:24:41 <haypo> acoles: oterwise, my patch may become too large :-(
21:24:44 <clayg> ok, anyway - i'm happy to be told it'll all be fine, this isn't my #1 priority
21:24:55 <haypo> acoles: i'm talking about checks which became more strict
21:24:59 <sigmavirus24> none of you seem to like it so
21:25:01 <clayg> I think acoles is making a good point - let's just stick with our goals
21:25:10 <notmyname> clayg: so the issue is that without this py3 is dead in the water
21:25:11 <clayg> we do E, we generally like F, H is pretty meh
21:25:21 <acoles> haypo: ok but then reverse the dependency - small patches to fix stuff that breaks with stricter existing checks, then bump the version
21:25:45 <clayg> acoles: seems like the best way to go about it
21:25:49 <acoles> haypo: so the patch taking us to hacking 0.10 has fewer ignores when it lands
21:25:56 <haypo> acoles: i prefer to upgrade hacking first
21:26:05 <haypo> acoles: it's easier to enable more checks after
21:26:07 <clayg> acoles: as long as the ignores are a couple of F's and H's
21:26:09 <notmyname> sigmavirus24: we're a complicated, grumpy group. don't assume we don't like it yet or can't come up with an answer ;-)
21:26:12 <haypo> and it unblocks my issue
21:26:20 <acoles> haypo: but then if the other patches don;t land....?
21:26:28 <sigmavirus24> notmyname: I totally grok the grump part
21:26:37 <haypo> acoles: it's your role to then review my following patches :)
21:26:38 <sigmavirus24> *grumpy
21:26:43 <haypo> acoles: it's just a matter of days
21:26:45 <acoles> haypo: yah i know :D
21:26:47 <sigmavirus24> I'm the grumpy person on my team despite being the youngest
21:27:04 <acoles> haypo: but days become weeks all too easy round here ;)
21:27:07 <haypo> acoles: i expect very short patches in fact
21:27:23 <haypo> it's just a mess to handle a patch serie in gerrit
21:27:26 <haypo> i hate doing that
21:27:40 <notmyname> acoles: so what is your idea? keep the current checks, fix for tighter checks, then bump the version?
21:28:04 <notmyname> ...version of hacking
21:28:13 <haypo> notmyname, acoles : if you really want to ensure that old checks are not disabled, i would prefer to work on a single giant patch
21:28:20 <notmyname> haypo: and you want to bump hacking now and fix check later by readding the checks
21:28:24 <clayg> notmyname: if the question was "will a blacklist approach going to fly" torgomatic and others seem to have answered yes
21:28:35 <notmyname> yeah, I was just noticed we kinda moved past that
21:28:53 <torgomatic> and it removes that py3 blocker in quite a short time
21:28:55 <acoles> notmyname: my idea is that stuff that would fail on master should still fail after any patch lands, not rely on the promise that we will claw back in future
21:28:58 <haypo> notmyname: i check to start on a fresh and well designed basis, with a list of ignored checks
21:29:08 <clayg> ok, so now we're just reviewing the patch - black list is fine - but why is it removing checks we want instead of fixing the offenders?
21:29:15 <acoles> notmyname: sounds like that could require a bigger patch to fix up for stricter checks
21:29:19 <haypo> notmyname: and then fix checks. it will be more explicit, because these patches will _enable_ checks
21:29:42 <haypo> clayg: i don't know which tests are old or new
21:29:49 <notmyname> yeah, I feel that a promise to readd checks is like a promise to write tests and docs later.
21:29:55 <acoles> clayg: +1
21:30:01 <haypo> clayg: i simply ignored all checks which made tox -e pep8 to fail
21:30:04 <clayg> haypo: we like E, F is gnerally good, H is meh
21:30:07 <zaitcev> sick burn
21:30:24 <clayg> haypo: ok, well no one likes that approach
21:30:42 <clayg> haypo: sorry :\
21:30:47 <torgomatic> I kind of do, actually
21:30:53 <clayg> LOL!
21:30:57 <clayg> ok then!
21:31:00 <torgomatic> it's not like we have those checks today, right?
21:31:01 <acoles> haypo: do you have any idea how big the patch would be with no E ignored and the fixes made to pass pep8? we can review big patches :)
21:31:05 <clayg> torgomatic: go +2 it - haypo  you only need one more
21:31:08 <torgomatic> k
21:31:10 <acoles> torgomatic: some we do
21:31:12 <haypo> acoles: no
21:31:14 <acoles> like E113
21:31:28 <torgomatic> oh
21:31:32 <haypo> acoles: you can see the topic pep8
21:31:48 <haypo> acoles: i wrote other patches to fix pep8 checks
21:31:52 <haypo> https://review.openstack.org/#/q/status:open+project:openstack/swift+branch:master+topic:pep8,n,z
21:32:22 <clayg> haypo: those titles look like H checks?
21:32:22 <torgomatic> this change doesn't run less checks than before.”
21:32:23 <haypo> for example, fixing H232 only changes a single file (two lines)
21:32:30 <torgomatic> ^^ from the commit message
21:32:47 <haypo> clayg: https://review.openstack.org/#/c/205964/ giant patches fixes a lot of things, but i don't remember which checks
21:33:01 <notmyname> I think we're getting into patch review which can stay in gerrit (or the -swift channel)
21:33:13 <clayg> notmyname: well hold on
21:33:17 <haypo> torgomatic: that's my bet, but acoles says that i'm wrong, i disabled some existing tests
21:33:19 * notmyname holds
21:33:22 <clayg> notmyname: there's a bunch of patches here
21:33:24 <haypo> torgomatic: because they became more strict
21:33:53 <clayg> notmyname: do we have a plan or is it just "go review"
21:34:05 <haypo> notmyname: well, you should take a decision, we will not spend the whole meeting on this issue, no?
21:34:12 <tdasilva> I might be missing something here, but it seems like a good compromise would be chained patches?
21:34:13 <acoles> torgomatic: so with E251 it seems it got stricter, haypo saw some fails and then disabled it, but now haypo has done the work to fix the fails, which is great
21:34:21 <notmyname> feels like it's even more complicated than when it was introduced as a discussion
21:34:28 <torgomatic> acoles: haypo: got it, thanks
21:34:46 <acoles> torgomatic: but i just randomly broke E113 on master so there's another example but none of us seem to know which E tests exist on master
21:35:06 <haypo> i don't understand why you care so much in the order in which patches are merged
21:35:10 <torgomatic> heh, I can't even get my code to pass unit tests, much less a linter
21:35:12 <clayg> ok, well a promise to "fix it later" is a fair bit more nebulous than "here's a chain the ignores some rules and then systematically enables them"
21:35:18 <notmyname> I think the resolution for now is that we need to review these. especially acoles and torgomatic
21:35:23 <haypo> IMHO in 3 weeks, all checks, old and new will be fixed, that's all :-p
21:35:23 <acoles> haypo: btw really appreciate the work you have done, concern is just with ordering the changes
21:35:43 <notmyname> haypo: I definitely agree with acoles. thank you for sticking with this
21:36:15 <clayg> acoles: if the code is already written do you care about the order of the patches?
21:36:17 <haypo> notmyname: well, its up to you
21:36:48 <clayg> haypo: is there a final patch I can checkout and see yup, all tests pass and no checks i care about are ignored - then just go +2 everyhting above it?
21:37:16 <acoles> clayg: not if they all merge :) i guess we'll eventually be consistent with master
21:37:20 <haypo> clayg: no. i didn't write all patches yet
21:37:32 <haypo> clayg: usually, i send a few patches, and wait until they are reviewed
21:37:41 <haypo> clayg: it's really easy to fix pep8 checks...
21:37:52 <clayg> sure i useually do that too
21:38:01 <clayg> haypo: the harder part is the conflicts in other patches when you merge them?
21:38:01 <notmyname> ok, we've got to move on to a few other things in the meeting :-)
21:38:05 <haypo> clayg: some checks are really coding style. i don't know if you want to enable _all_ pep8 checks
21:38:11 <haypo> like the coding style for docstrings?
21:38:25 <acoles> notmyname: tomorrow i will take haypo patch and enable all the Exxx and see how bad things are
21:38:32 <clayg> es all pep8 checks - most flake8 checks - basically no hacking checks (it was already in the tox file describing what we want)
21:38:34 <haypo> that's why i preferred to ignore tests, and _then_ discuss which tests are important
21:38:35 <notmyname> acoles: thanks
21:39:00 <notmyname> ok, next one should be briefer
21:39:09 <notmyname> #topic patches: test-requirements updates
21:39:12 <clayg> acoles: sigh, bigger fish man
21:39:13 <notmyname> #link https://review.openstack.org/#/c/204179/
21:39:50 <notmyname> this one is more of a "what do you think". it updates the test-requirements to match global requirements.
21:40:26 <notmyname> mostly an FYI, I guess. not a real big question
21:40:42 <notmyname> #topic patches: accept header in responses
21:40:44 <clayg> yeah it's fine - this helps someone?
21:40:44 <notmyname> #link https://review.openstack.org/#/c/204196/
21:40:50 <notmyname> cschwede: you brought this one up
21:41:13 <zaitcev> What in the world is "pbr at least 1.3"? I only have 0.10.8.
21:41:17 <notmyname> clayg: hopefully us. to prevent any gate issues (seems like they've come up more recetly)
21:41:35 <cschwede> yes; i was worried if there are clients that send a „accept:json“ header and currently expect html in case of an error
21:41:54 <cschwede> because that’S what it is today. and that change would fix this, but might break these clients
21:42:15 <torgomatic> if you say you accept json but don't accept json...
21:42:25 <cschwede> so, i’m fine with fixing this, but wondering if that needs to land in a new swift release?
21:42:31 <clayg> cschwede: I think it's a fair question - but what's your leaning?
21:42:41 <notmyname> what's the content type on the response? if that changes too, it's better
21:42:55 <clayg> cschwede: I don't think a swift version so muchs - maybe it needs an new api version - for some reason I think it will be fine
21:42:58 <cschwede> notmyname: text/html now, json then
21:43:28 <cschwede> clayg: yes, i tend to think the same. just wanted to raise this before putting a +2 on it
21:43:38 <notmyname> cschwede: if this doesn't change anything when the accept doesn't have json in it, then we should be ok
21:43:41 <clayg> cschwede: good call
21:43:44 <cschwede> and hear if most of us agree with this
21:44:05 <zaitcev> I think I already put +2 on it, but considering how clients didn't like "Etag", this is a possibility.
21:44:11 <notmyname> right
21:44:17 <notmyname> and in that case, we rolled back
21:44:22 <clayg> yup could break things - safer to just say no
21:44:32 <clayg> yeah we could do it and roll back if we get bit
21:44:52 <clayg> feels kinda arbitrary to let this one slide - but I'm game if ya'll are!
21:45:04 <redbo> ha
21:45:07 * clayg pops of a six shooter
21:45:13 <notmyname> redbo: what do you think?
21:45:38 <clayg> redbo thinks "bigger fish man, bigger fish"
21:45:42 <notmyname> :-)
21:46:23 <notmyname> according to the bug report on this one, a user expected json then worked around it
21:46:27 <redbo> I've never even seen a client that looks at the repsonse bodies.  But then I wonder why we need this.
21:46:41 <notmyname> so what' clayg said ;-)
21:47:03 <mattoliverau> I think, if they ask for json, we return json. The clients obviously are using some json library if asking for json, so we're fixing a bug, and they have the tools to fix the clients.. but maybe I'm grumpy cause I'm still sick :P
21:47:10 <zaitcev> redbo: It's for the recent crop of GUI things. They want to pop dialogs on error and they don't want to scrape so junk gets into various fields.
21:47:14 <notmyname> clayg: you should probably explain that for swift devs who don't know english (US?) idioms ;-)
21:47:19 <redbo> If they send "Accept: image/jpeg", we should render a jpeg that says "404 not found" and return it
21:47:45 <clayg> redbo: oh that's be a great feature!  can't wait to review!
21:47:54 <minwoob_> redbo: ^ lol
21:47:58 <clayg> ^ notmyname you can't translate this level of sarcasm
21:48:43 <zaitcev> okay, so the point is that this feature request conflates the format of listings with format of error bodies.
21:49:15 <notmyname> zaitcev: actually that's the fist "this fixes a real bug for someone" I've heard so far
21:49:18 <notmyname> so that's good.
21:49:42 <notmyname> if we've got users who need this, then I'm inclined to let it land. if this is just for some sense of "right" then no
21:49:42 <zaitcev> we're one step away from "X-Error-Accept:" now.
21:49:44 <clayg> zaitcev: no I dont' think that's the point - everyone thinks it's not that useful to return html to command line api clients - it just what it does today
21:49:59 <clayg> notmyname: that's a good call!  who needs this!?
21:50:05 <zaitcev> clayg: yeah and I saw truncated logs
21:50:18 <notmyname> zaitcev says UI people. who is this?
21:50:29 <torgomatic> horizon?
21:50:30 <clayg> truncated logs?
21:50:46 <clayg> anyway - honestly - like swiftclient could use this
21:51:02 <clayg> I hate the fact it spits html onto the screen - but thank the gods it didn't try to beautiful soup it
21:51:02 <notmyname> do it for joeljwright!
21:51:10 <clayg> let's just do it - yawn
21:51:13 <joeljwright> :)
21:51:15 <clayg> cschwede: thanks for asking!
21:51:32 <notmyname> ok, good
21:51:41 <cschwede> clayg: yw :)
21:51:47 <notmyname> #topic versions middleware
21:51:55 <notmyname> #link https://review.openstack.org/#/c/134347/
21:52:07 <notmyname> didn't land like we said last week we said we were going to do
21:52:18 <notmyname> tdasilva: put together a good doc on the test areas
21:52:25 <notmyname> #link https://docs.google.com/spreadsheets/d/1hyo3Q7SS70kG0ZCR3NvXJZ6ikeqqQ04RcRYjOLb44m8/edit#gid=0
21:52:28 <mattoliverau> that was probably my fault :P
21:52:29 <notmyname> so what's blocking this?
21:52:45 <mattoliverau> I confused clayg with my comments :)
21:53:18 <clayg> mattoliverau: notmyname: no it's good tdasilva fixed some issues last week - it's better than ever now
21:53:35 <clayg> if you haven't review that patch in the last few weeks you should!  I bet you'll +2 it - it's a good change
21:53:43 <tdasilva> thanks to clayg and mattoliverau for bringing up those issues
21:53:43 <notmyname> great! let's merge it this week then! it's required for some other ongiong work and needs to get out of the way
21:54:03 <zaitcev> I reviewed it 6 patches back and it was okay. But I need to re-read.
21:54:04 <clayg> tdasilva: thanks for being so diligent and doing all the work - amazing!
21:54:11 <notmyname> ok, last topic we'll have time for
21:54:15 <notmyname> #topic encryption update
21:54:18 <notmyname> #link https://etherpad.openstack.org/p/swift_encryption_issues
21:54:26 <notmyname> jrichli filled that in with details
21:54:27 <acoles> yes, great stuff tdasilva
21:54:31 <notmyname> jrichli: thanks
21:54:40 <jrichli> np
21:55:04 <notmyname> jrichli: what is there to report this week on encryption? what's blocking you or where do you need extra eyes?
21:55:13 <notmyname> acoles is back, so that helps :-)
21:55:23 <acoles> notmyname: you fool yourself
21:55:28 <jrichli> I am working on the support for footers right now.
21:55:38 <jrichli> It's going to be my frankenstein for awhile.  After/if I get something working, it would still need lots of refactoring.
21:55:57 <jrichli> it would be good to get some conversations going on those issues
21:56:01 <notmyname> ok
21:56:22 <notmyname> jrichli: did you get any feedback on the stuff you put in the etherpad yet?
21:56:32 <notmyname> we had asked for that last week, and you did it, so we owe you feedback
21:56:36 <jrichli> clayg gave me some feedback, to which I replied
21:56:42 <notmyname> thanks clayg!
21:56:52 <jrichli> and hrou has been giving me good feedback on encryption reviews
21:57:05 <clayg> notmyname: meh, not sure i'm helping
21:57:20 <jrichli> clayg: you are!  just need more of that :-)
21:57:33 <notmyname> http://i.imgur.com/ES6sP.jpg
21:57:36 <jrichli> maybe skype with acoles like you mentioned earlier
21:57:43 <jrichli> and me
21:58:08 <notmyname> ok, anything else on encryption?
21:58:08 <jrichli> notmyname: lol
21:58:11 <acoles> jrichli: wfm
21:58:19 <mattoliverau> I'll give it a read today, but be warned my brain is firing on 1/2 the cylinders.. but reading is someting I can handle :)
21:58:33 <jrichli> mattoliverau: thx!
21:58:45 <jrichli> notmyname: no, thats all i guess
21:58:57 <notmyname> ok
21:59:05 <clayg> mattoliverau: have you looked over the wiki - there's some big gaps that are not quite just "pls revw" - we don't know how some parts are supposed to work
21:59:13 <clayg> e.g. conditional if-match GETs
21:59:39 <clayg> mattoliverau: jrichli did a great job explaining what is not figured out yet
21:59:43 <clayg> ... on the wiki
21:59:58 <clayg> mattoliverau: i haven't gotten down to all of the issues either :'(
22:00:01 <mattoliverau> clayg: I'll make sure I look at that too :)
22:00:09 <notmyname> and we're out of time
22:00:10 <acoles> clayg: does wiki==etherpad?
22:00:11 <mattoliverau> I can at least get started
22:00:23 <notmyname> acoles: yes
22:00:30 <clayg> acoles: thank you sir - yes -> https://etherpad.openstack.org/p/swift_encryption_issues
22:00:33 <notmyname> thanks for coming. and thanks for working on swift
22:00:34 <clayg> not wiki :'(
22:00:38 <notmyname> #endmeeting