21:00:11 <notmyname> #startmeeting swift
21:00:12 <openstack> Meeting started Wed Aug 31 21:00:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:13 <patchbot> You've given me 5 invalid commands within the last 60 seconds; I'm now ignoring you for 10 minutes.
21:00:15 <openstack> The meeting name has been set to 'swift'
21:00:22 <notmyname> who's here for the swift team meeting?
21:00:27 <bkeller`> o/
21:00:31 <pdardeau> o/
21:00:32 <mathiasb> o/
21:00:33 <jrichli> hi
21:00:33 <cutforth> hola
21:00:36 <nadeem> hi
21:00:36 <cschwede> o/
21:00:36 <kota_> hello
21:00:36 <tdasilva> eu
21:00:38 <hosanai> o/
21:00:42 <torgomatic> .
21:00:46 <dmorita> hi
21:00:46 <m_kazuhiro> o/
21:01:07 <mattoliverau> o/
21:01:11 <kmARC> o/
21:01:38 <notmyname> welcome everyone
21:01:53 <notmyname> several things to go over this week. agenda is at..
21:01:54 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:09 <notmyname> first up...
21:02:16 <notmyname> #topic new swift core
21:02:26 <notmyname> I'm happy to announce that jrichli is now on swift core
21:02:39 <cschwede> Hoorayy! Welcome Janie :D
21:02:39 <mattoliverau> \o/
21:02:40 <nadeem> congrats jrichli!
21:02:40 <notmyname> jrichli: congrats (and my apologies)
21:02:46 * bkeller` applause
21:02:47 <pdardeau> jrichli: congrats!!
21:02:47 <jrichli> lol
21:02:54 <dmorita> Congrats jrichli
21:02:57 <jrichli> thanks!
21:02:57 <mathiasb> congratulations janie!
21:02:58 <kota_> congratulations!
21:03:02 <hosanai> jrichli: congrats!
21:03:08 <m_kazuhiro> congratulations!
21:03:49 <notmyname> jrichli's been doing great work, and I'm looking forward to working with her as a core reviewer
21:04:13 <notmyname> #topic barcelona schedule
21:04:30 <notmyname> brief update on the schedule for barca
21:04:45 <notmyname> like in tokyo, this summint is slightly compressed. it's tuesday through friday
21:04:58 <notmyname> on the design summit side, here's the overview
21:05:07 <notmyname> tuesday is ops stuff and some cross project stuff
21:05:22 <notmyname> wednesday is cross project stuff and some individual team sessions
21:05:31 <notmyname> thursday is individual team sessions
21:05:53 <notmyname> friday morning is individual team sessions, and friday afternoon is for the contributor meetup
21:06:08 <notmyname> so that's a half-day on friday instead of the full day that's been available in the past
21:07:00 <mattoliverau> k, yeah a little more compressed then
21:07:17 <notmyname> I've submitted the schedule request to ttx. I asked for 2 fishbowl (like we had in austin) and 13 working sessions. I made a note that having fishbowl on wed pm and working sessions thursday and friday (plus the friday pm meetup) would be best for us
21:07:44 <notmyname> basically, this means plenty of ops and cross-project time and still a couple of days for swift-specific stuff
21:07:56 <notmyname> also, don't fly home on friday evening. wait until saturday ;-)
21:08:18 <notmyname> make sense to everyone? any questions about that?
21:08:31 <cschwede> i think most people will leave Friday evening…
21:08:52 <notmyname> cschwede: the cool kids will stay through saturday. you want to be a cool kid, right? ;-)
21:09:15 <joeljwright> dammit, I'm flying home on Friday
21:09:17 <joeljwright> :(
21:09:19 <cschwede> notmyname: i am the cool kid that is at a concert on Friday evening in Hamburg!
21:09:23 <notmyname> lol
21:09:27 <hosanai> lol
21:09:34 <notmyname> that's much cooler than being in a hotel conference room
21:09:42 <notmyname> seriously, though, people leaving on friday is totally normal and expected.
21:10:00 <cschwede> we need to work faster on teleporting.
21:10:08 <notmyname> but if you currently *don't* have concert tickets for friday night, then stay for swift stuff
21:10:15 <kota_> cschwede: true
21:10:51 <notmyname> as we get closer to the summit, we'll start an etherpad to gather topics, like we've done in the past
21:10:56 <notmyname> no need to start that yet, though
21:11:28 <notmyname> ok, if no questions, then let's move on
21:11:45 <notmyname> #topic swiftclient release
21:11:56 <notmyname> we need a release for swiftclient for 2 reasons
21:12:07 <notmyname> 1, there's good stuff we should make available to users
21:12:21 <notmyname> 2, getting close to the openstack library deadlines to be included in the overall release
21:12:38 <notmyname> there's one last patch that might land for it
21:12:45 <notmyname> patch 184956
21:12:46 <patchbot> https://review.openstack.org/#/c/184956/ - python-swiftclient - Accept gzip-encoded API responses
21:13:14 <notmyname> and mattoliverau's going to look at that right after the meeting (he already have a +2 previously before a rebase)
21:13:27 <mattoliverau> yup will look at that this morning.
21:13:39 <notmyname> is there anything else that anyone knows of that really must be in this release?
21:13:57 <notmyname> (docs are great, but can be landed after since we build docs at every commit now)
21:14:08 <timburke> nah, the other interesting stuff are probably better left for next cycle
21:14:19 <notmyname> timburke: s/cycle/release/
21:14:25 <joeljwright> notmyname: I think we managed to land everything that was ready
21:14:30 <notmyname> ok
21:14:45 <notmyname> so that gets us to a segue topic..
21:14:56 <notmyname> I've got https://review.openstack.org/#/c/361775/ up for the normal authors/changelog updates
21:14:56 <patchbot> patch 361775 - python-swiftclient - authors/changelog updates for 3.1.0 release
21:15:09 <notmyname> but there's one other thing there: reno release notes
21:15:44 <notmyname> to summarize reno, it's a way to commit yaml files into your repo so that you get a release notes link on an openstack release web page
21:16:03 <notmyname> see https://releases.openstack.org for examples of other projects' notes https://releases.openstack.org
21:16:16 <notmyname> well, click through some stuff
21:16:35 <notmyname> but there's a little more to it than that
21:16:42 <torgomatic> whatever happened to plain text? release notes are for humans, so why embed that stuff in some markup?
21:16:55 <notmyname> torgomatic: yeah...about that
21:16:57 <cschwede> i like reno
21:17:21 <notmyname> us not having the reno yaml files in our repo is one of the things that some people on the TC complained about us not using
21:17:32 <cschwede> torgomatic: releasenotes are now able to contain semantic for stuff like „security“, „fixes“, „minor stuff“ etc
21:17:48 <notmyname> so far, it seems relatively simple (apart for yaml having 63 different ways to format a multi-line string)
21:18:12 <notmyname> and so that patch above simply takes the human-readable thing I normally write and reformats it into yaml
21:18:44 <notmyname> cschwede: yeah, and that's kinda nice.
21:19:01 * torgomatic can't wait for the first security hole to be found in our release-notes builder
21:19:02 <cschwede> notmyname: the nice thing is that each patch can contain a reno note snippet, making it (hopefully) easier to sumup the final release note
21:19:27 <cschwede> notmyname: so that should help you at the end - at least in theory ;)
21:19:46 <notmyname> cschwede: so I disagree with that. I'm the person that actually goes through the patches to build release notes, and I'll still have to do that
21:19:59 <notmyname> there's often patches that need to be grouped into a single release note
21:20:11 <notmyname> and I'll still have to look at patches that don't have notes on them
21:20:30 <notmyname> but I get the theory
21:21:08 <cschwede> notmyname: yes, but it can be really helpful if people contribute to the reno notes. but it will take some time to adopt (and reviewers might need to ask for a note)
21:21:13 <notmyname> for now, what I'm thinking is that at a release time I'll still go build release notes by hand (I enjoy this--it's not a chore) and then make the `reno report` match it
21:21:37 <notmyname> cschwede: so yeah, if people want to add a release note, that's fine. and if they don't, personally I'm ok with that too
21:22:24 <tdasilva> i'm not sure that works out well...we should either have for every patch or not...
21:23:06 <notmyname> I feel similarly to torgomatic on this. I want hand-curated notes because it's supposed to be read by humans. and I suspect that one person doing it at the end of a release will have better results than trying to make every patch also add a yaml file to our repo
21:23:20 <tdasilva> i'm ok if notmyname wants to just build one note at the end, just the idea that some patches would have notes and others would not that doesn't seem like a good idea
21:23:26 <notmyname> tdasilva: why does it need to be black-and-white?
21:24:00 <notmyname> tdasilva: what if I simply delete the other yaml files and roll their contents into the one release notes note (like this swiftclient patch has)
21:24:23 <notmyname> tdasilva: then the notes in a file hint and what to include, and the final results end up being not a jumbled mess
21:25:08 <tdasilva> notmyname: i'm just afraid it will lead to confusion when some patches have reno notes and others dont
21:25:17 <bkeller`> somehow i doubt "we can let people use reno if they want but we'll still ignore it" is what the tc wants us to do
21:25:33 <notmyname> bkeller`: no, I'm not proposing ignoring anything
21:25:44 <notmyname> clayg asked me an interesting question about this yesterday: would I even have considered using this if not for the TC criticism about it?
21:25:58 <cschwede> imo only patches that add a new feature, fix a bug etc need a reno note - ie something that should be mentioned in the final release note
21:25:58 <notmyname> and yes, I would, because of its integration with the automated release tooling
21:26:11 <tdasilva> bkeller`: i think the TC will get what they want which is the release notes being automatically created at release time
21:26:45 <notmyname> cschwede: I guess I think (somewhat based on experience) that it's hard to always know at the time of a patch how its notes come release time relate to other patches that landed
21:27:17 <dhellmann> having one person write all of the notes at the end of the cycle misses the point of building a culture around having all contributors think about how their changes impact users
21:27:41 <cschwede> notmyname: sure; but if i fix a typo that doesn’t need a reno; if i fix an important bug it could have a reno and lower the work for you at the end
21:28:11 <notmyname> bkeller`: but I think I get what you're trying to say. I don't want to use reno just to give some sort of lip-service. integrated with the automatic tooling is good--we should do as much of that as we can
21:28:50 <bkeller`> yeah
21:28:51 <notmyname> cschwede: perhaps. well, it does to some extent
21:29:04 <notmyname> cschwede: but it doesn't eliminate it. that's my point
21:29:29 <notmyname> I've still gotta review those and all the other patches too
21:29:43 <tdasilva> cschwede, notmyname : sorry, just read my previous message and I meant "every patch" that makes sense to have a note, i agree not every single patch needs a note
21:30:15 <cschwede> notmyname: sure, there is still some work to do
21:30:25 <jrichli> it might be interesting to have the point of view of a deployer.  do they appreciate the more cohesive summaries, and how would they feel about seeing a lot more verbage
21:30:59 <notmyname> jrichli: what do you mean? which one has "a lot more verbage"?
21:31:22 <jrichli> more verbage may result from having individuals all contribute over time
21:31:23 <patchbot> Error: I haven't seen verbage.
21:31:39 <jrichli> thanks, patchbot
21:31:40 <tdasilva> lol
21:31:43 <notmyname> bah! patchbot is sick
21:32:24 <cschwede> haha ^^
21:32:36 <jrichli> having notes from several commits : not having a way to group some together
21:32:42 <notmyname> jrichli: perhaps. but the balance is highlighting the important stuff so that its not lost in lots of less important stuff
21:32:58 <notmyname> jrichli: oh, I get it. that's actually what you're saying
21:33:00 <jrichli> yes, that is what i am thinking too
21:33:03 <jrichli> :-)
21:33:06 * clayg sneaks in the back
21:33:46 <notmyname> cschwede: I feel like you might not agree (or at least have a different perspective)
21:34:56 <cschwede> notmyname: well, it helped us in the last project, and the results were good - less work for the one who cutted a release
21:35:00 <bkeller`> we could use the groups like cschwede was saying
21:35:12 <bkeller`> unless i'm misunderstanding
21:35:32 <cschwede> but we only added reno notes when there was something worth to mention; for example the last patch in a chain of patches for feature XYZ
21:35:40 <notmyname> sure. like I said, if someone wants to add notes to a patch, that's fine
21:36:40 <notmyname> it works with the release tooling, there's a link on a web page, and patch authors can add some extra notes if they want to their patch
21:37:05 <cschwede> notmyname: well, back to the topic, we can learn from the experience and improve the workflow over time? ie see what’s working for us as group and you as release cutter?
21:37:15 <notmyname> cschwede: of course :-)
21:37:52 <mattoliverau> if its something that we do, it should be documented somewhere. ie. note naming standard etc.
21:38:16 <mattoliverau> or is it just patch sha and version each time
21:38:39 <notmyname> mattoliverau: it's install reno then use `reno new` and edit the resulting file
21:38:53 <mattoliverau> notmyname: right, even easier :P
21:39:38 <notmyname> and `reno report` to look at the results (although note that the yaml file must be in the git DAG before being used--you can't just have a local scratch file that's uncommitted [`git commit -am WIP` will be common, I suspect]
21:39:56 <notmyname> ok, we need to move on :-)
21:40:05 <clayg> notmyname: I don't recall asking you if you think this is something you'd want outside of it recently becoming a topic of contention - but I like that sentiment!
21:40:06 <notmyname> reno's a thing. ta da!
21:40:11 <clayg> it *feels* like something I would say
21:40:17 <clayg> also hooray!
21:40:27 <notmyname> #topic liaisons
21:40:43 * clayg should have stayed in his hole
21:40:53 <joeljwright> clayg: go, I'll cover you
21:41:04 <clayg> NO MAN LEFT BEHIND!
21:41:07 <notmyname> FYI, if someone is passionate about some of the things happening in other projects, take a look at https://wiki.openstack.org/wiki/CrossProjectLiaisons
21:41:26 <notmyname> if there's not a name listed, it defaults to the PTL
21:41:56 <notmyname> I'm not asking everyone to sign up for something--that's up to you (and I'm happy to continue being a point person as needed)
21:42:15 <notmyname> but I want to make sure people are aware of this way to get involved in other openstack efforts
21:42:31 <notmyname> #topic plan for golang, post TC decision
21:42:49 <notmyname> ok, this will probably take the rest of our time today
21:43:09 <notmyname> last week I was in NYC and I talked fact-to-face with quite a few TC members
21:43:47 <notmyname> honestly, it would be very hard to summarize (especially in the next 15 minutes)
21:44:27 <notmyname> but from a very high level, there's lots of opinions :-)
21:44:40 <nadeem> :)
21:44:45 * clayg sorta had some thought on the cross-project stuff - we spent to much time talking about release notes formatting software/process :'(
21:45:04 <notmyname> but in this meeting, let's focus on some of the tech issues and actual user problems
21:45:16 <notmyname> there's a ton going on in swift by everyone
21:45:42 <notmyname> and as we've been talking about for the last many months, the golang replication and object server is hugely important
21:45:59 <notmyname> right now, we've got feature/repconn for the object replicator daemon work
21:46:14 <notmyname> I'm expecting to see something there from nadeem very very soon so we can all dig into it
21:46:50 <notmyname> the goal with repconn is to get the golang replacement for the python object replicator, initially focussed on the new repconn protocol
21:47:01 <notmyname> for now, work will continue in the feature branch
21:47:18 <notmyname> we will not merge it to master and we will not move it to a separate repo yet
21:47:56 <notmyname> basically, let's not do something drastic until we actually have to (ie a release where a golang replicator is a thing)
21:48:30 <notmyname> nadeem: what the status of the repconn work
21:48:34 <notmyname> ?
21:49:20 * notmyname knows he saw nadeem in here earlier...
21:49:50 <clayg> notmyname: i was *going* to work on feature/hummingbird this week - but I barely got started before pulled onto something else
21:49:52 <nadeem> I should have a PR ready either tonight or tomorrow morning
21:49:52 <mattoliverau> maybe he's getting his notes in order to paste :)
21:50:00 <notmyname> nadeem: yay!
21:50:04 <clayg> but i'm almost done with that!  so hope to get back at it by the end of thweek
21:50:17 <notmyname> clayg: looks like nadeem has something for you to look at by then :-)
21:50:49 <clayg> notmyname: yeah... it's going to be interesting to see how feature/hummingbird and feature/repconn evolve
21:51:01 <notmyname> indeed
21:51:08 <nadeem> however in this PR, I am only working on moving REPCONN call from object server to replicator
21:51:29 <notmyname> nadeem: great starting point. that's what we talked about in san antonio
21:51:31 <clayg> basically we've put nadeem in charge of putting together a vision for how swift will evlove to ingest hummingbird - we sorta narrowed scope for him - but it's got to be a huge chore
21:51:44 <nadeem> cool
21:51:48 <notmyname> clayg: that's for all of us to work on :-)
21:51:59 <clayg> i'm sorta surpised he hasn't had more questions like "well shit, how the f am i going to pull apart xyz - do ya'll have an opinon on option a vs b?"
21:52:06 <clayg> ... maybe it was less than I realized
21:52:14 <clayg> notmyname: idk, depends on how big the patch is
21:52:22 <notmyname> we'll see in the morning
21:52:38 <clayg> nadeem: do you expect your upcoming push to be... like "done" or is it toally just a starting point wip to start a conversation?
21:52:55 <nadeem> WIP
21:52:55 <notmyname> and for everyone, yes, you have permission to work on the golang object replicator in the repconn branch or the more general golang stuff in hummingbird
21:52:55 <clayg> nadeem: are we gunna need to like skype or something so you can highbandwidth drop some knowledge on us?
21:52:56 <nadeem> mostly
21:53:16 <nadeem> because we haven't decided on how to split objectserver & replicator
21:53:42 <clayg> nadeem: oic
21:53:59 <clayg> nadeem: so you are going to push to feature/repconn on feature/hummingbird with just that change (move the REPCONN connection)
21:54:02 <nadeem> we can decide that after this initial PR
21:54:14 <nadeem> right now to just feature/hummingbird
21:54:15 <clayg> nadeem: "that"?
21:54:20 <notmyname> nadeem: oh?
21:54:22 <clayg> nadeem: ok, np, that makes sense
21:54:38 <notmyname> I was under the assumption you were going to push to repconn
21:54:58 <nadeem> once we finalize on how to split the object server & replicator we can push it to repconn
21:55:00 <clayg> notmyname: no that makes sense - get the feature/hummingbird (which works) in order closer to our target so we can start to think about what the real drop feature/repconn is going to look like
21:55:01 <notmyname> ok
21:55:20 <clayg> notmyname: nadeem: I think this is correct (not that anyone asked me)
21:55:33 <notmyname> yeah, it makes sense
21:55:54 <clayg> nadeem: you should have clarified - you can just just drop in channel and be like "FYI i'm doing this" - *I* totally appreciate that
21:56:19 <nadeem> sorry I should have clarified earlier
21:56:27 <nadeem> anyhow will do that going forward
21:56:29 <clayg> nadeem: dood, no worries
21:56:29 <notmyname> nadeem: I'm looking forward to seeing it :-)
21:56:37 <clayg> yeah for sure
21:56:45 <notmyname> any other questions or issues to bring up on the golang work?
21:57:28 <nadeem> do we have a time frame for when Repconn will be mainstream?
21:57:49 <notmyname> nadeem: asap
21:57:58 <clayg> nadeem: I think realistically the newton release is off the table :'(
21:58:07 <notmyname> users are broken today without it
21:58:09 <clayg> but that's just my pessemistic opinion
21:58:17 <notmyname> back in austin, we were hoping that it would be done by barca
21:58:39 <nadeem> but it will still be in feature branch...
21:58:42 <notmyname> however the tc governance discussions kinda delayed that by several months
21:58:54 <clayg> right, i think we all got derailed and there's still some unknowns - not so much with technical feasability - but like just the merge and gate and upgrades - who knows
21:58:56 <pdardeau> notmyname: are you expecting it to be in separate repo?
21:59:04 <notmyname> pdardeau: don't know yet
21:59:23 <notmyname> nadeem: yeah, and as soon as it's a good replacement to the python one, we'll be at the decision point for where it lives
21:59:24 <clayg> pdardeau: right now it's a branch - can't make a choice about where to merge until it's ready to merge somehwere!
21:59:42 <pdardeau> clayg: understood. just asking about plans
22:00:07 <clayg> pdardeau: FWIW, IMHO, merge to openstack/swift or openstack/swift-extra is a win either way - as long as we fix replication and continue to deliver ever improving cloud software to operators we're "doing it right"
22:00:28 <notmyname> focus on the users :-)
22:00:29 <clayg> they don't care about python vs. golang - they don't care about git vs bzr or some other repo - they need better replication
22:00:34 <notmyname> ok, we're out of time
22:00:40 <notmyname> thank you everyone for coming
22:00:45 <notmyname> thank you for working on swift
22:01:02 <notmyname> and thank you jrichli for your work and for stepping up to core
22:01:03 <nadeem> however splitting stuff will take toll on swift community
22:01:08 <notmyname> #endmeeting