21:00:25 <notmyname> #startmeeting swift
21:00:26 <openstack> Meeting started Wed Feb 10 21:00:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:29 <openstack> The meeting name has been set to 'swift'
21:00:30 <notmyname> who's here for the swift meeting?
21:00:33 <minwoob> o/
21:00:34 <mattoliverau> o/
21:00:34 <blmartin> o/
21:00:39 <kota_> o/
21:00:41 <cschwede> o/
21:00:45 <torgomatic> .
21:00:46 <sgundur> o/
21:00:55 <jrichli> here
21:01:09 * onovy 
21:01:23 <gmmaha> o/
21:01:43 <siva_krishnan> o/
21:01:45 <sarafraj> o/
21:01:46 <bjkeller> o/
21:01:51 <pdardeau> o/
21:01:54 <joeljwright> hey
21:01:56 <cutforth> o/
21:01:56 <acoles> hi
21:02:14 <notmyname> welcome, everyone
21:02:19 <notmyname> clayg: ping
21:02:29 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:32 <notmyname> agenda ^
21:02:49 <notmyname> a few things to go over this week
21:03:04 <notmyname> a couple of general things first
21:03:09 <notmyname> #topic general things
21:03:22 <notmyname> summit talk voting is open. so do that
21:03:30 <notmyname> #link https://www.openstack.org/summit/austin-2016/vote-for-speakers/
21:03:55 <notmyname> also, there's been some questions about releases for swiftclient and swift-bench
21:04:17 <notmyname> I'll work on getting those done before the hackathon (within the next 2 weeks)
21:04:53 <notmyname> and lastly, I've finished my summary of responses to the "what's going on in swift" questions I asked a few weeks ago
21:05:23 <notmyname> I sent it out to a few people, and assuming nobody comes back real soon with a "this is totally terrible", I'll publish that for the world to see
21:05:39 <notmyname> hopefully later today or tomorrow
21:06:02 <notmyname> #topic hackathon
21:06:21 <notmyname> the hackathon is coming up! have you got your plane tickets and passport yet?
21:06:34 <notmyname> #link https://etherpad.openstack.org/p/swift-hackathon-feb-2016
21:06:58 <notmyname> there is an etherpad to collect ideas to talk about in bristol
21:07:13 <notmyname> thank you for adding stuff :-)
21:07:27 <notmyname> any questions about the hackathon?
21:07:54 <clayg> ohai
21:08:43 <clayg> gah I don't *want* to vote on summit topics - I did *every* session last time and it took ---- FOREVAR
21:09:08 <notmyname> the votes are advisory to the track chairs
21:09:24 <clayg> lol - ORLY!?
21:09:30 <notmyname> so you can either say that it doesn't count or it's the way to make your voice heard. just depends on your perspective :-)
21:09:47 <mattoliverau> lol, and clayg if you don't do it, who will!
21:09:49 <clayg> oh gosh i need to read the hackathon
21:10:17 <joeljwright> clayg: I already volunteered you for a session…
21:10:25 <notmyname> heh
21:10:46 <clayg> FWIW my only plan is to take the much needed time away from work for upstream focus to merge fast-POST (bonus points if I get to reconstructor or concurrent gets changes)
21:10:49 <joeljwright> clayg: but only at the hackathon
21:11:43 <notmyname> sounds like a nice segue to talk about patches
21:11:55 <notmyname> #topic patches -- auditor bug
21:12:01 <notmyname> #link https://bugs.launchpad.net/swift/+bug/1183656
21:12:02 <openstack> Launchpad bug 1183656 in OpenStack Object Storage (swift) "object auditors don't finish" [High,Confirmed]
21:12:19 <notmyname> what's going on here?
21:12:20 <mattoliverau> clayg: I better get concurrent gets going again then.. especially before my life turns up side down :)
21:13:04 <notmyname> onovy: I belive you were looking into this bug?
21:13:13 <onovy> no? :)
21:13:18 <clayg> joeljwright: wat?  now I *really* better go read that eatherpad (thanks jrichli!)
21:13:30 <clayg> onovy: honesty is the best policy - notmyname can take it
21:13:34 <jrichli> clayg :p
21:13:58 <notmyname> hmm..ok then
21:14:04 <notmyname> I thought it was either onovy or peterlisak
21:14:16 <notmyname> but it seems I misremembered
21:14:17 <onovy> i think it's related to ionice
21:14:25 <onovy> "related" :)
21:14:29 <notmyname> but the point still stands that it's a bug that needs to be squashed
21:14:47 <notmyname> ok, so that leaves us with...
21:15:01 <notmyname> who can volunteer to work on a patch for this bug this week?
21:15:14 <notmyname> cschwede: interested?
21:15:15 <notmyname> :-)
21:15:19 <clayg> notmyname: wow you like went right out there for it - baller
21:15:30 <cschwede> notmyname: yup, just wanted to raise my hand
21:15:36 <notmyname> cschwede: awesome, thanks!
21:15:55 <clayg> cschwede: !!!! how you been doing man!  I think my schedule's been getting later - am I going to see you in bristol!?
21:16:44 <cschwede> clayg: :) of course, can’t wait to meeting all of you in Bristol!
21:16:54 <notmyname> yay
21:16:55 <notmyname> #topic patches -- in process functests with fast-POST
21:16:58 <notmyname> acoles: this is your topic
21:17:08 <notmyname> patch 274086
21:17:08 <patchbot> notmyname: https://review.openstack.org/#/c/274086/ - swift - Enable in-process func tests to optionally use fas...
21:17:23 <acoles> we discussed this last week - still need another +2 on that ^^
21:17:24 <notmyname> and patch 276823
21:17:24 <patchbot> notmyname: https://review.openstack.org/#/c/276823/ - openstack-infra/project-config - Add job gate-swift-tox-func-in-process-fast-post
21:17:34 <acoles> annd here's the gate change ^^
21:17:41 <acoles> notmyname: thanks for feeding the links :)
21:18:01 <acoles> I have been ultra-cautios with the gate change and made the tox-func-... job non-voting
21:18:02 <mattoliverau> I was going to look at the first one, sorry acoles. Conference had too many good talks.. will look at it today
21:18:08 <notmyname> mattoliverau: last week you said you'd look at it
21:18:10 <acoles> mattoliverau: thanks man!
21:18:13 <notmyname> mattoliverau: ah. thanks :-)
21:18:48 <notmyname> #topic patches -- rbac
21:18:53 <notmyname> patch 202411
21:18:54 <patchbot> notmyname: https://review.openstack.org/#/c/202411/ - swift - Add functional test for access control (RBAC) with...
21:18:59 <acoles> so nothing *should* fail but we'll let the gate runa few times then go back to voting, and imho we lose no coverage cos the regular func tests are still there
21:19:01 <notmyname> here's a quote from last week's meeting
21:19:04 <notmyname> "21:41:03 <notmyname> ok, so between torgomatic cschwede clayg and kota_, it *should* be either landed or have other patch sets by next week"
21:19:10 <clayg> hrrmm.. patch 274086 has two reviewers - I can think of *one* soltuion
21:19:10 <patchbot> clayg: https://review.openstack.org/#/c/274086/ - swift - Enable in-process func tests to optionally use fas...
21:19:34 <notmyname> so torgomatic cschwede clayg kota_, what's the status of the rbac patch? doesn't look like any activity in gerrit since last week
21:19:59 <torgomatic> welp, there's your status :|
21:20:16 <notmyname> well, maybe you've got something local :-)
21:20:18 * notmyname hopes
21:20:37 <torgomatic> I can come shrug at your desk if it helps
21:20:38 <kota_> sorry, I couldn't have a time to look at
21:21:04 <kota_> will see
21:21:20 <cschwede> notmyname: i had a look, but unfortunately didn’t make much progress :/ the list of expected test result is quite long, doesn’t make it easier to read
21:21:35 <clayg> notmyname: I'm *pretty* sure I have keystone working - but I honestly wasn't intending to look at the rbac tests again - I really am pretty sure if I do I'll want to push up another revision to address some of the stuff acoles already pointed out but couldn't bring himself to demand
21:21:45 <notmyname> cschwede: thanks
21:22:06 <acoles> fwiw ho_away 's patch adds a load of time to a test run, BUT less time than patch 277465 removed
21:22:07 <patchbot> acoles: https://review.openstack.org/#/c/277465/ - swift - Speed up functional testing (MERGED)
21:22:19 <notmyname> yeah, we talked about that in tokyo. it's a complicated set of test conditions. IIRC clayg was suggesting spot-checking and pattern matching to review
21:22:34 <clayg> acoles: two steps forward but only one step back sounds like progress!
21:22:42 <notmyname> progress!
21:22:57 <notmyname> cschwede: can I ping you about it at next weeks meeting?
21:23:07 <notmyname> (this rbac patch)
21:23:10 <clayg> acoles: also I'm not sure how much I care about func test run time?  It's been a long time since I was able to "wait" for a swift test run
21:23:20 <cschwede> i don’t feel comfortable about https://review.openstack.org/#/c/202411/20/test/functional/test_access_control.py - the list of expected returns
21:23:37 <cschwede> notmyname: sure, i’ll have another look at it. worst case is that i add only some comments
21:23:49 <notmyname> or that could be best case :-)
21:24:26 <acoles> clayg: yeah, its beyond 'watch and wait' but not long enough to do much else useful
21:25:05 <notmyname> go grab a pint at the windchester and wait for the whole test suite to finish running
21:25:30 <cschwede> i might bother acoles about the patch then ;)
21:25:36 <clayg> cschwede: wait which line?  You just don't like the whole idea of a data driven test matrix - and would prefer explicit behavior based tests with names - or you're ok with exahaustive matrix testing but want the format somewhat different?
21:26:35 <cschwede> clayg: the last; data driven is fine, but the format in this patch feels not familar (yet)
21:27:31 <acoles> we did discuss reformatting to something more readable, in Tokyo, IIRC
21:27:35 <notmyname> is ho_away here?
21:27:40 <clayg> poor ho_away
21:27:48 <ho_away> yep
21:27:52 <acoles> someone asserted that would be easy in emacs ;)
21:27:56 <notmyname> lol
21:27:59 <mattoliverau> yeah, using dictionaries so the fields are readable would be nice
21:28:14 <clayg> I think maybe he's not clear on exactly what formatting would be most appreciated (I'm not even sure we *know* what format would be ideal)
21:28:29 <cschwede> he, true!
21:28:32 <clayg> mattoliverau: acoles: +1 I think that was what folks said
21:29:00 <ho_away> clayg: yeah, exactly :-)
21:29:15 <notmyname> I'll bet ho_away would be interested in seeing your format bikeshed^W great ideas as a follow on ;-)
21:29:24 <notmyname> (was that too snarky?)
21:29:39 <notmyname> (it had a winky face. that makes it ok, right?)
21:30:00 <clayg> notmyname: that is an EXCELLENT point
21:30:07 <mattoliverau> winky face makes everything ok
21:30:09 <clayg> notmyname: winky face makes everything ok
21:30:15 <clayg> mattoliverau: JINX!
21:30:25 <acoles> so TBH I did not press ho_away too hard on the format because without other reviewers its maybe wasted effort, but it would be nice
21:30:28 * mattoliverau thinks damn, cause he can't talk
21:31:04 <clayg> mattoliverau: you get so many cool points if you can continue the rest of the meeting by "mimeing" your input
21:31:39 <notmyname> I sympathize with what cschwede said. the format of the tests isn't familiar yet. not that it's inherently bad
21:31:45 <clayg> #X$%^U it - let's merge it and file a bug to clean it up with an example of what we like?
21:32:03 <clayg> tag it low-hanging-fruit for the faries
21:32:15 <clayg> they LOVE that mechanical len/pep8/assertEqual crap anyway
21:32:16 <cschwede> clayg: yep, that was my idea as well, since there is already one +2 from acoles
21:32:29 <clayg> cschwede: do eeeet!  notmyname is right!
21:32:51 <clayg> cschwede: well... think hard about what format might be better and open the bug too - then DOOOO EEEET
21:32:58 <notmyname> :-)
21:33:36 <notmyname> cool. there's a plan and expected resolution Real Soon Now
21:33:44 <notmyname> #topic patches -- pyeclib version migration
21:33:46 <acoles> emacs will save us
21:33:54 <notmyname> acoles: thanks for adding this one
21:33:55 <ho_away> all: sorry & thanks for your help
21:34:08 <notmyname> ho_away: thanks for sticking with it for so long!
21:34:36 <notmyname> so the original pyeclib plan was this
21:35:04 <notmyname> update to 1.0.7 because of migration reasons (mostly with -infra reasons), then jump to 1.1.1
21:35:10 <notmyname> we did the first part
21:35:26 <notmyname> and now we're at 1.0.8 and there's an upstream 1.2.0
21:35:40 * onovy have simple question: if pyeclib is only for swift, what is reason for using older version than newest?
21:35:42 <notmyname> the final step in all of that was to then move the repos into the openstack namespace
21:36:26 <notmyname> onovy: IMO, we should go all the way (but the bump to 1.0.8 doesn't hurt anything)
21:36:50 <onovy> yep. i don't have problem to package 1.2.0 in debian (already done it, not uploaded yet)
21:37:03 <onovy> and it was simple, so others distro will not have any problems too
21:37:14 <onovy> (imho)
21:37:15 <clayg> onovy: i've been fighting liberasure packaging most of the day yesterday?
21:37:22 <clayg> and I think I only got 1.1.0
21:37:25 <notmyname> onovy: ah! you're the one who did the bump to 1.0.8 :-)
21:37:30 <onovy> notmyname: yes :)
21:37:45 <clayg> oh that's liberasure tho - I don't know yet what pyeclib i'm going to package today
21:37:51 <onovy> clayg: clayg liberasure 1.1.0 is newest
21:37:57 <clayg> *phew*
21:38:04 <notmyname> clayg: you aren't packaging the latest from VCS? wow.
21:38:13 <clayg> onovy: I thought zigo did all the debian openstack packaging - does he have HELP!?
21:38:19 <notmyname> ;-)   <--- winky face makes it all ok
21:38:29 <clayg> notmyname: no no i was - i think - onovy says i'm golden
21:38:32 <onovy> clayg: yep, i'm doing swift packages
21:38:41 <notmyname> clayg: zigo isn't doing it anymore. right onovy?
21:38:43 <adis> da li ima neko ovdje iz Bosne za razgovor
21:38:53 <adis> bilo ko .neka se javi
21:38:54 <adis> ??
21:38:58 <clayg> ???
21:39:06 <onovy> notmyname: zigo is working on it too
21:39:33 <onovy> adis: a ga la mo ne to vyra?
21:39:46 <notmyname> onovy: ah ok
21:40:04 <onovy> notmyname: os packages are team maintained in debian
21:40:10 <notmyname> got it
21:40:12 <clayg> adis: govoriti o openstack hitri ?
21:40:42 * notmyname feels like he has irc dysphasia
21:41:08 <notmyname> so let's continue the pyeclib upgrade with 1.2.0. sound reasonable to everyone?
21:41:08 <clayg> notmyname: so... version "migration" - what was the question/notice exactly?
21:41:23 <clayg> notmyname: it has a bigger number - why do we even need to discuss it ;)
21:41:30 <notmyname> yeah, that's exactly what I was about to ask
21:41:31 <onovy> +1 for 1.2.0 version. don't see any cons here
21:41:45 <clayg> lol
21:41:46 <notmyname> acoles: did you have something else specific on this? or just the "what's going on?"
21:42:32 <onovy> and what about migration to os-infra?
21:43:01 <notmyname> onovy: I don't have anything there except "yup. that's the plan"
21:43:24 <onovy> ok, let's do it
21:43:26 <acoles> well mainly what's going on and when do we move up again? does 1.0.8 have everything required to use the liberasurecode-rs-vand?
21:43:38 <clayg> "to" os-infra - or for the package/source/bitbucket
21:43:55 <clayg> acoles: in my experience 1.0.8 was sufficient
21:43:55 <notmyname> clayg: in the openstack/* namespace (instead of bitbucket)
21:44:03 <notmyname> no I don't think 1.0.8 is sufficient
21:44:05 <acoles> clayg: k. thanks
21:44:08 <acoles> oh
21:44:12 <notmyname> it still has the liberasurecode bundling
21:44:24 <notmyname> that's why I think we need 1.2.0 (from what I see of the pyeclib changelong)
21:44:38 <clayg> notmyname: it has what now?  i think 1.0.8 requires liberasure-dev to install
21:44:50 <clayg> what?  rly?
21:44:56 <onovy> exactly in debian pyeclib don't have liberasure bundling, becuase it can be disabled on "configure"
21:45:03 <clayg> where is tsg he's the only one that knows how this works
21:45:25 <onovy> so pyeclib package need liberasure package, it doesn't work without it
21:45:38 <onovy> clayg: i know it too :)
21:45:42 <clayg> onovy: the way that god intended packages to work
21:45:47 <notmyname> which is why the move to openstack/* is the goal. so not only tsg knows of it and can patch it :-)
21:45:58 <onovy> pyeclib <1.2.0 have option "disable erasure bundling"
21:46:06 <onovy> *liberasure bundling
21:46:19 <onovy> 1.2.0 don't have liberasure at all
21:46:23 <notmyname> ah ok. option to disable it. and 1.2.0 fully removes it
21:46:26 <clayg> onovy: wtf is liberasure "bundling" why is that that i don't even?
21:46:27 <notmyname> onovy: thanks
21:46:47 <onovy> clayg: it uses liberasure lib from pyeclib repo
21:47:07 <notmyname> clayg: that was what we didn't like about the earlier versions (we == anyone doing packaging). the pyeclib setup.py was downloading/installing the c lib
21:47:30 <onovy> clayg: https://bitbucket.org/kmgreen2/pyeclib/src/b9140f9273655691812d8cc9c4e56da8a59ffd06/src/c?at=v1.1.1
21:47:33 <clayg> notmyname: not anywhere anyone was packinging it wasn't - everyone worked around it
21:47:48 <acoles> ok, i admit i am confused and stupid, but without liberasurecode how does liberasurecode-vs-rand work? or is the key word here "bundling"? what am i missing?
21:48:03 <onovy> acoles: pyeclib have dependency
21:48:07 <onovy> it needs liberasure
21:48:22 <onovy> but older version had this version "distributed together"
21:48:27 <onovy> *this deps
21:48:34 <kota_> liberasurecode-rs-rand bundled in liberasurecode
21:49:00 <onovy> kota_: liberasure-rs-rand is just one EC inside liberasurecode lib
21:49:01 <notmyname> http://d.not.mn/lca2016_ec_in_swift.pdf  <-- 5th slide from the bottom ;-)
21:49:03 <kota_> and it expected to be installed via os packaging
21:49:11 <kota_> os packaging repo
21:49:12 <acoles> oh, so what notmyname said "the pyeclib setup.py was downloading/installing the c lib" <- 1.2.0 stops doing this?
21:49:17 <kota_> or by hand, in 1.2.0
21:49:19 <onovy> acoles: yep
21:49:44 <onovy> acoles: https://bitbucket.org/kmgreen2/pyeclib/src/19c99357839b0b95053632f303c1c4fab5408450/ChangeLog?fileviewer=file-view-default#ChangeLog-4
21:49:45 <notmyname> acoles: correct. and 1.0.7(?)->1.1.1 had an option to disable it
21:50:06 <kota_> older pyeclib repo has tar ball in inside.
21:50:17 <kota_> liberasurecode tar ball
21:50:24 <onovy> yes, here: https://bitbucket.org/kmgreen2/pyeclib/src/b9140f9273655691812d8cc9c4e56da8a59ffd06/src/c/
21:51:24 <acoles> ok thanks everyone. so 1.0.8 brings us liberasurecode_rs_vand, 1.2.0 decouples the install
21:51:30 <notmyname> ya
21:51:40 <onovy> this option: --install-liberasurecode=no
21:51:41 <notmyname> summary is pyeclib 1.2.0 is better than the earlier versions and that's what we should use in swift
21:51:49 <onovy> notmyname: +1 :)
21:51:53 <notmyname> everyone agree? any more questions on that?
21:51:59 <mattoliverau> +1
21:52:03 <clayg> onovy: where is that option?
21:52:08 <acoles> so...why did we not jump to 1.2.0, why step to 1.0.8?
21:52:15 <onovy> clayg: setup.py install --install-layout=deb --install-liberasurecode=no
21:52:27 <clayg> WHAT?
21:52:27 <kota_> +1
21:52:50 <onovy> acoles: because i wanted to drop jerasure defaults
21:52:58 <notmyname> acoles: ah, because it was code that was written to solve a different problem. and code written to solv that other thing makes the project better.
21:52:59 <onovy> acoles: a i done "smallest" step to achieve this
21:53:23 <onovy> so, should i make review to bump to 1.2.0? or anyone else wants?
21:53:24 <notmyname> acoles: basically it comes down to the fact that onovy got the 1.0.8 change into global-requirements.
21:53:30 <notmyname> onovy: go for it
21:53:35 <onovy> ok, i will do it
21:53:42 <acoles> notmyname: ok, i get it :)
21:54:18 <notmyname> acoles: I've been trying to apply a "working code that is good enough but maybe not the perfect end solution is better than no code" :-)
21:54:19 <notmyname> #topic open discussion
21:54:29 <acoles> heh, another merge master to feature/crypto on its way then :P
21:54:36 <notmyname> anything else to discuss in the meeting this week?
21:54:39 <onovy> https://review.openstack.org/#/c/240036/ https://review.openstack.org/#/c/250022/
21:54:44 <notmyname> acoles: that should be a regular thing anyway, right?
21:54:49 <onovy> unit coverage boost ^^!! :)
21:54:55 <notmyname> moar tests!
21:55:15 <onovy> waiting ~3 weeks, anyone?
21:55:18 * notmyname should make patchbot detect full gerrint urls too
21:55:26 <acoles> notmyname: right
21:56:19 <acoles> timburke: whats important to land in swiftclient before next release?
21:56:24 <mattoliverau> onovy: I'll add them to my list this week
21:56:26 <timburke> patch 265417 is some nice cleanup on the retry-partial-downloads work
21:56:27 <patchbot> timburke: https://review.openstack.org/#/c/265417/ - python-swiftclient - _RetryBody doesn't need to take explicit etag/cont...
21:56:32 <onovy> mattoliverau: thanks
21:56:36 <acoles> timburke: joeljwright other than "everything" :)
21:56:41 <timburke> along the same lines, patch 269252
21:56:41 <patchbot> timburke: https://review.openstack.org/#/c/269252/ - python-swiftclient - Check responses when retrying bodies
21:56:44 <clayg> onovy: good to ping on those patches - you don't have to wait for a meeting
21:56:57 <timburke> really want patch 252328
21:56:57 <patchbot> timburke: https://review.openstack.org/#/c/252328/ - python-swiftclient - Fix debug and info option parsing
21:57:09 <acoles> ^^ oh yeah, must do that
21:57:15 <joeljwright> I've been reading through the outstanding patches today
21:57:19 <onovy> clayg: ok
21:57:20 <timburke> patch 269359 is just stupid
21:57:20 <patchbot> timburke: https://review.openstack.org/#/c/269359/ - python-swiftclient - Display proper name when failing to create segment...
21:57:42 <timburke> and can't forget acoles's patch 275719
21:57:43 <patchbot> timburke: https://review.openstack.org/#/c/275719/ - python-swiftclient - Support --os-identity-api-version option
21:57:53 <notmyname> timburke: so, "all of them"? ;-)
21:58:12 <timburke> all low risk, but nothing critical
21:58:34 <onovy> and for me this: patch 276280 is must have! :)
21:58:34 <patchbot> onovy: https://review.openstack.org/#/c/276280/ - swift - Script for checking sanity of manpages
21:58:34 <joeljwright> timburke: agreed
21:58:45 <joeljwright> the only other thing is solving the logging bug before another release
21:58:48 <acoles> timburke: --debug position was annoying me again today, will try to review asap
21:58:50 <joeljwright> or asap
21:58:51 <joeljwright> ...
21:59:00 <timburke> notmyname: hey, as  long as i curate a little, you won't be *too* overwhelmed :-)
21:59:14 <timburke> joeljwright: true, good point
21:59:28 <joeljwright> I think I saw a candidate
21:59:36 <notmyname> for p in patches_by_author['timburke']: star(p)
21:59:43 <joeljwright> but it's a little confusing as there are 2 bug reports that are very similar
21:59:59 <notmyname> we're out of time for this meeting slot
22:00:18 <joeljwright> until next time…
22:00:18 <notmyname> thank you everyone for coming today. it's great to work with you on swift (and swiftclient!)
22:00:22 <notmyname> #endmeeting