21:00:15 <notmyname> #startmeeting swift
21:00:16 <openstack> Meeting started Wed Nov 11 21:00:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:19 <notmyname> hello, everyone
21:00:22 <openstack> The meeting name has been set to 'swift'
21:00:27 <notmyname> who's here for the swift meeting?
21:00:28 <wbhuber> o/
21:00:28 <hurricanerix> |o|
21:00:28 <minwoob_> o/
21:00:30 <ho> hi
21:00:31 <joeljwright> evening
21:00:31 <kota_> hello
21:00:32 <jrichli> o/
21:00:38 <clayg> heyoh!
21:00:38 <torgomatic_> ䷣
21:00:56 <notmyname> did I see acoles join?
21:00:58 * briancline collapses
21:01:01 <peluse> yo
21:01:04 <tdasilva> i am
21:01:25 <notmyname> all right
21:01:35 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:42 <acoles> here
21:01:52 <jrichli> acoles!
21:01:54 <notmyname> several smaller things to go over this week, and maybe a couple of bit things
21:01:54 <peluse> acoles: thought you were hanging someone?
21:02:06 <acoles> peluse: ran out of rope
21:02:10 <tdasilva> lol
21:02:12 <clayg> heh
21:02:45 <notmyname> #topic PyECLib update
21:02:54 <notmyname> going from the top...
21:03:23 <notmyname> tsg and clayg and I have been going over the pyeclib changes, with help from lifeless in -infra for global-requirements changes
21:03:30 <notmyname> so here's the status
21:03:34 <notmyname> (and why you care)
21:03:52 <notmyname> there are a few goals
21:03:56 <clayg> hint: you don't
21:04:00 <notmyname> aww
21:04:09 <notmyname> first is to use later version of pyeclib
21:04:22 <notmyname> second is to drop any hard bundling with jerasure
21:04:29 <clayg> new bugs better than old bugs - always
21:04:38 <blmartin> awkward late hello
21:04:45 <clayg> jerasure sux INAL
21:04:49 <notmyname> third is to set it up to move into the openstack namespace so we have more of a community around landing patches
21:05:00 <clayg> openstack all the things!
21:05:08 <peluse> openstack this!
21:05:36 <notmyname> meh, in or out of the openstack namespace, it's good to have more people commit access and able to cut a release
21:05:50 <notmyname> and openstack is a convenient place with the logistics already set up
21:05:58 <peluse> agreed for sure
21:06:16 <notmyname> currently we're pinned to 1.0.7
21:06:33 <notmyname> and we've got a patch (landed yesterday) on master that lets us support >=1.0.7
21:06:51 <kota_> that's nice.
21:06:55 <clayg> oh that landed!?
21:07:02 <notmyname> so global-requirements has been bumped to >=1.0.7. next up is for us to land that to mirror g-r
21:07:08 <notmyname> clayg: yeah, I think this morning
21:07:21 <notmyname> tsg: mentioned it an hour ago or so
21:07:59 <notmyname> so once we have the >=1.0.7 patch landed, we'll bump g-r to be >=1.1.1. then we'll bump swift to be >=1.1.1 and also drop the jerasure references
21:08:31 <clayg> notmyname:  I don't think anything else goes in the >=1.0.7 change - we could start doc fixes in saio and example confs to remove jerasure references (asuming you're more on the > side of the >=1.0.7)
21:08:33 <notmyname> the reason for the dance is because of how dependencies are tested in the gate and that we have to have our requirements file be an exact string match for global requirements
21:08:42 <torgomatic_> basically https://lh3.ggpht.com/QL094vQpTcJHIxF5qVeURS-0-KpLq_ciDUzHnlYlOQ9GSO_Q98AO7b731jFG=w300
21:08:48 <notmyname> clayg: yes
21:08:48 <clayg> ^ this the part you don't care about
21:08:51 <notmyname> tsg: basically
21:08:56 <notmyname> torgomatic_: basically
21:08:57 <clayg> if you try to care you'll end up punching walls
21:09:12 <notmyname> it's true. clayg did that yesterday when he started to care about it ;-)
21:09:20 <peluse> who won?
21:09:35 <notmyname> the boss man who said go get in a quieter room ;-)
21:09:50 <notmyname> good times.
21:10:07 <clayg> torgomatic_: it's more like this -> http://static.fjcdn.com/gifs/Rude_05b797_2726116.gif
21:10:14 <clayg> and that's how dependencies get updated
21:10:32 <notmyname> so I thinkw e should be able to get this done today or tomorrow
21:10:42 <clayg> yay!
21:10:55 <clayg> notmyname: well someone needs to do the saio doc updates and scour the rest of the code for jerasure
21:10:55 <notmyname> for everyone working on it, thanks for your patience
21:11:03 <clayg> at a minimum we should get it claned out in the >=1.1.1 patch
21:11:09 <peluse> rock on... saio docs need to include how to instal isa-l also....
21:11:09 <notmyname> right. I think that's in tsg's 1.1.1 patch
21:11:10 <clayg> *cleaned
21:11:12 <peluse> is tsg doing that?
21:11:14 <clayg> oh!
21:11:16 <clayg> tsg: is a boss
21:11:22 <tsg> LOL
21:11:30 <tsg> hopefully no one breaks neutron again!
21:11:43 <tsg> (today or tomorrow that is :))
21:11:46 <notmyname> clayg: go check this one https://review.openstack.org/#/c/244287/
21:12:02 <notmyname> tsg: where's your >=1.1.1 patch with the doc updates?
21:12:05 <notmyname> and test updates?
21:12:55 <tsg> notmyname: let me get it up there later today - hadn't posted it yet (with the slight change of plans yesterday)
21:13:00 <notmyname> ok
21:13:12 <notmyname> any more questions on pyeclib before we move on?
21:13:27 <tsg> notmyname: the test updates won't be needed anymore after clayg's recent patch
21:13:34 <notmyname> right
21:13:48 <tsg> notmyname: and we are keeping jerasure in the supported list, correct?
21:13:50 <notmyname> jsut dropping jerasure from docs and unit/__init__.py
21:13:54 <tsg> notmyname: ok
21:13:56 <tsg> will do
21:14:06 <tsg> I will ;)
21:14:28 <notmyname> tsg: drop down to just liberasure. later we can readd jerasure and add isa-l
21:14:33 <notmyname> if we want
21:14:34 <clayg> tsg: I think when we say requires pyeclib>=1.1.1 we remove jerasure from the prefer list - a list of one is a good list
21:14:41 <notmyname> ya
21:14:52 <tsg> clayg: ok :)
21:15:01 <notmyname> ok, moving on (lots to cover)
21:15:09 <notmyname> #topic ring change
21:15:13 <clayg> whoa - notmyname is on a mission
21:15:16 <notmyname> clayg has a good patch up
21:15:21 <notmyname> patch 241571
21:15:22 <patchbot> notmyname: https://review.openstack.org/#/c/241571/ - Put part-replicas where they go
21:15:32 <notmyname> go review it and run your prod rings through ti!
21:15:41 <clayg> yeah!  multiple part-replica placement on same device is bullshit!
21:15:43 <notmyname> clayg: what do we need to do on it?
21:15:53 <notmyname> what do we look for?
21:15:53 * clayg *shrugs*
21:15:57 * clayg *shrugs*
21:16:28 <notmyname> clayg: you've still got a -2 on it
21:16:41 <clayg> notmyname: oh yeah i need to write words in the ring_overview
21:16:58 <briancline> oh yeah. it's on my list for tonight to run our latest ring through it
21:17:04 <clayg> I mean I don't *need* to - those words won't close the bug any faster - but I will cause folks thought that would be good
21:17:21 <notmyname> the first reason the ring stuff was updated was because sometimes you'd get more than one part placed in the exact same drive. that means that replicas lie about your durability and EC just flat-out breaks
21:17:36 <notmyname> so clayg dived in to fix it and came up with this patch
21:17:54 <clayg> notmyname: i fixed everything [1] else while i was in there!
21:17:56 <notmyname> which is a big change, but AFAIK much more tested and deterministic
21:17:57 <clayg> 1. not everything
21:18:32 <notmyname> so the first concern is that it doesn't make all your existing clusters shuffle data everywhere. that would be bad
21:19:05 <notmyname> secondly, it needs to have a good plan going forward. ie is it supportable/tested code that makes sense
21:19:11 <clayg> notmyname: yeah - it's acctually pretty agressive about fixing things - so if you give it an old ring from before overload that's all imbalanced it'll just move 50% of your parts around and be like "what?"
21:19:41 <notmyname> by "fixing" things you mean fixing the duplicate assignments
21:19:59 <notmyname> ?
21:20:09 <clayg> well either duplicates or like "bad" placements - with the replica_plan stuff you can dial into imbaance and dispersion if you can't have both
21:20:19 <clayg> so I call "fixed" meaning how successfully it filled the replica_plan
21:20:25 <notmyname> ok
21:20:32 <clayg> the default replica_plan is "as dispersable as balanced"
21:20:40 <clayg> then you add a bit of overload when things look stupid
21:20:54 <clayg> or a bunch of overload if you're like super into 507's
21:21:04 <clayg> the algo doesn't really care anymore
21:21:11 <clayg> it says there's two poles you can fit anywhere in the middle
21:21:12 <notmyname> dfg: nadeem: it would be great if you could look at the ring patch and put your rings through it
21:21:40 <dfg> notmyname: ya we're planning on it
21:21:44 <nadeem> notmyname: sure
21:21:46 <clayg> dfg: nadeem: I think all you'll get out of it is that it'll be like 10-15% slower - you're welcome
21:21:53 <notmyname> clayg: you did a great job explaining all that in tokyo. do you have those slides linked somewhere?
21:22:05 <dfg> clayg: hey- i'm not the one who does that
21:22:35 <clayg> https://docs.google.com/a/swiftstack.com/presentation/d/1HdTyMAjpauoCNpwBMyNmv_11bimZScvpRTxI-e0Gmw4/edit?usp=sharing
21:22:48 <clayg> but like... I'm not sure it's as good with out my commentary
21:22:53 <clayg> i'm like *pretty* funny
21:23:13 <notmyname> can other people see that link?
21:23:21 <tdasilva> clayg: you are probably going to get a bunch of requests
21:23:36 <clayg> notmyname: i don't know how to computer?
21:23:42 <ho> i sent it now :-)
21:24:03 <notmyname> I can work with clayg to get it publicly sharable
21:24:19 <dfg> between all of us. we'll figure that out :p
21:24:26 <nadeem> :)
21:24:32 <tdasilva> please make sure to add clayg's commentaries ;)
21:24:46 <notmyname> for everyone, please take a look at the patch. it's pretty important and promises a better way to do data placement in the cluster. and will take a while to review
21:25:11 <notmyname> ok, moving on
21:25:19 <notmyname> #topic py3 patches
21:25:38 <notmyname> there is now a Plan for the py3 port
21:26:09 <notmyname> it's nothing more complicated than (1) get a voting gate job and (2) add modules to it until we have everything tested on it
21:26:34 <notmyname> so It hink that means we'll have a steady stream of "port XXX to py3" patches for a long time
21:26:58 <notmyname> which is why someone suggested "hey, can we just agree that we can approve a py3 change with only one core +2?"
21:27:03 <notmyname> so what do you think?
21:28:07 <notmyname> is anyone uncomfortable with that? acoles clayg peluse dfg torgomatic_ tdasilva?
21:28:14 <torgomatic_> eh, I won't do it
21:28:21 <briancline> seems reasonable.. the gates are more helpful than usual for this sort of thing
21:28:22 <notmyname> won't do what? py3 reviews?
21:28:35 <torgomatic_> I've never really ported anything to py3 before, so I won't solo-approve a py3 patch because I lack sufficient confidence to do so
21:28:37 <peluse> wait, py what?  ok, yeah sure
21:28:59 <tdasilva> yeah, i'm not a big fan either (of one +2 +A)
21:29:08 <peluse> seriously though, I don't understand.  why propose just one +2?
21:29:17 <acoles> notmyname: idk i'm not sure what these patches are going to look like
21:29:33 <acoles> notmyname: maybe after the first N I/we might feel differently
21:29:38 <notmyname> the thought was only to speed up the process
21:29:56 <notmyname> and it sounds like current thinking is that we should keep with 2 +2s
21:30:05 <notmyname> I'm completely fine with that :-)
21:30:17 <kota_> +1
21:30:17 <peluse> oh geeze, I think there's probably a better way to speed it up.  maybe assign some volunteers to review them.  i dont think cutting to one +2 sounds right
21:30:22 <notmyname> #agreed py3 patches aren't special. still needs 2 cores to approve
21:30:23 <acoles> i'm with torgomatic_
21:30:35 <peluse> kota, double meaning?  heh
21:30:51 <notmyname> ok, moving on
21:31:02 <kota_> peluse: exactly, I'm with keep two +2
21:31:09 <notmyname> #topic searchlight integration / oslo.messaging
21:31:15 <notmyname> sjmc7: this is a topic you added to the agenda
21:31:26 <sjmc7> hey. this one’s under my name ( i work on searchlight) but after a conversation with briancline yesterday
21:31:47 <sjmc7> and as a followup to the presentation the IBM guys did at the summit
21:32:04 <sjmc7> the short version - to integrate swift with SL we need notifications and oslo messaging is how we’ve been doing it for other services
21:32:40 <sjmc7> there’s a patch up on swift for zaqar based notifications - would there be any objection to an optional oslo.messaging notification middleware?
21:32:51 <sjmc7> our alternative is something out of tree deployers could install
21:32:51 <tdasilva> searchlight == metadata search ??
21:33:09 <sjmc7> ah, yes, sorry
21:33:24 <sjmc7> yes, to back up a little - we’d love to index swift metadata for search
21:33:51 <notmyname> sjmc7: with any dependency addition there's the question of what it also brings in transitively. and many oslo projects also tend to bring in others like config, logging, etc. and since we don't currently use those, it's been a barrier to "just drop it in"
21:34:08 <notmyname> but that being said, I'm find with evaluating it like any other dependency addition
21:34:16 <briancline> yeah, this solves a few concerns i think we had from ibm/softlayer's perspective as well. my two biggest concerns are the auth issues (some mentioned in the review i think) and some scale concerns
21:34:34 <torgomatic_> yeah, zaqar is nice because it's just like "POST here; you're done"
21:34:37 <sjmc7> yes, i can certainly understand dependency concerns
21:35:20 <torgomatic_> if I understand, oslo.messaging drags in AMQP, so now you need a messaging broker and you need to maintain the broker and blah blah blah
21:35:26 <sjmc7> although keystonemiddleware already brings in most of oslo
21:35:28 <torgomatic_> it's like "surprise! more infrastructure!"
21:35:49 <briancline> it's pluggable -- amqp, zeromq, and i believe whatever backends kombu supports
21:35:53 <sjmc7> yes - we’re not suggesting this would be enabled by default
21:36:01 <hurricanerix> Is there any advantage to adding the middleware into Swift rather than just having it be it's own thing in Github somewhere?
21:36:08 <notmyname> sjmc7: sure. and like keystone, it would be an optional dependency to bring in. ie not something every deployer must suddenly install to upgrade
21:36:14 <sjmc7> right
21:36:16 <briancline> torgomatic_: to be fair, zaqar is also a bit of infrastructure as well
21:36:21 <torgomatic_> briancline: true
21:36:25 <sjmc7> hurricanerix - that’s an option, certainly
21:36:28 <dims> fyi, there's work ongoing to use oslo.messaging to send notifications to zaqar
21:36:39 <briancline> orly?
21:36:44 <sjmc7> the advantage of in-tree is that if the middleware structure changes it doesn’t get ignored
21:36:51 <dims> briancline right. no rpc, no rabbitmq
21:36:57 <notmyname> hurricanerix: not sure. but there's a lot of people doing metadata search, so having a common way upstream to feed that isn't a terrible idea
21:37:32 <dims> just notifications
21:37:36 <briancline> yeah, seems a lot of folks have been interested in the search use case for a few years
21:38:00 <briancline> there's also the use case of user-facing consumable notifications, which is what zaqar primarily serves
21:38:26 <notmyname> briancline: yeah, and there's some pretty interesting use cases there too
21:38:35 <sjmc7> there are other conversations about translating oslo.messaigng notifications into zaqar queues
21:38:40 <sjmc7> horizon and heat are both interested in that
21:38:49 <hurricanerix> notmyname: true, but it seems easier to let it be its own thing first, let it mature some and then if tons of people are using it, then look to add it in.  (just my opinion though)
21:38:50 <torgomatic_> there's a thing I wrote that might indirectly help with search; let me go find it
21:38:52 <notmyname> many of us have wanted some sort of notification/message thing in swift for a while
21:39:14 <torgomatic_> here we go https://review.openstack.org/212824
21:39:38 <briancline> what was the other feature discussed in vancouver that could benefit from this? was it tiering? or something else?
21:39:57 <torgomatic_> that would let you find unindexed objects in your cluster and go index them
21:40:10 <torgomatic_> or, you know, whatever. that's kind of the point.
21:40:11 <notmyname> briancline: tiering. container sync. utilization processing. probably others
21:40:47 <notmyname> torgomatic_: yeah, probably both would be needed, right?
21:40:48 <dims> torgomatic_ briancline : if there's any interest in oslo.messaging for just notications and not using amqp/rabbit, you can ping us on #openstack-oslo
21:41:22 <torgomatic_> notmyname: definitely. but just using a notifier on new PUTs misses a couple things
21:41:27 <notmyname> right
21:41:32 <torgomatic_> (a) if the other end is down, you miss objects
21:41:55 <torgomatic_> (b) you don't get notifications for existing objects (like if you add indexing to a cluster with data already in it)
21:42:01 <sjmc7> a) is why using oslo is desirable
21:42:01 <torgomatic_> hence the watcher thingy
21:42:16 <notmyname> so the original question is "are we ok with using oslo.messaging or not"
21:42:19 <briancline> dims: excellent. i'll pop in soon
21:42:58 <hurricanerix> personally oslo anything makes me nervous =)
21:43:17 <dims> hurricanerix you should get to know us :) we don't bite
21:43:32 <sjmc7> we’re ok with this living out of tree, if that’s preferable
21:43:44 <briancline> to be fair, using swift with keystone pulls in a lot of oslo deps anyway
21:44:26 <notmyname> sjmc7: it's a little hard for me to say at this point just because I'm not familiar with oslo.messaging
21:44:42 <sjmc7> ok. well, perhaps we’ll do something out of tree for now, and revisit this in the future
21:45:24 <notmyname> in general, I'm supportive of having basic hooks/functionality for people to build metadata searching for the stuff in swift
21:45:44 <sjmc7> i think the middleware would be very simple, so in that sense the hooks exist
21:46:00 <notmyname> do you have an example we could look at?
21:46:09 <sjmc7> for middleware?
21:46:13 <hurricanerix> notmyname i'm not that familiar with how all the dependency stuff works.  does having the middleware included mean that the middleware's deps get pulled in, even if you don't use it?  or is there a way to have deps on a per middleware basis?
21:46:58 <hurricanerix> it would be nice if it were done on a per middleware basis, so if all you had was the most basic Swift install, you wouldn
21:47:03 <notmyname> hurricanerix: dependencies are set for the whole project. there isn't currently a way to do dependencies for just one piece of middleware or optional stuff
21:47:06 <hurricanerix> 't need to install a bunch of extra stuff.
21:47:08 <notmyname> sjmc7: yeah
21:47:22 <hurricanerix> notmyname: yeah, that what I thought
21:47:26 <notmyname> hurricanerix: right. so eg with keystone today, we have keystone middleware, but we don't have keystone in our requiremnts
21:47:28 <sjmc7> every project emits notifications through different mechanisms
21:47:41 <briancline> i'd imagine it could work the same way that the optional keystoneauth middleware works now -- swift has that in-tree, but doesn't have hard dependencies on the keystonemiddleware package
21:47:46 <briancline> what john said
21:47:52 <sjmc7> but all through oslo.messaging, so i don’t have an example that’d be useful, but looking at existing swift MW it looks like it’d be quite simple
21:47:59 <clayg> and depending on the dependency I think there's a good point to be made that it doesn't need to be in the upstream tree
21:48:08 <clayg> minimize dependencies is a thing
21:48:10 <notmyname> clayg: right
21:48:16 <clayg> and middleware packaged outside of swift is a thing too
21:48:22 <sjmc7> ok, we can live with that. thanks for the discussion
21:48:50 <notmyname> sjmc7: thanks for bringing it up. I've very interested, personally, in searchlight, so please let us know what's going on there
21:48:56 <clayg> if it was so *needed* and trivial to do right in middleware there'd already be dozens of these things implemented outside of swift and we could just pick the one we like the best to bring onto stackfordge or w/e
21:49:08 <notmyname> gotta move on. 2 more things to bring up
21:49:19 <notmyname> #topic -infra is dropping py26 testing
21:49:23 <joeljwright> :(
21:49:30 <notmyname> I just discovered this today on the ML in another thread
21:50:00 <lifeless> its only been EOL for 2 years ;)
21:50:15 <joeljwright> yeah, but centos 6 users are very stubborn
21:50:23 <notmyname> Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6
21:50:23 <notmyname> compatability"
21:50:24 <notmyname> topic is "
21:50:39 * dims waves again :)
21:50:41 <notmyname> so yeah, we still support py26 in swiftclient
21:51:00 <notmyname> that will get harder to do if we arent' running py26 tests
21:51:10 <notmyname> oh, the -infra date in nov 19. so really soon
21:51:40 <clayg> dropping py26 from the gate is the same as not supporting py26 in practice
21:51:43 <notmyname> so that raises the question of continuing py26 support and if so how to test it
21:51:51 <notmyname> clayg: right
21:51:55 <clayg> no one will bother to checkout changes and tox -e py26 them
21:51:59 <notmyname> we could do some 3rd party CI
21:52:07 <clayg> notmyname: oh - that'd be fine
21:52:11 <notmyname> but 3rd party CI doesnt' vote
21:52:29 <clayg> notmyname: we could probably socialize it and work around bugs pretty quick if it slipped?
21:52:40 <notmyname> unfortunately, I have zero idea how much py26 swiftclient is used
21:52:43 <clayg> notmyname: anywa - i've been pretty happy with no py2.6 in swift
21:52:57 <clayg> notmyname: some folks have said that "well it matters more in the client" - but... no it doesn't
21:53:00 <joeljwright> yeah, but no pu26 in swift is very different to no py26 for clients
21:53:05 <notmyname> heh
21:53:07 <clayg> heh
21:53:12 <clayg> joeljwright: HOW SO!?  ;)
21:53:25 <joeljwright> there are loads of people using rhel6/centos6/scientific6
21:53:28 <clayg> joeljwright: do you have some client machines that don't have a good way to get py2.6
21:53:29 <joeljwright> all on my26
21:53:33 <joeljwright> py26
21:53:52 <clayg> rhel5 is probably py2.6 - but rhel6 - really?
21:53:57 <tdasilva> yep
21:54:00 <joeljwright> I don't know about 'good'
21:54:15 <joeljwright> the issue is all these systems are supported for years more
21:54:18 <tdasilva> we are also still shipping RHGS in rhel6.5
21:54:30 <tdasilva> yep
21:54:32 <notmyname> tdasilva: RHGS?
21:54:36 <clayg> and this is why we can't have nice things
21:54:38 <tdasilva> Red Hat Gluster Storage
21:54:45 <notmyname> ah
21:54:51 <tdasilva> which ships with swift packages
21:54:59 <clayg> Python 2.7 was released on July 3rd, 2010
21:55:20 <notmyname> clayg: RHEL6 is supported until something like 2035
21:55:25 <clayg> i say that like it was a long time ago but I don't really remember what year it is - 2016?  do i have to vote next month?
21:55:33 <joeljwright> clayg: python 3.0 was released in 2008, but it's still not default...
21:55:33 <timburke> notmyname: 2020 -- https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
21:55:57 <notmyname> so the reality is that someone that needs py26 needs to think very hard about some 3rd party py26 tests
21:56:27 <notmyname> clayg: "you didn't blow away your entire deployment and install everything fresh from the very latest version?! wow."
21:56:50 <clayg> why is rhel6 py2.6
21:57:14 <notmyname> this week, especially joeljwright and tdasilva, please let's think on what we can do there. and raise it again next week
21:57:18 <joeljwright> clayg: I honestly don't know :(
21:57:20 <notmyname> (look at the time)
21:57:25 <joeljwright> kk
21:57:27 <tdasilva> k
21:57:27 <notmyname> last thing, briefly
21:57:39 <notmyname> #topic functional tests with testrepository
21:57:49 <notmyname> patch 214206
21:57:50 <patchbot> notmyname: https://review.openstack.org/#/c/214206/ - Modify functional tests to use testr
21:57:50 <clayg> well I don't think we can support py2.6 for another *5* years?
21:58:12 <notmyname> moves just functional tests to use testr. this is important for defcore, but it might also get us other cool stuff too
21:58:18 <clayg> I already package py2.7 for rhel - so does epel and ius I'm sure
21:58:19 <joeljwright> clayg: honestly, I'm not sure I want us to try :(
21:58:38 <notmyname> please look over the patch and understand the small changes you'll see when you run functional tests
21:58:44 <clayg> notmyname: skeptical of the other cool stuff
21:58:45 <torgomatic_> if it might get us other cool stuff, I might +2 it ;)
21:59:06 <notmyname> clayg: recheck just failing tests, run a test until failure (eg for timing bugs), run tests concurrently
21:59:09 <clayg> yawn - if it passes the gate and still runs my tests I'll adust - w/e
21:59:17 <notmyname> heh, ok
21:59:21 <hurricanerix> clayg: I think the "cool stuff" is not having test duplication between Swift repo and Tempest. =)
21:59:36 <briancline> +1
21:59:40 <clayg> notmyname: idk, fancy stuff like that scares me - back in my day we used to run our tests by rubbing two asserts together with a stick
21:59:42 <notmyname> hurricanerix: you'll be shocked to learn clayg doesn't really care about tempest ;-)
21:59:58 <acoles> clayg: lol
22:00:01 <clayg> hurricanerix: sorry not sorry
22:00:01 <hurricanerix> notmyname: lol
22:00:08 <notmyname> clayg: sorry, not trying to put words in your mouth
22:00:13 <notmyname> unfortunately, we're out of time
22:00:21 <notmyname> thanks for helping move everything along quickly this week
22:00:36 <hurricanerix> clayg: well I don't either, I see this as allowing me to continue to not care about it :)
22:00:49 <clayg> hurricanerix: nice!
22:00:54 <notmyname> looks like we have follow-ups about py26, maybe oslo.messaging at a later time
22:01:07 <notmyname> thanks for working on swift!
22:01:09 <notmyname> #endmeeting