21:00:23 <notmyname> #startmeeting swift
21:00:24 <openstack> Meeting started Wed May 31 21:00:23 2017 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:27 <openstack> The meeting name has been set to 'swift'
21:00:28 <timburke> yay!
21:00:31 <notmyname> who's here for the swift team meeting?
21:00:33 <cschwede_> o/
21:00:36 <mattoliverau> o/
21:00:42 <clayg> yo yo yo
21:00:44 <rledisez> o/
21:00:47 <jeffli> o/
21:00:49 <kota_> hi
21:01:07 <m_kazuhiro> o/
21:01:09 <tdasilva> hello
21:01:16 <joeljwright> 0/
21:01:20 <mathiasb> o/
21:01:26 <acoles> hi
21:01:42 <notmyname> I feel like I just talked to half of you ;-)
21:01:48 <mattoliverau> Lol
21:01:51 <notmyname> jeffli: were you aware of the swift meeting that was 14 hours ago?
21:02:08 <notmyname> jeffli: probably a much better meeting time for your time zone :-)
21:02:19 <notmyname> anyway, that's one of the topics for *this* meeting today
21:02:28 <jeffli> yeah. but I had an unexpected meeting at that time.
21:02:34 <notmyname> me too!
21:02:39 <notmyname> actually, no. I expected it
21:03:10 <notmyname> meeting agenda page is...
21:03:12 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:23 <tdasilva> notmyname: you had conflicts meetings at midnight?
21:03:30 <notmyname> yeah. sleep ;-)
21:03:43 <notmyname> also video games
21:03:45 <joeljwright> pfft, sleep
21:03:48 <tdasilva> lol
21:03:59 <notmyname> there's a few things to go over in this meeting today, so let's get started
21:04:09 <notmyname> #topic last meeting follow-ups
21:04:30 <notmyname> ok, meta comment: "this meeting" "next meeting" and "last meeting" are now confusing
21:04:42 <clayg> har har
21:04:44 <notmyname> personally, I do not want to have a "main" meeting and "alternate" meeting
21:04:56 <notmyname> so I've been referring to them as the 0700 meeting and the 2100 meeting
21:05:04 <notmyname> (this is the 2100 meeting)
21:05:16 <notmyname> ok, so last 2100 meeting follow-ups
21:05:28 <clayg> ^ nice
21:05:45 <notmyname> again, no status updates on writing things down for the pike goals. but I'll keep it on the agenda to keep guilting myself about it
21:06:15 <notmyname> rledisez: last week you promised charts and graphs about memory consuption. did you and/or jeffli get a chance to work on that?
21:06:27 <acoles> notmyname: I think I promised you a patch on the uwsgi goal
21:06:36 <acoles> notmyname: but I haven't done it ... yet
21:06:37 <rledisez> notmyname: not on my side, we were off most of the week
21:06:37 <clayg> i promise nothing
21:06:42 <rledisez> notmyname: for next we should have them
21:06:43 <notmyname> rledisez: ..and a mailing list discussion
21:06:45 <clayg> rledisez: that's the ticket!
21:06:54 <notmyname> great, thanks
21:06:58 <notmyname> acoles: ok :-)
21:07:06 <jeffli> me neither
21:07:17 <rledisez> notmyname: same for mailing discussion, we'll start it by the end of this week
21:07:46 <notmyname> the ML discussion was the share that memory info (and the related discussion about which LOSF scheme to use), right?
21:08:08 <rledisez> yes, so that anyone can follow progression and choices and give insight
21:08:20 <notmyname> ok, perfect
21:08:28 <clayg> so perfect
21:08:32 <notmyname> I'll look for that ML thread from rledisez and jeffli this week
21:08:34 <clayg> rledisez: is a hero
21:08:37 <notmyname> please let me know if you need any help on it
21:08:40 <clayg> jeffli: is a hero
21:08:56 <mattoliverau> Yay to heros
21:09:01 <notmyname> ok, next up
21:09:02 <clayg> notmyname: is a facilitator of global communication
21:09:22 <notmyname> patch 466255 from tdasilva and cschwede_
21:09:22 <patchbot> https://review.openstack.org/#/c/466255/ - swift - Make mount_check option usable in containerized en...
21:09:28 * clayg hi-five's mattoliverau for assistance with the running commentary
21:09:59 <notmyname> and we were waiting for comments from cschwede_
21:10:11 <cschwede_> uhm, what do you want to hear?
21:10:14 <notmyname> ...which it looks like we have?
21:10:33 <mattoliverau> clayg: it's you and me buddy
21:10:43 <notmyname> there was one question about the re-instroduction of the lstat() call?
21:11:13 <notmyname> not that the comment needs to be updated, but are we ok with the additional call?
21:11:15 <cschwede_> well, it's adding one lstat, but then it's only happening when you have an unmounted or failed disk
21:11:45 <cschwede_> it should not happen when you're running outside containers with healthy disks
21:12:09 <notmyname> I like "the normal case is unaffected"
21:12:38 <notmyname> so clayg already had a +2 on it
21:12:45 <notmyname> and IIRC is still good with it
21:12:47 <cschwede_> right, normal usecases should'nt be affected at all (hopefully?)
21:13:04 <notmyname> tdasilva: can you please remove your -2 cork?
21:13:21 <notmyname> zaitcev has a +1
21:13:31 <tdasilva> notmyname: sure
21:13:32 <notmyname> so we need another core to review it (zaitcev or otherwise)
21:13:49 <cschwede_> i mean if someone has a better idea for containers, i'm happy to hear about it - i didn't see one so far
21:13:49 <notmyname> well, the big question is "were the concerns over the stat call addressed?"
21:14:29 <cschwede_> clayg? ^^
21:15:33 <tdasilva> clayg: cschwede_: is there a more 'elegant' solution? the bug clayg linked seemed to detail a better way to solve this
21:15:49 <tdasilva> so maybe we could have a short term and long term solution?
21:16:06 <tdasilva> I know clayg was also concerned about doing things just for containers
21:16:48 <clayg> I think mostly the stat syscall (which returns false for everyone except cschwede_'s containers) will mostly be cached/quick - I wouldn't worry about it if I thought there was no way solve the use-case with out it
21:17:10 <cschwede_> well, as written in the comments - doing stats has some benefits, because it detects broken disks that are still mounted (probably not always, but at least sometimes)
21:17:58 <notmyname> the docstring implies that if we add the lstat() back in, we might as well use the python version of it instead of our own (but I haven't looked at python's in a long time)
21:18:11 <clayg> tdasilva: not worried about "doing things just for containers" - worried about "trying to do the *right* thing being slower than just 'doing the first obvious thing that seems to work for containers' (and also then that slowness causing contempt or alienating potential contributions)"
21:18:26 <cschwede_> no, that's different afaict - that's another lstat in "normal" cases iirc
21:18:33 <cschwede_> notmyname: ^^
21:18:34 <notmyname> cschwede_: ah ok
21:19:17 <notmyname> ok, so for this meeting, we've got it sorted, and we need another reviewer. shall we ping zaitcev about it? or does someone else want to volunteer?
21:19:34 <tdasilva> o/
21:19:45 <notmyname> tdasilva: thanks
21:20:14 <cschwede_> thx Thiago!
21:21:29 <notmyname> ok, last thing in the follow-up section is "composite ring"
21:21:32 <notmyname> and that's landed!
21:21:53 <mattoliverau> \o/
21:22:22 <kota_> \o/
21:22:28 <notmyname> #topic 0700 meeting update
21:22:42 <notmyname> all right. report on the first 0700 meeting
21:22:54 <tdasilva> notmyname: quick question for kota_ and other folks working on composite rings
21:23:01 <tdasilva> what's left for the global EC work?
21:23:03 <notmyname> yeah, what's uo?
21:23:03 <mattoliverau> mahatic: did a great job chairing
21:23:17 <tdasilva> just trying to catch up
21:23:18 <notmyname> mahatic: thanks for chairing
21:23:38 <notmyname> tdasilva: follow-ups on https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:23:43 <acoles> tdasilva: IIRC there are some follow up patches e.g. doc changes
21:23:51 <notmyname> here's a brief summary of the earlier meeting
21:24:00 <kota_> tdasilva: true for acoles
21:24:03 <notmyname> #link http://eavesdrop.openstack.org/meetings/swift/2017/swift.2017-05-31-07.00.html
21:24:25 <notmyname> the next 0700 meeting will be on june 14. acoles will chair
21:24:32 <acoles> tdasilva: longer term there are some EC GET path optimisations we may want to make
21:24:43 <acoles> to do with duplicate frags
21:25:30 <kota_> tdasilva: and, making CLI binary for composite ring builder may be needed too
21:25:33 <notmyname> there are lots of EC reconstructor optimizations we "may want to make" (regardless of "global ec" or not) ;-)
21:25:34 * acoles apparently has first nick by alphabetical order
21:26:23 <notmyname> ok, for meeting transition follow-ups...
21:26:32 <tdasilva> acoles, kota_ thanks!
21:26:40 <notmyname> mattoliverau is going to look at https://review.openstack.org/#/c/289664/ and roll in clayg's comments
21:26:40 <patchbot> patch 289664 - swift - Make eventlet.tpool's thread count configurable in...
21:26:41 <mattoliverau> That's why I'm changing my nick to zzzmattoliverau :p
21:27:02 <notmyname> and we need to bring up https://review.openstack.org/#/c/371150/ in this meeting now
21:27:03 <patchbot> patch 371150 - swift - Return 404 on a GET if tombstone is newer
21:27:25 <tdasilva> notmyname: i'm almost done sending another patchset for that
21:27:31 <notmyname> tdasilva: great!
21:27:56 <clayg> tdasilva: that's awesome
21:27:57 <notmyname> yeah, the 0700 meeting was like "it hasn't been touched in a month, needs to get in, but everyone who's looked at it is asleep" ;-)
21:28:17 <timburke> i'd like to add https://review.openstack.org/#/c/302494/ to the list of priority patches that haven't had movement in a month. the only change has been to break out https://review.openstack.org/#/c/464084/ as a separate patch since it's a bit of a change in how the replicator works
21:28:18 <patchbot> patch 302494 - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:28:20 <patchbot> patch 464084 - swift - Apply remote metadata in _handle_sync_response
21:29:03 <notmyname> adjusting meeting topic to reflect the converstation
21:29:13 <notmyname> #topic patches that need attention
21:29:40 <kota_> notmyname: I'll be back at https://review.openstack.org/#/c/302494/ in this week
21:29:41 <notmyname> for https://review.openstack.org/#/c/302494/ we need other reviewers
21:29:41 <patchbot> patch 302494 - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:29:42 <patchbot> patch 302494 - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:29:48 <notmyname> kota_: thanks :-)
21:30:01 <joeljwright> I'd love people to review https://review.openstack.org/#/c/365371/
21:30:01 <patchbot> patch 365371 - swift - Add Preamble and Postamble to SLO and SegmentedIte...
21:30:26 <notmyname> hang on hang on. we've got several patches to discuss
21:30:34 <joeljwright> sorry
21:30:37 <joeljwright> :D
21:30:40 <notmyname> first patch 302494 then path 365371
21:30:41 <patchbot> https://review.openstack.org/#/c/302494/ - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:31:19 <notmyname> for https://review.openstack.org/#/c/302494/ it's been split out ( timburke: because it changes the behavior?) and needs reviews
21:31:20 <patchbot> patch 302494 - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:31:32 <notmyname> timburke: should we wait until we get reviews on the dependency from kota_?
21:31:33 <clayg> notmyname: I think timburke and kota_ can tell us when that one is ready
21:31:45 <clayg> timburke: may already know it's done?
21:32:05 <clayg> so someone could race kota through the first sanity review - or sweep with +A if he's already commited?
21:32:26 <clayg> IIRC it's one of those must fix things - the question is in how much follow will be needed once we grok the issue and land the damn thing
21:33:13 <kota_> clayg: correct, https://review.openstack.org/#/c/302494/ is what we must fix and the other is optional improvement IIRC
21:33:14 <patchbot> patch 302494 - swift - Sync metadata in 'rsync_then_merge' in db_replicator
21:33:14 <notmyname> kota_: timburke: how does that sound to you?
21:33:21 <clayg> keep it tight that's always my suggestion
21:34:02 <kota_> probably, I will be able to give my +2 for the first one in near future
21:34:08 <notmyname> great
21:34:15 <timburke> i'm rather certain the first one is good to go -- i've just meddled with it enough that i'm not sure i'm an unbiased reviewer. the follow-up is a bit more of an open question, but should be ready to merge if we want it
21:34:32 <notmyname> kk
21:34:33 <kota_> on the second one, I'm not entierly sure if it's *good* thing for us
21:34:40 <clayg> timburke: second set of eyes is good always - too easy to get code-blind
21:34:58 <clayg> kota_: timburke: let's focus on landing the critical fix - follow up is... follow up
21:35:02 <notmyname> let's focus on the first one fir this week
21:35:04 <notmyname> yeah :-)
21:35:14 <timburke> and clayg's thought about keeping it tight is why i split it into two changes
21:35:20 <kota_> yup, will do at least this week.
21:35:22 <clayg> timburke: is a hero!
21:35:24 <notmyname> ok, joeljwright's patch 365371
21:35:25 <patchbot> https://review.openstack.org/#/c/365371/ - swift - Add Preamble and Postamble to SLO and SegmentedIte...
21:35:50 <notmyname> this is new functionality to swift. offers some pretty interesting stuff (that joeljwright wants to use in his cluster)
21:36:05 <joeljwright> timburke has been looking at it and torgomatic expressed some interest a while back
21:36:18 <notmyname> IIRC this enables being able to download tar files from swift that are dynamically composed
21:36:54 <joeljwright> that's certainly my use case - avoiding storing lots of tiny objects that only make sense combined with actual data
21:37:33 <notmyname> but in this case you'll be storing the tiny files and then make a tarfile manifest to download them all at once?
21:37:56 <joeljwright> all the tar specific data would be base64 encodeed and stored in the manifest
21:38:13 <clayg> notmyname: I think joeljwright was contrarsting with storing the pre-amble and post-amble *as* objects - then preamble postamble slo is just... a slo
21:38:20 <joeljwright> as pre/postambles to the objects
21:38:24 <notmyname> oh, I see. instead of making individual object of the tar metadata, you dynamically build it
21:38:27 <notmyname> yeah
21:38:44 <cschwede_> me totally wants this - currently doing something similar for backups...
21:38:57 <notmyname> cschwede_: does that mean you could review it?
21:38:59 <notmyname> :-)
21:39:02 <cschwede_> sure!
21:39:02 <joeljwright> :)
21:39:05 <notmyname> nice!
21:39:05 <joeljwright> thanks!
21:39:16 <clayg> joeljwright: is there any write up on the API?
21:39:41 <joeljwright> it's all in the SLO docstring atm
21:39:50 <clayg> the use-case seems more like "instead of storing some SLO segments as objects (or a range of an object) I want them to be data written directly into the manifest"
21:40:14 * tdasilva wonders if gnocchi driver could use this
21:40:39 <joeljwright> clayg: yes that's the use-case
21:40:50 <clayg> joeljwright: maybe a script/snippet that says "here's three examples of different things (two useful one crayz) how you use this new api capability for awesomeness success and winning"
21:41:11 <joeljwright> clayg: I'll have a think
21:41:19 <clayg> joeljwright: so is it *pre/post*amble - or just add inline object support to SLO segments
21:41:36 <notmyname> cschwede_: when you look at it, please keep an eye out for what would be good docs :-)
21:41:37 <joeljwright> timburke already created a gist to make tarballs :) Now I just need other examples!
21:41:42 <notmyname> oh cool
21:41:45 <clayg> notmyname: timburke: do we just recheck to make the doc build refresh?
21:41:46 <timburke> https://gist.github.com/tipabu/5c96175d26fac1ec1771b5d01c6573a7
21:41:53 <timburke> clayg: ya
21:41:56 <notmyname> that would be nice to include in the tree then
21:42:13 <clayg> notmyname: the code snippet?
21:42:23 <timburke> notmyname: i believe joeljwright's intention is to write a new middleware to do exactly that :-)
21:42:24 <notmyname> oh, I said that before I clicked the link ;-)
21:42:31 <joeljwright> I modified timburke's example to use the python tarfile lib: https://gist.github.com/joel-wright/b8282f689ff1a622c035cd2741e8e265
21:42:35 <clayg> notmyname: maybe in the doc/prose - but it could also just go in a gist referenced in the review
21:42:49 <notmyname> no, I don't want to link to timburke's gists in the swift source tree
21:42:52 <timburke> well aren't *we* fancy :P
21:42:59 <joeljwright> :D
21:43:24 <notmyname> ok, we've got a plan on this patch for this week
21:43:30 <timburke> notmyname: you do enough linking to my gists as it is
21:43:36 <notmyname> a couple of others I wanted to bring up...
21:43:44 <notmyname> first, https://review.openstack.org/#/c/435152/
21:43:45 <patchbot> patch 435152 - swift - Do not sync suffixes when remote rejects reconstru... (MERGED)
21:44:18 <clayg> oh, every segment needs it's own pre-amble post amble
21:44:18 <notmyname> I did some backport releases this week, and I noticed that although we backported this patch and have now (or soon) released it, we haven't actually released this on master. it's post-2.14.0
21:44:20 <clayg> interesting...
21:44:35 <notmyname> which raises the question of tagging another swift release
21:44:49 <notmyname> which is totally fine. or not. what do you think?
21:44:52 <clayg> I had imagined [{'preabmle'}, {'object1'}, {'object2'}, {'postamble'}]
21:45:02 <notmyname> seems that if it's important enough to backport, it's important enough to cut a release for
21:45:13 <notmyname> but I'd like input from everyone else
21:45:24 <notmyname> what are your thoughts?
21:45:33 <timburke> clayg: yeah, i had a similar thought... in particular, i was reminded of things like data uris...
21:45:46 <clayg> but I could also imagine an api [{'blah1'}, {'object1'}, {'blah2'}, {'blah3'}, {'object2'}, {'blah4'}]
21:46:16 <timburke> certainly in the context of a tlo, having it in the object dict makes perfect sense
21:46:34 <acoles> notmyname: I hadn't realised we backported that
21:46:57 <notmyname> https://review.openstack.org/#/q/Ia72c407247e4525ef071a1728750850807ae8231,n,z
21:47:00 <notmyname> yep
21:47:02 <joeljwright> clayg: pre/postambles are optional and can be mixed in any combination for each object
21:47:16 <clayg> notmyname: i thought that was a minor optimization - also not understanding the backport (unlike the *other* suffix hashing *bug* which was both terrible *and* inefficient)
21:48:00 <clayg> joeljwright: but can I have a segment that is *just* a pre-post amble - like an "inline" segment instead of a segment that is referencing another object or a range of an object
21:48:18 <notmyname> clayg: acoles: ok. I'll let it sit for now
21:48:26 <clayg> notmyname: yeah I think it's weird that got backported - so what's the question?  it's done now right?
21:48:33 <clayg> :shipit: who cares
21:48:33 <notmyname> yeah, it's done
21:48:40 <acoles> notmyname: well we have a lot of new stuff recently landed so a release might  make sense soon
21:48:40 <joeljwright> Hmmmm, zero byte objects are allowed as segments if they have a pre/post amble
21:48:45 <notmyname> lol, you just described our backport policy ;-)
21:48:57 <notmyname> acoles: indeed, but I won't rush for it
21:49:11 <notmyname> ok, last patch on the agenda..
21:49:13 <notmyname> https://review.openstack.org/#/c/468105/
21:49:14 <patchbot> patch 468105 - swift - Require that known-bad EC schemes be deprecated
21:49:21 <notmyname> for clayg and timburke to bring up
21:49:36 <clayg> timburke: is definitely the hero here
21:49:48 <clayg> just the other day I logged into a lab cluster and noticed those messages being logged
21:50:11 <clayg> going to be really rough when I upgrade to the version of swift that makes your proxies not start - but hey - at least I'll %^&*ing fix my lab clusters!
21:50:17 <kota_> oic
21:50:18 * clayg so lazy
21:50:32 <notmyname> I definitely support preventing this known-bad config
21:50:56 <kota_> sounds good to me
21:50:58 <notmyname> timburke: do you have, off-hand, the releases of when we said it was deprecated?
21:51:31 <notmyname> just ocata?
21:51:38 <timburke> if i remember right, yeah
21:51:59 <notmyname> changelog has it there (2.13.0)
21:52:17 <timburke> we backported to newton, but that doesn't mean people upgraded
21:52:45 <notmyname> ok, so we need to check the deprecation policy. but if we land it now (ie "Pike" series), I think we'll be ok. IIRC the deprecation is to keep it as a warning for one openstack cycle and remove it in the next
21:53:22 <notmyname> however, this is also a Big Deal, and there's very little reason to leave that particular issue lurking for operators
21:53:25 <clayg> be nice if we had some cluster-assisted-policy-migration up in there
21:53:33 <timburke> yeah, i'm cool with landing it whenever -- i just wanted to be aggressive since that config harms durability
21:54:16 <clayg> well - it's worse if you have an old liberasurecode - at least now we 503 instead of corrupt data
21:54:19 <notmyname> "oh you lost all your data because you selected some parameters? we knew it was bad, but we still let you do that because we didn't warn people long enough" <<<--- a terrible terrible message and we shoudl feel bad if we do it
21:54:22 <acoles> notmyname: timburke is there any value in a half way step i.e. force the bad policy to be deprecated in the policy config sense, so that it becomes read only?
21:55:01 <clayg> oh i like that - instead of refusing to start just auto deprecate - noice
21:55:07 <acoles> otherwise we go from warning to no data, right?
21:55:19 <timburke> clayg: a plus, but how does that get handled in the reconstructor? do we go grab another frag, or just skip it and hope we have better luck later?
21:55:21 <clayg> people be like "where'd my policy go" - and we be like "ftfy"
21:55:24 <notmyname> yeah, that is a good idea. timburke, thoughts?
21:55:33 <clayg> timburke: yeah
21:56:00 <timburke> ...how would we handle single-policy deployments?
21:56:30 <notmyname> timburke: read-only
21:56:46 <clayg> notmyname: there is no such thing as a read-only policy
21:56:56 <timburke> no, just no-new-containers
21:57:00 <acoles> timburke: h, you mean you gotta have *one* policy not deprecated
21:57:10 <tdasilva> can't deprecate if you only have one policy, right?
21:57:21 <notmyname> yeah, sorry, if you only have one and it gets deprecated, things don't work
21:57:29 <notmyname> will the proxy just not start?
21:57:40 <notmyname> which is the same as what's proposed now
21:57:45 <notmyname> effectively
21:57:53 <acoles> I wonder if we can special case this though
21:58:06 <clayg> tdasilva: yeah I think if you do the checks in the right order it could still say "This policy is bad and it's deprecated now; I can't start unless you have at least one not-deprecated policy"
21:58:26 <clayg> still not *great* - but the whole idea is we're doing something - something mean - and the beatings will continue until your cluster configuration improves!
21:58:35 <notmyname> timburke: can you work through these questions in that patch this week?
21:58:37 <timburke> also, i'm not sure we'd really be doing operators any favors by hiding the issue -- you need to deal with this, and one of the first steps to dealing with it is to have a good, non-deprecated policy to migrate to
21:59:28 <notmyname> oh! one more note from the 0700 meeting. now that composite rings has landed, cschwede_ is unblocked on part power increase and will be moving forward on it again!
21:59:30 <acoles> timburke: +1 you need to make a good policy anyway to move on from this terrible place
21:59:31 <timburke> (also worth remembering: even with the policy deprecated, you'll *still* have new data being written with the bad config)
21:59:57 <notmyname> bah. we're at full time for the meeting
21:59:58 <clayg> womp womp
22:00:09 <timburke> that's a whole *other problem that needs addressing
22:00:22 <notmyname> ok, I'm trusting that timburke will keep thinking on this and type up some awesome code for it
22:00:25 <notmyname> :-)
22:00:34 <notmyname> thank you all for coming to this meeting
22:00:42 <mattoliverau> +1
22:00:44 <notmyname> and for about half of you, it's your second swift meeting in 24 hours!
22:00:59 <notmyname> thank you for your commitment to swift
22:01:03 <acoles> notmyname: it's great! two in a single day!
22:01:06 <notmyname> #endmeeting