19:00:15 <notmyname> #startmeeting swift
19:00:16 <openstack> Meeting started Wed Oct 22 19:00:15 2014 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:19 <openstack> The meeting name has been set to 'swift'
19:00:20 <notmyname> hello world
19:00:25 <notmyname> who's here for the swift meeting?
19:00:27 <peluse> rock n roll
19:00:28 <cutforth> hola
19:00:32 <cschwede> o/
19:00:32 <Tyger> bonjour
19:00:40 <torgomatic> .
19:00:46 <kota_> o/
19:00:50 <mattoliverau> o/
19:00:57 <elambert> o/
19:01:11 <notmyname> welcome :-)
19:01:22 <lpabon> here
19:01:30 <notmyname> I want to spend most of the time talking about the summit session topics
19:01:34 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:01:39 <notmyname> acoles: here?
19:02:24 <acoles> here
19:02:28 <notmyname> great
19:02:31 <peluse> well, finally :)
19:02:38 <notmyname> I want to start with your topic :-)
19:02:50 <notmyname> #topic Proposed change to move devstack functional tests to use keystone v3
19:03:27 <notmyname> #link https://review.openstack.org/#/c/128888/
19:03:38 <notmyname> #link https://review.openstack.org/#/c/130162/
19:03:41 <notmyname> acoles: tell us more
19:04:11 <acoles> ok, so the context is that some functional tests are skipped on jenkins because they need account in a non-default domain
19:04:20 <acoles> and i would like them to not be skipped!
19:04:37 <notmyname> seems reasonable :-)
19:04:52 <acoles> so the devstack changes (128888) put support in place for those tests
19:05:21 <acoles> i.e. setup another account, and configure the tests to use v3 API
19:06:07 <acoles> then the change in 130162 will flip the switch (devstack takes the value for authAPI version from test.conf)
19:06:29 <peluse> acoles, so I assume the devstack side needs to land before we commit the swift patch and also, separate question since I haven't looked at the swift side yet, does that affect our local functional tests or saio env?
19:06:59 <notmyname> or is it that the swift one lands before devstack?
19:07:03 <notmyname> which one goes first?
19:07:17 <acoles> peluse: yes devstack patch needs to land first and 130162 is failing anyway until 128888 lands
19:07:58 <peluse> OK, yeah, looks like you have it workflow -1 awaiting just that thing to happen... what about saio env (local functional tests)?
19:08:06 <acoles> i did it that way so that swift cores get to vote the test behaviour switch through rather than devstack
19:08:21 <notmyname> acoles: what do we need to do on the swift side to get the devstack patch landed?
19:09:34 <acoles> peluse: re saio, the change in test.conf is to a comment so will only affect if you have local CI that uncomments (as devstack does) or are used to manually uncommenting and need to stick with v2 API
19:10:09 <acoles> notmyname: so if you are happy it would be great to get some +1 form swift folks on the devstack patch - it has a +2 already
19:10:23 <notmyname> ok
19:10:26 <mattoliverau> I'd say swift guys go give a +1 to the devstack change if you agree with the patch, I think that would help the infra/qa guys know that we're in ageement.
19:10:47 <notmyname> sounds good
19:10:56 <acoles> so devstack patch that is https://review.openstack.org/#/c/128888/
19:11:07 <notmyname> acoles: anything else you need to bring up for those 2 patches?
19:11:11 <notmyname> acoles: thanks for working on it!
19:11:25 <peluse> mr v3!
19:11:26 <acoles> if/when that lands i will ping swift folks about 130162
19:11:40 <acoles> peluse: roll on v4, i'm ready ;)
19:11:50 <notmyname> heh
19:11:51 <mattoliverau> lol
19:11:58 <notmyname> watch out, they might! ;-)
19:12:32 <clayg> yeah careful what you wish for :\
19:12:43 <notmyname> ok, let's move on to the paris scheduling
19:12:49 <notmyname> #topic paris summit scheduling
19:12:56 * clayg dusts off his devstack vm
19:13:00 <notmyname> who here is going to be in paris?
19:13:08 <mattoliverau> o/
19:13:09 <peluse> o/
19:13:09 <kota_> o/
19:13:11 <gvernik> i am
19:13:13 <lpabon> me
19:13:14 <acoles> oui
19:13:19 <peluse> nice!
19:13:19 <clayg> o/
19:13:27 <notmyname> great!
19:13:28 <clayg> kota_: !!!!
19:13:31 * cutforth wishes he was going to Paris, but is saddened he is not
19:13:42 <Tyger> I'll be there
19:13:42 <kota_> clayg: :)
19:13:47 <lpabon> tdasilva is going also
19:13:49 <tdasilva> o/
19:14:01 <peluse> kota you must be the king of frequent flyer miles :)
19:14:05 <notmyname> lol
19:14:13 <notmyname> so here's what I know about the design summit for swift
19:14:21 <kota_> peluse: lol
19:14:23 <notmyname> 1) we've got 6 slots to schedule
19:14:35 <notmyname> 2) we've got a half-day of unscheduled time on Friday
19:14:36 <clayg> lol (?) at devstack "World dumping..."
19:14:46 <notmyname> 3) there are cross-project topics that we should look at
19:15:09 <notmyname> 4) near-final schedule for swift sessions should be published by next tuesday
19:15:50 <peluse> wrt cross project - meaning we should make sure that a pile of us attend those sessions whenever they are scheduled or that we should dicusss them in our free block?
19:15:52 <notmyname> so here's what I want to do now. I want to go over what has been proposed and prioritize them. then I will take that and schedule them later this week or this weekend and push it up for the formal schedule
19:16:29 <notmyname> for cross-project, meaning that we should look at what's scheduled and attend the ones that pertain to swift/storage
19:17:05 <clayg> peluse: yeah like if glance wants to talk about the swift storage backend - we should consider going, if cinder wants to talk about volume archives to object storage we should go
19:17:12 <notmyname> peluse: meaning, don't just focus on the narrow swift things, but take advantage of the other in-person conversations while we're together ;-)
19:17:20 <notmyname> clayg: yup. exactly
19:17:27 <clayg> peluse: if olso wants to talk about how they're nazi's - well.... notmyname should go
19:17:41 <peluse> agreed, one of my co-workers (Reddy Chagham) has some cross project topics that, if scheduled, should draw some of us from the Swift side for sure
19:17:49 <notmyname> clayg: I think Ihave other commitments during that time block ;-)
19:17:52 <peluse> well, I typed that "agreed" before clayg's comment
19:18:03 <clayg> hehehehehhehe - i'm tricky like that
19:18:11 <notmyname> #link https://etherpad.openstack.org/p/kilo-swift-summit-topics
19:18:25 <notmyname> ^ there's the etherpad of our proposed sessions
19:18:36 <notmyname> so let's go through them one at a time, top to bottom
19:18:51 <notmyname> first, erasure code overview
19:19:06 <notmyname> I proposed this one, but I suspect peluse might have one or two things to say ;-)
19:19:20 <peluse> so we can spend hours on that... we should narrow down to something more specific that people can get into
19:19:22 <notmyname> IMO this needs to happen since it's a big part of current work
19:19:29 <notmyname> peluse: agreed
19:19:36 <peluse> like make the PUT path/MIME support or the reconstructor in detail (one of those)
19:19:48 <peluse> and then maybe an overall ststus thingy for the open session in causal conversation
19:19:53 <notmyname> with an eye to an overview of the design?
19:20:02 * clayg cries at MIME (because he doesn't have any better ideas)
19:20:09 <peluse> BTW... latest design spec is really fun  to read for anyone that wants to see it;  http://docs-draft.openstack.org/90/125190/8/gate/gate-swift-specs-docs/2d2cf67/doc/build/html/specs/swift/erasure_coding.html
19:20:11 <peluse> yes
19:20:11 <notmyname> I wonder if there's any chance of having rudamentary PUT/GET patch support by then
19:20:24 <peluse> there should be I think, tsg?
19:20:41 <notmyname> well, tsg and torgomatic
19:20:52 <clayg> peluse: it's getting big - i'm having a hard time keeping up with drift w/o having to just re-read the thing from top to bottom
19:20:53 * peluse is making MIME signals to clayg right now :)
19:20:55 <tsg> notmyname: yes, a first version of PUT+MIME patch should up
19:21:02 <notmyname> torgomatic is typing on PUT stuff right now I think
19:21:16 <torgomatic> yeah, I was curious how it'd go, and I think I might have some stuff soonish
19:21:29 <peluse> fantastic!
19:21:59 <notmyname> peluse: can you add some notes to the etherpad of what specifically you want to cover during the formal session?
19:22:32 <peluse> back to clayg's comment wrt the design spec - yeah it is getting big so maybe we take the EC sessions and do 50% overview and 50% drill down on one topic (like PUT/MIME or something)
19:22:35 <peluse> yes, I'll do that
19:22:41 <notmyname> peluse: thanks
19:22:48 <notmyname> ok, next topic proposed
19:22:57 <notmyname> queue integration and/or callbacks
19:23:17 <notmyname> this is something that's come up from time to time. I think it's pretty interesting, but IMO it's not a top priority for paris
19:23:30 <notmyname> mostly because there isn't actually anyone working on this in the near term that I know of
19:23:56 <notmyname> so I'd only schedule this one if there aren't less important ones. but I'd liek to have it on the whiteboard for the informal sessions
19:24:00 <clayg> notmyname: maybe the zerovm guys?  who knows?
19:24:07 <notmyname> yeah, maybe
19:24:22 <torgomatic> you mean Swift emitting events or consuming them?
19:24:24 <mattoliverau> Why dont we push it to the 1/2 conversations, the if we have time :)
19:24:28 <torgomatic> one of these things is reasonable, one is not :)
19:24:43 <notmyname> that's the thing. on the other hand paris might be the good place to talk with zerovm/zaqar/etc
19:25:15 <notmyname> torgomatic: swift putting stuff on a queue or otherwise emitting events when something happens
19:25:24 <torgomatic> notmyname: okay, the good one then. got it.
19:25:27 <notmyname> :-)
19:25:36 <cschwede> +1 on this :9
19:25:45 <notmyname> ok :-)
19:26:11 <notmyname> I'll come back to it depending on how the other proposed go :-)
19:26:17 <notmyname> next up
19:26:19 <notmyname> service tokens
19:26:27 <notmyname> this is something we talked about in westford
19:26:54 <notmyname> it has the advantage of having integration with cinder/glance, so paris is a good time to talk about it
19:26:59 <acoles> donagh and i have been doing more work on that since westford and will have a revised spec real soon
19:27:05 <notmyname> ok
19:27:10 <notmyname> acoles: both of you will be in paris?
19:27:19 <acoles> just me unfortunately
19:27:28 <notmyname> ok
19:28:26 <clayg> service tokens sounds like something I will probably not understand very well :\
19:28:30 <notmyname> so higer priority (because of other projects) than queuing
19:28:42 <notmyname> clayg: 2 auth tokens at the same time
19:28:54 <clayg> when 8k isn't enough - you've always got 16k
19:29:00 <peluse> do we need to use service token to use the restrooms in Paris?
19:29:01 <notmyname> :-)
19:29:09 <clayg> why have one when you can have two for only twice as much!
19:29:14 <torgomatic> I guess if you've got a million dollars, that's a thing you can do
19:29:27 <clayg> dfg!!!!
19:29:34 <dfg> hey clayg
19:29:47 <notmyname> ok, next proposed session
19:30:01 <notmyname> performance improvements in all-in-one (PACO) deployments
19:30:14 <notmyname> this was brought up and discussed in westford
19:30:22 <notmyname> tdasilva: anything to add here
19:30:24 <notmyname> ?
19:30:39 <tdasilva> I talked to Ignacio yesterday, he is already in Paris
19:30:45 <tdasilva> both of us have been doing some work on it
19:30:48 <notmyname> ok, wow
19:30:52 <tdasilva> and would like to discuss with the group about it
19:31:02 <notmyname> I think it's a really interesting idea, but could be done in the ad-hoc sessions.
19:31:07 <notmyname> tdasilva: argue with me :-)
19:31:21 * tdasilva is really bad at that
19:31:24 <tdasilva> hehe
19:31:25 <notmyname> lol
19:31:40 <tdasilva> not sure what the format of the ad-hoc sessions are
19:31:49 <notmyname> ok, what does everyone else think? better or worse than queue integration for a formal session?
19:31:57 <tdasilva> but would definetely like to have some time to talk about it
19:31:57 <peluse> better
19:32:00 <notmyname> tdasilva: the ad-hoc sessions will be very much like westford
19:32:03 <acoles> better
19:32:15 <notmyname> doen :-)
19:32:17 <notmyname> it's better
19:32:37 <notmyname> next up
19:32:41 <notmyname> app developer tools
19:32:49 <notmyname> I proposed this one. here's my thinking
19:33:04 <notmyname> we've got a pretty cool storage engine, but we need to make sure people use it
19:33:27 <notmyname> that means working on producing stuff as the swift dev that make it easier for the ecosystem to grow.
19:33:52 <cschwede> notmyname: is this limited to a python client or other languages as well?
19:33:59 <notmyname> this session would be to disucss what those things are and find people to do it
19:34:25 <notmyname> cschwede: yes clients, but also docs, setup scripts, other guides
19:34:45 <notmyname> mostly I see it as a gap in the community right now, and I don't know who's going to fill it
19:34:58 <cschwede> notmyname: ok, sounds like „everything“ on the user/dev side. great
19:34:58 <notmyname> thoughts?
19:35:02 <tdasilva> notmyname: does this involve ops tools such as deployment and monitoring?
19:35:07 <peluse> maybe we can find a company that focuses its core business on Swift :)
19:35:12 <notmyname> tdasilva: no. app-dev
19:35:15 <notmyname> peluse: hmm ;-)
19:35:47 * cschwede thinks this topic is important…
19:36:12 <notmyname> cschwede: important as in we should take it upon ourselves? or important as in "yeah, somebody should do something about it"
19:36:17 <mattoliverau> +1 the idea, our documentation is good but samples etc should help adopt more usage.
19:36:25 <peluse> agree... did the data migration middleware from Gil show up once as a topic on etherpad?  Seems like a good example of something that falls in this category
19:36:57 <mattoliverau> we should, being the people that undertand the middle wares.. and hopefully foster app devs to get involved
19:37:01 <zaitcev> do we have a Go client
19:37:07 <cschwede> notmyname: we should work on this (imo) - if „somebody“ needs to work on this we start again in 5-6 months
19:37:08 <gvernik> peluse: I added it there
19:37:18 <peluse> ahh, great
19:37:38 <notmyname> peluse: and we could choose to combine sessions too, if that's best
19:37:42 <peluse> was right in front of me, must be going blind...
19:37:54 <notmyname> peluse: go get a bigger monitor ;-)
19:38:17 <peluse> bigger is indeed better...
19:38:25 <notmyname> so on a scale of 1-10 (10 being highest), where would rank this session topic?
19:38:46 <notmyname> (FWIW, we have 10 proposed topics for 6 slots)
19:39:06 <notmyname> ie is this one 1 of the 4 that gets moved to the ad-hoc discussions
19:39:29 <peluse> that probably makes the most sense becaues it will be a lot of general ad-hoc discussion
19:39:39 <mattoliverau> 5-6, it should be discussed.. but might be ok in the ad-hoc.. so long as it gets covered
19:39:43 <tdasilva> i'd vote this is less than the previous one :P
19:39:55 <notmyname> ok
19:39:58 <Tyger> It seems like a good topic for ad-hoc
19:39:58 <peluse> yeah, I'd say 6
19:39:58 <cschwede> notmyname: i’m fine with a ad-hoc for this, but then we should make sure it get’s covered by a few cores
19:40:10 <notmyname> ok
19:40:26 <acoles> sounds like goal will be to generate a list of ideas, ad-hoc session sounds good
19:40:32 <clayg> notmyname: it's pretty high for me - but I'd really like it to leverage some community participation - we have so much input from people who develop deploy and operate swift - be great to have some input from consumers beyond "I store the lolcatz" and "I upload the backups"
19:40:43 <notmyname> yeah
19:40:53 <notmyname> ok, next one
19:40:59 <notmyname> status of python-swiftclient
19:41:09 <notmyname> this is related, but separate, from the last one
19:41:10 <clayg> getting less terrible with every commit!
19:41:19 <acoles> clayg :)
19:41:35 <notmyname> I want to go over the current status (what's good, what's bad, etc) and make a set of goals for swiftclient
19:41:45 <mattoliverau> lol, this might need a session, so there is a defined end point to its dicsussions :P
19:41:51 <torgomatic> $ git mv swiftly python-swiftclient
19:42:05 <notmyname> swiftclient is often the first impression people have of swift, and frankly it's not great IMO
19:42:35 <notmyname> I'd rank this one pretty high. what do you think?
19:42:46 <mattoliverau> yeah, 8 or 9
19:42:50 <lpabon> agreed
19:42:54 <mattoliverau> needs to be talked about
19:43:24 <notmyname> acoles: peluse: clayg: ?
19:43:43 <acoles> notmyname: not great as in bugs or not great as in interface?
19:44:17 <notmyname> acoles: interface mostly. also not great from a maintenance point of view, although that's not often seen by users
19:44:24 <clayg> yeah i get bummed out sometimes when I find broke stuff in swiftclient; but i try to just file bugs or fix things
19:44:32 <notmyname> acoles: where interface includes performance
19:44:34 <clayg> I don't really understand what we can do except make it better
19:44:48 <peluse> I don't have a huge amount of experience with it but always willing to listen/comment...
19:44:52 <clayg> honestly my biggest rip is still pbr
19:45:06 * peluse thought torgotmatic solve it with his earlier git command already
19:45:08 <clayg> like everytime someone says "I tried to install swiftlcient and pbr" my blood boils
19:45:32 <notmyname> ok, I'll put it down as an 8
19:45:36 <notmyname> next one
19:45:38 <notmyname> swift-on-file
19:45:46 <notmyname> this is tdasilva's stackforge project
19:45:54 <tdasilva> this one we were just looking for some open time in case it is available
19:45:59 <notmyname> makes swift work on top of external durable filesystems
19:46:30 <mattoliverau> I'd love to hear about it
19:46:31 <notmyname> yeah, I'd rank it lower since it's not the codebase we officially manage. but supporting it is good
19:46:59 <tdasilva> it will be a good opportunity to meet with other folks to are interested on the project, so whatever time we can get we appreciate
19:47:08 <notmyname> thoughts? above or below queues in swift? ;-)
19:47:16 <peluse> above
19:47:44 <clayg> above - there's like a whole thing that works - imporoving what we've got is ++ on new and shiny most of the time in my book
19:47:51 <notmyname> cool
19:47:59 <acoles> above
19:48:03 * notmyname lowers priority for queues
19:48:08 <notmyname> let's do it :-)
19:48:18 <clayg> when we get swift on file on fuse on rados then we win right?
19:48:38 <notmyname> clayg: something like that. but only when rados is running on netapps backed by tape, right?
19:48:45 <notmyname> next up
19:48:50 <clayg> or s3 - we should throw aws a bone too
19:48:52 <notmyname> encryption in swift
19:48:58 <torgomatic> clayg: especially then if you make rados store the file in the original Swift cluster, because then you get infinite free storage
19:49:03 <notmyname> on dis-encryption
19:49:10 <notmyname> on-disk encryption
19:49:17 <torgomatic> Swift -> FS -> FUSE -> RADOS -> start again
19:49:20 <clayg> DOCKER!
19:49:25 <notmyname> ok ok ok
19:49:26 <torgomatic> lol
19:49:26 <peluse> that was something I was interested in hearing about if anyone who is part of the effrt that Sam started to doc is around/wanting to discuss
19:49:30 <clayg> oh... i meant ENCRYPTION!
19:49:33 <clayg> let's do it!
19:49:34 <mattoliverau> needs a session, looking at the spec coments, this needs discussion
19:49:51 <notmyname> yeah, it's a touchy topic that a lot of people get really excited about
19:49:56 <notmyname> I think it needs a session
19:50:01 <torgomatic> seems like you mention crypto and all the scope creepers come out of the woodwork
19:50:15 <notmyname> ok, 3 more (quickly)
19:50:17 <peluse> oooh oooh, and then we can....
19:50:18 <clayg> there has got to be minecraft meme there
19:50:21 <notmyname> torgomatic: seagulls
19:50:21 <torgomatic> you're just sitting there and you hear sssssssssssssSSSSSSSSSSSSSSo, we also need X!
19:50:24 <torgomatic> and then your scope explodes
19:50:27 <notmyname> :-)
19:50:43 <notmyname> ok, migration middleware from gvernik
19:50:59 * notmyname is sad it's not landed yet
19:51:08 <peluse> seems like we need a forcing function to get that landed
19:51:13 * notmyname has also not put a +2 on it and is part of the problem ;-)
19:51:19 <notmyname> peluse: no kidding
19:51:20 <peluse> like lock some of us in a room in Paris until its done
19:51:36 <clayg> http://cdn.meme.am/instances/500x/55541888.jpg
19:51:47 <zaitcev> I only looked at Gil's thing once months ago.
19:51:47 <notmyname> could that be done during the ad-hoc time? or does it require a session?
19:52:19 <tdasilva> zaitcev: it's nice, you should look again :-)
19:52:28 <peluse> i do think its a must but ad-hoc is probably OK and there should a goal to get 2 cores signed up to attend and get all their questions answered so we can merge it
19:52:46 <peluse> and I'll volunteer to be one of them...
19:53:07 <acoles> so, are we all planning to be at the ad-hoc? can we structure it at all?
19:53:07 <mattoliverau> lets give it a mid range score, it might get a tail end session :)
19:53:23 <notmyname> acoles: yeah, I think we should all be there
19:53:27 <clayg> peluse: what's the hold up - if it's awesome lets merge it - or if it's just middleware get it out on the githubs and referenced in the associated projects till we ready to eat it - or it's baked eough for core?
19:53:29 <notmyname> mattoliverau: yup
19:53:50 <notmyname> two more to review in 7 minutes
19:53:53 <peluse> clayg, only hold up for me is a piss poor excuse of not having taken the time to go through it in detail
19:53:54 <notmyname> next
19:53:59 <notmyname> durability simulator
19:54:04 <kota_> This is something we disscussed in Hackthon.
19:54:14 <clayg> if we could only *simulate* durability then we wouldn't acctually need it!
19:54:18 <notmyname> yeah. kota_ and cschwede are kinda leading this one
19:54:19 <notmyname> " Discuss how swift durability should be calculated with showing some our sample tool design and how to make such tools for system architects to calculate their own  durability when building Object Strage System"
19:54:27 <notmyname> I vote for ad-hoc
19:54:46 <peluse> sounds good
19:54:47 <cschwede> fine with me
19:54:54 <notmyname> ok
19:54:57 <acoles> peluse: clayg: i would be +2 on migration but got kinda involved so i'm hoping other cores will bless it
19:55:00 <notmyname> kota_: are you ok with that?
19:55:29 <kota_> ok but I'd like to get some feedback also ops
19:55:47 <notmyname> last up
19:55:49 <notmyname> ops session
19:56:00 <notmyname> in the past, we've had a session for ops feedback
19:56:05 <notmyname> either we schedule this or we don't
19:56:11 <notmyname> no ad-hoc for this one
19:56:22 <notmyname> there is an "ops summit" or track at the summit
19:56:41 <notmyname> so we could punt to there, but that will be more general for all openstack (read: nova/neutron)
19:56:49 <mattoliverau> probably a good one to advertise, if no one turns up we could talk about app dev support for those ops :)
19:56:51 <tdasilva> was it beneficial at the atlanta summit?
19:56:51 <notmyname> so do we want a session for just swift feedback?
19:57:24 * tdasilva wasn't there, but thinks it is always a good idea to hear how people are using software in the real-world
19:57:24 <clayg> notmyname: seeing as how this is the first summit in euro - could turn up some interesting deployers we've not previously had a chance to talk to face to face?
19:57:35 <clayg> I remember atlanta was not so good ops-session, hk was quite good
19:57:41 <notmyname> tdasilva: clayg ++ to both
19:58:25 <notmyname> cool, let's do it
19:58:36 <mattoliverau> lets shedule one then.. if its quiet we can always talk about a ad-hoc topic
19:58:38 <notmyname> awesome, we got through them all
19:58:39 <notmyname> thanks!
19:58:52 <mattoliverau> just in time :)
19:58:58 <notmyname> I'll work on scheduling these and then push the schedule
19:59:05 <notmyname> before tuesday :-)
19:59:13 <clayg> ... and my devstack is running!
19:59:13 <mattoliverau> Cool, thanks notmyname
19:59:14 <tdasilva> notmyname: thanks!
19:59:16 <notmyname> thanks everyone for coming and participating!
19:59:20 <notmyname> #endmeeting