21:00:08 <notmyname> #startmeeting swift
21:00:09 <openstack> Meeting started Wed Aug 10 21:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:13 <notmyname> hello, everyone.
21:00:13 <openstack> The meeting name has been set to 'swift'
21:00:19 <notmyname> who's here for the swift team meeting?
21:00:28 <nadeem> o/
21:00:31 <bkeller`> o/
21:00:33 <sgundur1> hi
21:00:38 <kei_yama> o/
21:00:39 <mmotiani> hi
21:00:39 <torgomatic> .
21:00:59 <cutforth> o/
21:01:03 <ntata> o/
21:01:21 <notmyname> I think tburke and clayg are in a meeting (but they've heard enough of me ranting this week ;-)
21:01:42 <notmyname> kota is on vacation
21:01:49 <notmyname> mattoliverau is sick
21:01:53 <jrichli> o/
21:02:05 <jrichli> mattoliverau: :-(
21:02:15 <acoles> here
21:02:36 <notmyname> sgundur1: ntata: mmotiani: is paul around?
21:02:55 <notmyname> pdardeau: there you are :-)
21:02:59 <pdardeau> o/
21:03:29 <notmyname> ok. let's get started
21:03:34 <notmyname> welcome, everyone
21:04:03 <notmyname> while I do want to get to repconn stuff with nadeem at the end, there's really just one big topic on everyone's mind
21:04:25 <notmyname> so let's talk about last week's tc meeting and decision
21:04:49 <tdasilva> hello, sorry i'm late
21:04:57 * nadeem all ears
21:04:57 <notmyname> tdasilva: just getting started
21:05:15 <notmyname> yeah...I typed out notes, but still trying to figure out how to kick it off :-)
21:05:44 <tdasilva> ccccccdkkgthrlbidfffiurjtdchnrirvintejgigdbn
21:05:47 <notmyname> ok, so summary: last week the TC decided that golang should not be allowed as a way to implement openstack services, in whole or in part
21:06:15 <tdasilva> sorry
21:06:23 <notmyname> #link http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html
21:06:34 <notmyname> those are the meeting logs from the TC meeting.
21:06:37 <notmyname> don't go read them now
21:06:45 <notmyname> just putting them here for reference
21:07:16 <notmyname> so I want to summarize what's going on and how we figure out what's next
21:07:21 <notmyname> but first...
21:07:38 <notmyname> I know the decision has hit several of us quite hard
21:07:59 <nadeem> true
21:08:00 <notmyname> and I want to thank you for not going off on twitter or in irc or on the ML and flaming the TC about the decision
21:08:53 <notmyname> also, please don't rage quit (yet). it will take a while to figure out what's going on and what the path forward it, so let's work together on that
21:09:31 <nadeem> is the TC's decision final & binding?
21:09:35 <notmyname> I've talked to several of you on the phone. several others I haven't been able to talk with yet. (and of course people in the office with me have heard me say a lot ;-)
21:10:20 <notmyname> nadeem: it's a good question. let's cover what was said, why, and the options we have
21:10:43 <notmyname> for what was said, the decision is rather clear: no golang in openstack
21:11:02 <notmyname> or actually, no not-python for openstack services
21:11:27 <notmyname> there are several reasons why tc members voted the way they did
21:11:40 <notmyname> I've talked to several of them on the phone (or video chat) this week
21:12:20 <notmyname> one reason, not shared by everyone, but that does have several people behind it is this...
21:13:27 <notmyname> put simply, there is a strong perception that swift has been granted exceptions to do things differently in the past, the swift team is not concerned about cross-project efforts (especially in relation to swift's internal priorities), and swift should not be given another way to be different in openstack
21:14:05 <notmyname> there is fear that the swift team will not respect the cross-project effort needed to find a way to effectively use golang across all of openstack
21:14:33 <notmyname> basically, there's a big trust issue
21:15:10 <notmyname> the second biggest reason given by TC members comes down to technical justification of if golang is actually needed to solve the problems we have
21:15:56 <notmyname> I'm leaving these things here without comment, and I don't really think it's good if we try to discuss or debate this in IRC in this meeting
21:16:13 <notmyname> but I'm definitely available if you want to talk about this
21:16:39 <clayg> hi!
21:16:47 <notmyname> ok, so where does that leave us, as swift? how do we move forward?
21:17:08 <notmyname> we basically have 3 options moving forward. none are great, but two of them are pretty terrible
21:17:17 <notmyname> 1) swift drops golang work
21:17:22 <notmyname> 2) swift drops openstack
21:17:43 <torgomatic> I think the TC members should each have to write a paragraph explaining the problem with concurrent disk IO in Python before being allowed to decide if golang is needed for the solution
21:17:49 <notmyname> 3) swift's proposed golang parts are moved into a different non-openstack repo to be developed/managed separately
21:18:07 <torgomatic> how can they decide what's necessary for a solution if they don't understand the problem?
21:19:14 <clayg> phew, this is not fun
21:19:16 <notmyname> so option 1 (dropping golang) means that we reject a proven technically superior solution that solves problems for users and customers
21:19:22 <clayg> fuck that
21:19:23 <clayg> sorry
21:19:29 <notmyname> I don't htink that's a good idea at all
21:20:14 <notmyname> option 2 (drop openstack) is something that would absolutely devastate our community (ie many current, prolific contributors could no longer work on swift)
21:20:36 <notmyname> this, too, is a terrible possibility
21:20:56 <notmyname> so options 1 and 2 are off the table for now
21:21:00 <clayg> it also sorta gives in to "we're the problem"
21:21:14 <notmyname> which leaves us with option 3 (split the repo and figure it out)
21:21:36 <notmyname> this has high costs, both technically and socially amongst our contributors
21:21:47 <notmyname> and I'm really worried about that
21:22:01 <clayg> notmyname: not to breed false hope, but isn't there an option #4 that at some point there is a change of opinion in the TC and OpenStack does find a way to build services that make up clouds in languages not-python?
21:22:39 <notmyname> yes, there is the magic option 4. and while I certainly hope for that, we need to prepare as if it's not there
21:23:06 <notmyname> so figuring out what this looks like is what we need to all discuss
21:23:11 <nadeem> <tdasilva> does "external" development mean completely outside of the openstack namespace? <ttx> tdasilva: no, just outside of TC's reach
21:23:13 <notmyname> and likely IRC is not the best place to do it
21:23:20 <nadeem> what does ttx means here?
21:23:38 <notmyname> nadeem: like swift3. in the openstack/* namespace but not an official project
21:23:43 <notmyname> or pyeclib
21:23:49 <nadeem> oh ok
21:24:13 <clayg> FWIW I think this probably not a terrible compromise - no one is happy
21:24:36 <notmyname> so there are 2 more points I want to cover: current, short-term plan and what about the cross-project work
21:24:54 <notmyname> first, here's what I propose we do for now: nothing
21:25:11 <notmyname> that is, there is no need to split a repo or do anything else even more drastic yet
21:25:19 <clayg> but I would still like official TC support for we're not doing something to be different - we're doing exactly what you're supposed to do in OpenStack - you wanna do something not python - break up your project and contribute into "projecs" only one of which is under the rule of the TC
21:25:34 <clayg> or however they would phrase it
21:25:47 <notmyname> we don't even have the repconn or obj server code ready to replace the python versions yet, so there's no need to split it out
21:26:14 <notmyname> clayg: right. that question would be great to get an explicit "yes this is what to do" from the TC. one of the reasons I want to wait before doing anything
21:26:15 <clayg> +1 keep working on the mergable feature branch
21:26:53 <notmyname> so we should do what we said in austin and san antonio: start with repconn in a golang object-replicator and get the "mergable" version in feature/repconn
21:26:53 <acoles> clayg: do you mean you'd like the TC to actively approve swift breaking out into separate projects?
21:27:09 <clayg> acoles: yeah if that's what they want say so
21:27:35 <acoles> clayg: interesting, avoids any future misunderstanding of our motivations
21:27:52 <clayg> I mean if that's the compromise - like we're not happy; you're not happy; but this seems like a reasonable compromise to set as the pattern going forward
21:28:58 <notmyname> one issue I see with splitting the repo is that, essentially, we reduce the scope of "openstack object storage" to no longer include the part that writes anything to disk. getting explicit TC "yes, that's what we mean" for that would help my own "wait, what?!" sort of reaction to that suggestion
21:29:46 <rbergeron> fda
21:30:17 <nadeem> notmyname what can we do reduce the trust deficit between TC & us?
21:30:19 <torgomatic> we could move everything but swift-init to a separate repo, then get on with the business of actually fixing real problems
21:30:22 <notmyname> so beyond the technical side (splitting the repo, scope, etc), that gets us into the social issue
21:30:28 <notmyname> nadeem: yeah, that :-)
21:30:30 <torgomatic> (/s, but only mostly)
21:30:33 <clayg> bah, if you follow it through ad absurdum it doesn't make sense, try not look at the broader picture
21:31:05 <notmyname> this will definitely be a topic that I schedule for the summit. maybe more than one
21:32:10 <notmyname> but the basic trust deficit comes down to a few things. first, swift isn't using some of the libraries that other projects are. and second, swift hasn't been the group to change those or other common tools/processes to make them better for everyone including swift
21:32:12 <pdardeau> did the question of trust and technical necessity ever come up during first proposal?
21:33:00 <notmyname> pdardeau: TBH we all kinda got it wrong on the first proposal. we thought the TC was looking for a process to work through, but the decision was that the TC doesn't really agree that golang should be a thing or that swift should be the ones to propose it
21:33:29 <clayg> notmyname: ttx was looking for a process - and he was just in a minority - that includes like jbryce
21:33:37 <notmyname> clayg: true
21:34:00 <clayg> I think it was great that he brought it to a head - he was like "wait, do we even agree on the *gaol* here!?"
21:34:15 <clayg> I think a lot of people were surprised, and more thought it wasn't settled
21:34:55 <notmyname> looking forward, to help rebuild trust with the TC (rebuild? build in the first place?) we will need to revisit our usage of oslo libraries (config and logging specifically) and some other common things like requirements and release notes
21:35:02 <clayg> but.... community - YEAH!  Let's help!  WHOOOO
21:35:40 <acoles> it's weird to think that if another project had proposed golang then the decision might have swung the other way
21:35:50 <clayg> you barely see the scars of pbr these days - i'm all up on setuptools v3405877777 everything is awesome!
21:36:05 <pdardeau> if the reasons to keep them out in the past were valid, wouldn't they still be valid (except maybe for the higher social cost)?
21:36:38 <notmyname> pdardeau: to keep what out of what? oslo libs out of swift? golang out of openstack?
21:36:58 <pdardeau> notmyname: sorry, oslo logging and config out of swift
21:37:04 <clayg> pdardeau: like sometimes we didn't use things because it was the path of least resistence and we had different priorities
21:37:05 <tdasilva> i think we also need to be careful to not jump into a us vs them, we are right and they are wrong mentality. If the TC said there are trust issues, we should at least try to understand better what is meant by it
21:37:08 <clayg> like oslo.confg
21:37:11 <clayg> we *can't* use it
21:37:14 <clayg> without changing it
21:37:15 <notmyname> tdasilva: yes
21:37:17 <clayg> so we don't use it
21:37:20 <acoles> tdasilva: agree
21:37:23 <clayg> instead of changing it, and using it
21:37:35 <clayg> but like the only reason we do that is priorities
21:37:50 <clayg> and it's our prioritization that's biting us more than anything i think
21:38:03 <pdardeau> clayg: thx for clarification
21:38:10 <notmyname> so it's about chaning our own priorities to update eg oslo.config and then integrating that before doing more swift-specific things
21:38:15 <clayg> how can we not prioritize using oslo.config?  *everyone* uses it.  Parts are even like *technically* use*FUL*
21:38:22 <clayg> so pony up, do the work
21:38:33 <clayg> that's my opinion anyway - everything is awesome!
21:38:45 <clayg> no do all the things!
21:38:50 <clayg> sleep is overrated!
21:39:42 <notmyname> so right. it comes down to prioritiaztion, and what several TC members really want to see is that the swift team work on things that benefit cross-project efforts
21:40:02 <timburke> in our defense, some of us *have* tried to fix things for the larger community, but all of openstack has the same slow-review-times issue we have. see https://review.openstack.org/#/c/240090/, https://review.openstack.org/#/c/233245/, https://review.openstack.org/#/c/276517/ for some examples
21:40:09 <acoles> notmyname: are there specific work items they have in mind?
21:40:52 <clayg> timburke: nice - i was hoping those were all yours :D
21:40:55 <notmyname> acoles: I'll avoid yet again linking in the logged meeting channel the doc that details the swift team's failing and my personal responsibility there ;-)
21:41:21 <timburke> clayg: oh, there are more... ;-)
21:42:05 <notmyname> but yeah, it's requirements, reno, logging, config, oslo.messaging, cross-project liasons (or lack thereof)
21:42:27 <notmyname> that's the starting list
21:42:37 <tdasilva> acoles, notmyname: i don't think it is so much about work items as just being "part of the community" which means yes, doing cross-project work, but also participating in the conversation
21:42:37 <notmyname> some are goign to be easier to address than others
21:42:46 <notmyname> tdasilva: right, exactly
21:42:59 <pdardeau> is py3 one of them also?
21:43:17 <timburke> if it isn't yet, it probably will be in the next six months
21:43:21 <notmyname> pdardeau: that will come up once the new TC-set cross-project goals gets landed
21:43:35 <notmyname> for example, for requirements, we're dinged on not landing the bot patch proposals
21:43:50 <clayg> pdardeau: it probably doesn't help us that we prioritize other things over python
21:44:11 <notmyname> but it's not that we dont' land them, it's that the swift team has ignored the problem and not contributed to the openstack-requirements repo to improve the version matching
21:44:16 <clayg> notmyname: let's land 'em!!! I'll package everything!!!  srly, nothing else to do this week.  LOVE me some packaging
21:44:20 <notmyname> that's a specific example
21:45:13 <notmyname> in summary, there are some significant social and technical issues to work through in the coming months
21:45:21 <notmyname> what other questions do you have?
21:45:26 <nadeem> notmyname : do we have a list of TC cross-project goal documented somewhere to look at?
21:45:39 <nadeem> *goals
21:45:48 <tdasilva> the ML?????
21:45:53 <notmyname> https://review.openstack.org/#/c/349068/ and http://lists.openstack.org/pipermail/openstack-dev/2016-July/100472.html
21:46:01 <nadeem> cool
21:46:12 <clayg> tdasilva: heh, yeah it's sort of BD right now
21:46:28 <timburke> i'm still very much interested in finding out how well it works for people to contribute to repos under https://github.com/openstack/* that aren't officially OpenStack projects
21:46:29 <clayg> tdasilva: but that's very swift of us right?  "oh the ML, yeah I mostly ignore that; too painful"
21:46:32 <timburke> does that work well for everyone's employers? like, would their legal depts. be ok with it? can you contribute today to pyeclib and swift3, and if so did it require some separate approval process?
21:46:37 <timburke> answers might be better as PMs to notmyname, but it's something people should think about
21:46:52 <tdasilva> clayg: yep :(
21:47:01 <notmyname> yes, please think about it, and please tell me any issues you may have
21:47:11 <notmyname> I have already heard from one person for whom it might be an issue
21:47:28 <notmyname> and we must understand the cost here
21:47:57 <notmyname> timburke: I'll check with your employer for you ;-)
21:48:08 <timburke> yay! less work for me!
21:48:50 <notmyname> any other questions about all this?
21:49:13 <notmyname> I'm sorry that there aren't any good answers right now. if you're feeling a little confused, you're in good company with everyone else
21:50:05 <nadeem> what is our action plan going forward?
21:50:31 <notmyname> nadeem: keep doing feature/repconn, don't do anything drastic until we actually have to (eg when we have to release)
21:50:43 <nadeem> okay
21:51:37 <notmyname> nadeem: what's going on with feature/repconn right now?
21:51:57 <notmyname> you've been moving code from the obj server to the object replicator, right?
21:52:12 <nadeem> true. That is in progress.
21:52:31 <notmyname> (also, note that the "what's next" also includes all the other "normal" stuff going on in swift that still needs to be done)
21:52:50 <notmyname> nadeem: how is it going? when can we see patches? how can we help?
21:53:37 <nadeem> It is going well. Hopefully I could have a patch ready by next week
21:54:08 <notmyname> good. looking forward to it :-)
21:54:50 <notmyname> in a couple of weeks I'll be going to NYC to the operators meetup and to the openstack east event. I hope to be able to talk face-to-face with several tc people there
21:56:06 <clayg> notmyname: good luck, don't get kicked out
21:56:12 <nadeem> :D
21:56:12 <acoles> notmyname: if we are going to make progress on cross-project stuff then some of the "normal" stuff has to slip, or we hire more elves ;)
21:56:23 <notmyname> acoles: yep :-(
21:57:15 <clayg> i really don't have a good quip here :'(
21:57:25 <acoles> notmyname: it would be good to coordinate efforts there i.e. if anyone is able to start on one of those pieces, then communicate to rest of us so we don't suplicate effort
21:58:05 <notmyname> good idea. and tracking these in a more formal way and having them as meeting agenda items probably also would really help
21:58:06 <acoles> clayg: "Wanted: Elves"? :P
21:58:16 <nadeem> notmyname agree
21:58:36 <acoles> notmyname: wishlist bugs maybe?
21:58:53 <tdasilva> acoles: you mind find them in the wood of Yosemite ;)
21:59:00 <notmyname> acoles: not joking, I'll look into whatever is the cross-project OpenStack Way (tm) to do it
21:59:05 <clayg> acoles: I was hoping something more like "no we can totally do everything this won't be a distraction at all!"
21:59:34 <notmyname> we're at full time
21:59:40 <acoles> clayg: that is of course a given ! its just typey-typey except matt is sick :/
21:59:44 <clayg> tdasilva: OMG - i spent some time in the park week before last - it was *amazing* - North America is beautiful
21:59:52 <acoles> tdasilva: I'll take a net :)
22:00:03 <onovy> pls pls, anyone, after almost 1 year open review? https://review.openstack.org/#/c/238799/
22:00:06 <notmyname> thank you for your work on swift. you've written something that is used in production every day around the world at massive scale. thank you for your work
22:00:10 <notmyname> #endmeeting