21:00:27 <notmyname> #startmeeting swift
21:00:28 <openstack> Meeting started Wed Jul 20 21:00:27 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:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:31 <openstack> The meeting name has been set to 'swift'
21:00:39 <notmyname> who's here for the swift team meeting?
21:00:42 <cschwede> o/
21:00:45 <mathiasb> o/
21:00:46 <ntata> hello
21:00:49 <kei_yama> o/
21:00:51 <mattoliverau> o/
21:00:52 <dmorita> hi
21:00:54 <hosanai> o/
21:00:54 <sgundur1> hi
21:00:55 <pdardeau> o/
21:01:00 <acoles> here
21:01:17 <kota_> hi
21:01:20 <mmotiani> hi
21:01:26 <tdasilva> hello
21:01:52 <notmyname> welcome everyone
21:02:04 <notmyname> #topic post hackathon...
21:02:06 <torgomatic> ohai
21:02:19 <notmyname> if you weren't at the hackathon in san antonio last week, you were missed
21:02:32 <notmyname> I'm glad it seems everyone made it back safely
21:02:43 <notmyname> (even if mattoliverau wasn't upgraded to first class for his birthday)
21:02:51 <mattoliverau> :(
21:03:27 <notmyname> it was a great week, and thank you hurricanerix for hosting
21:03:36 <mattoliverau> +100
21:04:20 <notmyname> I'd love to hear what everyone is thinking after the hackathon. how was it? what was good/bad?
21:04:25 <notmyname> so we can learn for next time
21:04:52 <clayg> notmyname: best one evar
21:04:54 <notmyname> does anything stand out that was good or bad?
21:05:03 <clayg> ahale was there - that was good
21:05:41 <dmorita> everything we need was available. That was very good.
21:05:46 <ahale> oh meeting time o/ yeah i really got a lot from just meeting people
21:05:50 <mmotiani> I got chance to interact with all the devs and cores in-person. That was the best part for me.
21:06:09 <ahale> and talking about stuff i cant say in logged places
21:06:14 <notmyname> lol
21:06:38 <notmyname> yes, I definitely love the face-to-face and getting to know everyone
21:06:50 <cschwede> we met again and got a lot of things done/discussed - just perfect!
21:07:10 <acoles> notmyname: felt we got discussion going quicker on Monday which was good. few things didn't get selected for main agenda but I think we covered them eventually.
21:07:11 <tdasilva> good as always, can't really think of anything bad that really stood out. thanks hurricanerix for organizing everything!
21:07:12 <notmyname> I would have preferred to have a separate room. I know hurricanerix worked on that, but the logistics didn't work out. not his fault
21:07:18 <notmyname> acoles: yes!
21:07:35 <notmyname> I really liked how the discussions started right off this time
21:08:49 <notmyname> if you had a conversation, write down some notes and please link them on https://wiki.openstack.org/wiki/Swift/ideas
21:09:03 <clayg> notmyname: i think priority topic selection was *a little* off - but there's a million reasons for that as deverse as everyone participating - not sure if there's much to consider there beyond "we're still busy"
21:09:04 <tdasilva> acoles: thanks for the awesome notes on symlinks
21:09:46 <kota_> tdasilva: +1
21:09:47 <acoles> tdasilva: np! that was the conclusion of what began on plane home from Austin ;)
21:09:51 <notmyname> clayg: might be good to try to adjust a little next time
21:10:11 <acoles> notmyname: transferable votes ;)
21:10:12 <tdasilva> clayg: was there any topic you wished we had discussed and it was not?
21:10:30 <notmyname> acoles: your notes are https://etherpad.openstack.org/p/swift_symlinks right?
21:10:42 <clayg> notmyname: maybe we should have looked more closely at the topics with 5-6 dots and tried to encourage people to get them "scheduled" - ackowledgeing there will be overlaps, there will be conflicts, you will miss out - but it's important that important stuff have time carved out
21:11:00 <cschwede> maybe add a 2 hour session with 15 minute timeboxed slots for the small topics next time?
21:11:01 <notmyname> acoles: can you add a link to the ideas wiki page, please?
21:11:04 <clayg> tdasilva: we did a lot of "oh shit we didn't talk about py3" on Thursday - I think we could have been more cognisent of that earlier in the week
21:11:12 <acoles> notmyname: yes
21:11:17 <bkeller`> creating an ordered list of what to cover when major topics end early might be good
21:11:17 <acoles> notmyname: yes
21:11:22 <notmyname> thanks
21:11:26 <mmotiani> cschwede +1
21:11:40 <notmyname> cschwede: lightning talks? :-)
21:11:53 <clayg> notmyname: but overall it feel like we're just talking about iteration on good foundation
21:11:57 <acoles> notmyname: one idea - if someone has brought a new topic then maybe chance to pitch it in 5 mins so we know the scope?
21:12:05 <cschwede> notmyname: no, we need different names ;)
21:12:29 <cschwede> acoles: sounds good to!
21:12:34 <cschwede> too
21:12:36 <acoles> notmyname: oh, what cschwede said is what I mean too
21:12:57 <notmyname> interesting idea. I'm definitely willing to try it!
21:13:01 <tdasilva> acoles: do you mean before we vote on topics?
21:13:04 <mattoliverau> eventual consistancy talks.. by the end we hope to all be on the same page :P
21:13:35 <acoles> tdasilva: yes, quick pitch of new topics before the vote
21:13:44 <clayg> cschwede: acoles: notmyname: some of the "wtf is this" should be on the wiki before we arrive
21:13:53 <tdasilva> acoles: got it
21:14:01 <acoles> clayg: true
21:14:17 <notmyname> yeah. that will mean it will take more time on the first day, but it does help people get up to speed quickly
21:14:18 <clayg> ... but if you see a topic that interests you and doesn't get scheduled we just need to think harder about what that means?
21:14:24 <cschwede> clayg: agreed; but sometimes it’s just easier to talk about things to make them clear?
21:14:48 <clayg> do we as a community just hope that those interested find the time, or do we acknowlege that we care about some smaller topics - and we want to faciliate time for them
21:14:49 <cschwede> clayg: not everyone is going to raise his voice then maybe?
21:15:28 <clayg> cschwede: that's fair
21:15:50 <cschwede> idk; if there are a few short timeslots to get things started, even if they don’t raise attention yet - that might be helpful
21:15:52 <notmyname> one thing is that the top stuff on http://not.mn/swift/swift_community_dashboard.html didn't get many stickers. I think that's really interesting
21:15:55 <clayg> anyway - I thought it was really great overall - I like some of these ideas
21:16:24 <cschwede> yes, overall it was really great!
21:16:26 <clayg> notmyname: that *is* interesting
21:17:54 <acoles> I think we did try to keep an eye on the unscheduled topics and fit them in when there was downtime, or over lunch.
21:17:57 <notmyname> ok, moving on
21:18:10 <clayg> notmyname: I think maybe we favor design discussion when we get together as a group over extream reviewing or something like that
21:18:33 <notmyname> we do. I dont think that's bad. and I've seent he intense review be great too
21:18:44 <notmyname> maybe we just have too many big design things going on at once?
21:18:48 <clayg> acoles: yes, self organization is "working pretty well"
21:19:12 <clayg> it's all good
21:19:17 <cschwede> some challenging architecture discussions just work better in person, and that seems to be the right place
21:19:25 <ahale> so i had some feedback from some of the other rackspace ops people - they thought it was going to be a ton of code reviews, actual hacking - not talking. if they'd realised that they would have probably been there too
21:19:31 <notmyname> (on the self-organizing front) the whole point of the very first hackathon was just 
to get people in the same physical room, and it turend out pretty great
21:20:12 <notmyname> ahale: yeah, more ops == more better
21:20:20 <kota_> ah, one thing. thanks for giving us for hummingbird performance evaluation of NTT;-)
21:20:36 <tdasilva> kota_: thanks for presenting it! great info
21:20:36 <notmyname> kota_: that was great feedback!
21:20:37 <acoles> I favour using hackathon for things that need face to face and are harder to do on gerrit or etherpad. that can include code review, but is often design.
21:21:17 * cschwede nods to Alistair
21:21:21 <kota_> and if you want to get slides, could you please send a n E-mail for yamamoto.kimihiro@lab.ntt.co.jp (with c.c.ed for me)?
21:21:41 <cschwede> kota: i think he will get a lot of mails soon ;)
21:21:44 <acoles> ** all go to email ;)
21:21:44 <kota_> sorry, I didn't get approval to upload it to online for public.
21:21:52 <notmyname> ok
21:22:02 <kota_> sorry inconvinience
21:22:43 <notmyname> ok, let's move on to some of the specific topics
21:22:52 <notmyname> #topic hummingbird plan (repconn)
21:23:01 <notmyname> the summary is this
21:23:18 <notmyname> the first thing we will incorporate into master is the repconn functionality of the object replicator
21:23:30 <notmyname> we will not bring the whole golang object server over yet
21:23:49 <notmyname> and we all (very strongly) agreed that we want one and only one object server implementation on master at a time
21:24:26 <notmyname> so there's some work to do to get that on master
21:24:48 <notmyname> on the technical front, there now exists feature/repconn which is for the code we want to be on master
21:25:26 <notmyname> we need the repconn handler to be moved from the hummingbird object server to the object replicator daemon
21:25:26 <clayg> http://img.pandawhale.com/post-57023-arrested-development-wink-nod-h6aB.gif
21:25:59 <clayg> https://etherpad.openstack.org/p/hummingbird-replication-upgrade
21:26:00 <notmyname> that and the neede dutils will go into the repconn branch
21:26:13 <notmyname> yeah, thanks clayg. I'm basically going over the top of that
21:26:47 <clayg> also, turns out that hummingbirds and swifts are all in the same order -> https://en.wikipedia.org/wiki/Apodiformes
21:26:50 <clayg> so... it's all good
21:26:52 <notmyname> starting/managing golang processes with swift-init is important (operationally and also for probe tests)
21:26:59 <pdardeau> clayg: you provide awesome visuals!
21:27:47 <notmyname> with the repconn work, we'll need a lot of effort, I think. but we'll get a huge return
21:28:03 <notmyname> it's possible that we could have this work done by barcelona. that's 3 months from now
21:29:33 <clayg> notmyname: yeah let's do it!!!! WHOOOO!
21:29:46 <notmyname> on the non-tech side, I'm working on a new TC governance resolution with great input from acoles and clayg about having golang in our master branch
21:29:55 <clayg> oh yeah... that
21:30:03 <notmyname> I expect to have a public draft of that available this week
21:30:16 <notmyname> any questions on this topic, overall? what we're doing or how it all fits together?
21:30:59 <notmyname> ok, great :-)
21:31:06 <notmyname> #topic container sharding
21:31:32 <mattoliverau> \o/ go sharding.
21:31:33 <notmyname> this is the other big thing
21:31:54 <notmyname> mattoliverau's been doing a ton of great work, and went over it a lot last week
21:32:10 <mattoliverau> thanks
21:32:16 <notmyname> IMO repconn and container sharding are the two most important things going on right now
21:32:21 <mattoliverau> I had some great conversations with others during the week
21:32:52 <mattoliverau> I'll write up what we discussed in more detail.. then those I talked to can poke holes in my memory :)
21:33:03 <notmyname> that woudl be fantastic
21:33:15 <notmyname> or add it to https://etherpad.openstack.org/p/container-sharding-SAT-2016
21:33:31 <mattoliverau> I wrote down some rough notes from the actaul session. But theres probably more to it now (thanks to beer)
21:33:32 <mattoliverau> sure
21:33:58 <tdasilva> beer refreshes memory?
21:34:24 <mattoliverau> no, but we sure talk alot :P
21:34:28 <tdasilva> lol
21:34:37 <notmyname> and if you're looking for something to do, jump into the golang repconn work or the container sharding work. both of these solve problems for existing users and give us a great foundation for the next five years of swift
21:35:29 <notmyname> mattoliverau: I'd love to make sure the TODO list is up to date and that the code is easy to collaborate on
21:35:42 <mattoliverau> +1
21:36:02 <notmyname> mattoliverau: please let me know if I can help with any of that, and I'll keep bugging you about it too
21:36:18 <notmyname> any questions from anyone on container sharding?
21:36:18 <mattoliverau> great thanks :)
21:37:00 <notmyname> #topic rolling upgrade tests
21:37:11 <notmyname> I wanted to mention this again, now that the crypto rush is over
21:37:22 <notmyname> cschwede: what's up? and pdardeau you were getting into it, too, I think
21:37:36 <cschwede> notmyname: nothing new… waiting for reviews.
21:37:43 <notmyname> from -infra?
21:37:50 <cschwede> yes
21:38:20 <notmyname> patch 304465
21:38:20 <patchbot> notmyname: https://review.openstack.org/#/c/304465/ - openstack-infra/devstack-gate - Use subnodes for Swift storage nodes in a multinod...
21:38:25 <notmyname> that one, right?
21:38:37 <cschwede> exactly, you were faster
21:38:57 <notmyname> the notes I've got are at https://etherpad.openstack.org/p/swift-rolling-upgrade-multinode-testing
21:39:14 <notmyname> cschwede: what do we need after that lands? or is that the end?
21:39:47 <cschwede> notmyname: it’s nearly the end then. we will have a proxy and a storage node on a second vm (subnode) then, and that one gets updated
21:39:53 <cschwede> during the tests
21:40:11 <notmyname> anything else required in the swift repo?
21:40:21 <cschwede> the subnode only runs a subpart of nova right now for rolling upgrade tests, and will run swift storage too then
21:41:11 <cschwede> i don’t think so - at least not for the moment. we might want to look if we could add more tests for upgrades, but i thin we’re pretty well covered already
21:41:21 <cschwede> s/thin/think/
21:41:23 <notmyname> pdardeau: are you getting involved with this too? or were your questions early more curiosity?
21:41:29 <pdardeau> will the introduction of repconn make the rolling upgrade a little tricky?
21:41:30 <notmyname> cschwede: ok, great
21:41:39 <notmyname> pdardeau: not if we do it right ;-)
21:41:51 <pdardeau> curiosity
21:41:53 <cschwede> pdardeau: well that will get interesting :)
21:42:09 <notmyname> pdardeau: aww, man. I was hoping I could start bugging you about it too ;-)
21:42:22 <cschwede> and is a nice reason to have that rolling upgrade tests landed before
21:42:42 <pdardeau> notmyname: you can, it'll just get added to the list ;-)
21:42:48 <notmyname> actually, I don't think the rolling upgrade tests will be affected much by repconn specifically. those are functests only. what will be more interesting is probe tests
21:43:17 <cschwede> notmyname: well, tempest also runs there iirc. so it’s nice to know from an end-user perspective
21:43:25 <notmyname> of course, that's me just speaking from the perspective of what's needed to make the gate pass. we certainly will need to consider that with repconn
21:43:44 <notmyname> cschwede: yeah, but my point is that tempest tests are only func tests
21:43:56 <cschwede> notmyname: ah, ok, got what you mean
21:44:00 <notmyname> cschwede: ie replication daemons or ec or whatever is completely transparent
21:44:02 <notmyname> yeha
21:44:10 <cschwede> yes, should be
21:44:33 <cschwede> i was thinking on new dependencies and how to switch to a golang service during upgrade
21:44:40 <cschwede> on the gate, that is
21:44:43 <notmyname> any questions from anyone about the rolling upgrade tests?
21:44:50 <notmyname> cschwede: right. that will be "fun"
21:45:17 <notmyname> but if we do it right, `swift-init object-replicator restart` shoudl Just Work (tm)
21:45:19 <mattoliverau> I dont think that work means what you think it does :P
21:45:36 <mattoliverau> s/work/word/
21:46:11 <notmyname> cschwede: thanks for keeping on the patch. what can any of the rest of us do to help move it along?
21:46:15 <cschwede> notmyname: would be awesome, and we’re working hard to make that happen!
21:46:39 <cschwede> notmyname: not for now, thx! might need some pings to -infra, but i can start the discussion as well
21:46:48 <notmyname> ok, great. I'll look for those
21:47:11 <notmyname> #topic other priorities
21:47:45 <notmyname> like I said, repconn and container sharding are IMO the 2 most important things going on right now (ie to land in the next few months)
21:47:47 <mattoliverau> cschwede: I'll poke my infra-core coworker.
21:47:50 <notmyname> but there's a lot of other stuff
21:47:52 <notmyname> mattoliverau: thanks
21:47:57 <notmyname> but there's a lot of other stuff going on too
21:48:06 <cschwede> mattoliverau: thx!
21:48:49 <notmyname> policy migration, global EC, composite rings, symlings, notifications, etc
21:49:03 <notmyname> part power increases ( cschwede what's the patch?)
21:49:25 <cschwede> patch 337297
21:49:25 <patchbot> cschwede: https://review.openstack.org/#/c/337297/ - swift - Add support to increase object ring partition power
21:49:46 <notmyname> hmm...how do I phrase this not like "begging for reviews"? what's the other patches we should be looking at?
21:50:18 <notmyname> cschwede: I was really happy to hear how far you were along on that feature!
21:50:22 <timburke> thanks tdasilva and cschwede, for starting to look at https://review.openstack.org/#/c/214922/
21:50:23 <patchbot> timburke: patch 214922 - swift - Add "history" mode to versioned_writes middleware
21:50:30 <acoles> notmyname: does patchbot recognise wildcards ? ;)
21:50:37 <notmyname> patch *
21:50:46 <notmyname> not yet ;-)
21:50:58 <timburke> notmyname: you don't really want that :-)
21:51:16 <notmyname> oh, I think it would short-circuit to "Nope"
21:51:55 <mattoliverau> it should allow it, and then you need to use marker,end_marker to page through :P
21:52:12 <kota_> lol
21:52:21 <clayg> mattoliverau: you going to do patchbot sharding?
21:52:27 <acoles> mattoliverau: soon we'll need it to shard
21:52:37 <acoles> aww clayg got there first !
21:52:41 <mattoliverau> lol,.sure how hard can that be :P
21:52:52 <mattoliverau> *famous last words*
21:53:49 <tdasilva> can anybody give a very quick summary of how the auto-tier conversation went? like a one-liner
21:53:54 <notmyname> so I've seen ring part power increase and history mode. anything else someone wants to highlight for the team this week?
21:54:50 <acoles> tdasilva: had you left? "auto-tiering can use symlinks, posts go to the symlink"
21:55:01 <kota_> tdasilva: got a great feedback, probably auto-tier can use symlink
21:55:08 <kota_> acoles: ;-)
21:55:40 <cschwede> was that discussion about policy migration as well? on thursday afternoon?
21:55:55 <kota_> dmorita:^^
21:55:56 <tdasilva> acoles, kota_: got started with the symlink work, so at some point I'd like to catch up with the work ntt is doing on auto-tiering so we can be on the same page
21:56:28 <dmorita> Ya. We had a discussion on Thursday afternoon.
21:56:30 <kota_> tdasilva: ok, will poke mkazuhiro that be in vacation in this week :/
21:56:37 <acoles> tdasilva: +1 need to line those pieces of work up
21:56:50 <tdasilva> kota_: ok, no problem, I'll go look at the patch to see where things are
21:56:51 <tdasilva> thanks
21:57:11 <notmyname> tdasilva: great question
21:57:28 <notmyname> anything else from anyone? 3 minutes left in our time slot
21:57:42 <torgomatic> if anyone has any idea how the gate vms are built, ping me
21:57:48 <kota_> ah, not hackathon related
21:57:51 <kota_> one thing
21:58:00 <torgomatic> I'm looking at https://review.openstack.org/#/c/336323/ which seems sane except for the gate
21:58:00 <patchbot> torgomatic: patch 336323 - swift - Add checksum to object extended attributes
21:58:21 <kota_> if someone can help for reviewing https://bugs.launchpad.net/pyeclib/+bug/1604335
21:58:21 <openstack> Launchpad bug 1604335 in OpenStack Object Storage (swift) "get_segment_info leaks reference count for items" [Undecided,New]
21:58:32 <kota_> it is great to me
21:58:44 <cschwede> torgomatic: i’ll can have a look tomorrow
21:58:46 <kota_> i finally got the reason EC policy can leak memory.
21:58:58 <notmyname> kota_: is that a swift bug or pyeclib bug?
21:59:07 <kota_> yes
21:59:11 <notmyname> heh
21:59:30 <tdasilva> smart answer
21:59:39 <kota_> and tsg- and kmgreen2 know it already but I know they are not able to 100% swift work.
21:59:56 <kota_> so if swifters can help it, it's great.
22:00:03 <notmyname> ok
22:00:27 <notmyname> we're out of time for this week
22:00:30 <acoles> I'm confused about keystone default domain, the default id seems to have changed, if anyone understands please comment on https://bugs.launchpad.net/bugs/1604674
22:00:30 <openstack> Launchpad bug 1604674 in OpenStack Object Storage (swift) "Doc error in Auth Overview for specifying keystone domain " [Undecided,New]
22:00:38 <kota_> oh, sorry, pyeclib bug notmyname
22:00:41 <notmyname> thank you, everyone, for coming. and thank you for working on swift
22:00:52 <kota_> i saw just the last chunk of the line :/
22:01:04 <notmyname> #endmeeting