15:00:30 <jd__> #startmeeting ceilometer
15:00:31 <openstack> Meeting started Thu Nov 14 15:00:30 2013 UTC and is due to finish in 60 minutes.  The chair is jd__. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:34 <openstack> The meeting name has been set to 'ceilometer'
15:00:46 <sileht> o/
15:00:47 <apmelton> o/
15:00:49 <dhellmann> o/
15:00:49 <lsmola_> hello
15:00:52 <gordc> o/
15:00:52 <llu-laptop> o/
15:00:55 <eglynn> o/
15:00:55 <nsaje> o/
15:00:59 <nadya_> o/
15:01:13 <zhikunliu> o/
15:01:16 <jd__> hi everybody
15:01:17 <sandywalsh> o/
15:01:19 <ildikov> o/
15:01:27 <thomasem> o/
15:01:28 <jun> o/
15:02:09 <jd__> #topic Pick our official name
15:02:15 <jd__> #link https://review.openstack.org/#/c/55877
15:02:28 <llu-laptop> Is it approved?
15:02:31 <jd__> so there's a little issue around what should be Ceilometer official name
15:02:38 <eglynn> the plural form of Measurements seems odd to my ears
15:02:45 <dhellmann> I agree with eglynn
15:02:59 <jd__> Measurement itself sounds odd to my ears
15:03:21 <dhellmann> networking vs. networks
15:03:34 <terriyu> o/
15:03:34 <eglynn> Orchestration versus Orchestrations ;)
15:03:35 <jd__> I was happy with Metering, but as a non-native speaker…
15:03:36 <jd__> 
15:03:54 <dhellmann> I think the idea was that metering doesn't cover the new monitoring and alarming stuff, right?
15:04:00 <eglynn> the problem with Metering was that it didn't fully reflect the expanded mandate right?
15:04:03 <dhellmann> although I could go with metering myself
15:04:04 <eglynn> yep
15:04:06 <thomasem> What about just Monitoring?
15:04:18 <jd__> Measurement would cover alarming?
15:04:23 <eglynn> again doesn't cover the full range of the project
15:04:29 <ildikov> Is Ceilometer a monitoring tool, or will it be ever?
15:04:33 <eglynn> (Monitoring that is ...)
15:04:38 <dhellmann> we do enough monitoring for alarms
15:04:56 <dhellmann> and that involves collecting more and different data than metering
15:05:29 <eglynn> yep, so measurement (of resource usage and performance) covers both bases
15:05:29 <thomasem> Monitoring - we monitor usage, we monitor watermarks for alarming, we will soon have events to monitor arbitrary things defined by the deployers. I don't see how monitoring misses anything?
15:05:47 <ildikov> Until we just trying to use aeras for names we will face with the same "not covering all" problem
15:05:55 <jd__> what about "OpenStack: The Missing Piece"? :)
15:06:02 <ildikov> :)
15:06:03 <sileht> :)
15:06:07 <llu-laptop> :-)
15:06:20 <terriyu> "Project X" ?
15:06:24 <jd__> haha
15:06:34 <jd__> shall we vote on Measurement then?
15:06:45 <sandywalsh> measurements doesn't cover events
15:07:08 <terriyu> I dunno, as a native English speaker, measurement doesn't sound that different from metering
15:07:15 <sandywalsh> collection?
15:07:31 <jd__> OpenStack Slurp?
15:07:36 <nadya_> we have processing too
15:08:07 <jd__> "monitoring" may cover events?
15:08:15 <ildikov> Maybe an abstract name would be better
15:08:29 <jd__> ildikov: right, like "Ceilometer" for example? :)
15:08:30 <eglynn> like "ceilometer" ;)
15:08:40 <eglynn> snap :)
15:08:40 <ildikov> exactly ;)
15:08:54 <jun> i think the name ceilometer is ok
15:08:54 <jd__> "OpenStack Ceilometer, codenamed Ceilometer, a project that ceilometer your OpenStack cloud."
15:09:14 <jd__> jun: that's not the point, we'll keep the code name
15:09:15 <lsmola_> +1 to Ceilometer
15:09:19 <jd__> we just need an official name
15:09:39 <lsmola_> :-(
15:09:53 <dhellmann> yeah, we need to pick the name we'll use for trademark purposes
15:09:54 <lsmola_> then Openstack Slurp :-)
15:10:24 <dhellmann> what about "metrics"?
15:10:27 <eglynn> so given that https://review.openstack.org/#/c/55375/ has landed already, the scope for change is fairly narrow, or?
15:10:43 <apmelton> what about Analytics?
15:10:45 <dhellmann> eglynn: no, we can "bug fix" the resolution
15:10:46 <gordc> eglynn: was going to ask the same question.
15:10:52 <eglynn> dhellmann: cool
15:10:53 <dhellmann> apmelton: we *do  not* do analytics
15:10:59 <nadya_> I like 'monitoring' :) I think if Ceilometer becomes real 'monitoring' tool it will be great
15:11:05 <dhellmann> that was specifically restricted from our charter
15:11:17 <eglynn> we more enable the doing of analytics by someone else
15:11:21 <dhellmann> right
15:11:28 <jd__> OpenStack Enabler then?
15:11:29 <sandywalsh> Data Collection
15:11:35 * sandywalsh pukes
15:11:35 <gordc> i'm ok with Measurements but i agree with sandywalsh, it doesn't really cover events well.
15:11:49 <jd__> Auditing?
15:11:56 <eglynn> Diagnostics?
15:12:02 <eglynn> Telemetry?
15:12:11 <jd__> telemetry's nice
15:12:13 <dhellmann> I sort of like telemetry
15:12:18 <ildikov> Telemetry sounds good :)
15:12:32 <eglynn> cool :)
15:12:37 <thomasem> A bit esoteric
15:12:42 <eglynn> very rocket-sciencey
15:12:44 <jd__> thomasem: like us
15:12:51 <nsaje> telemetry o/
15:13:08 <jd__> and it makes me think of teletubbies
15:13:13 <eglynn> LOL :)
15:13:15 <apmelton> +1 telemtry
15:13:17 <sileht> Telemetry sounds good
15:13:33 <eglynn> what's not to like about teletubbies? ;)
15:13:45 <sandywalsh> +1 Telemetry
15:13:46 <terriyu> I'm with thomasem , feel like "telemetry" is unnecessarily esoteric
15:13:52 <dhellmann> as long as we get teletubbies on our new logo, I'm good with it
15:14:04 <thomasem> No!
15:14:12 <dhellmann> esoteric?
15:14:16 <thomasem> Teletubbies are the most frightening thing on this planet...
15:14:17 <jd__> #startvote Should Ceilometer pick "OpenStack Telemetry" as it's official project name? Yes, No, Abstain
15:14:17 <openstack> Begin voting on: Should Ceilometer pick "OpenStack Telemetry" as it's official project name? Valid vote options are Yes, No, Abstain.
15:14:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:14:28 <sandywalsh> http://en.wikipedia.org/wiki/Telemetry
15:14:28 <jd__> let's vote on this :)
15:14:33 <eglynn> #vote Yes
15:14:34 <lsmola_> eglynn, lol
15:14:36 <dhellmann> point of order: should we vote on one name, or vote on the selections?
15:14:41 <sandywalsh> yes
15:14:45 <sandywalsh> #vote yes
15:14:46 <sileht> #vote yes
15:14:59 <apmelton> #vote yes
15:15:00 <jd__> dhellmann: I think it'll be simpler to vote on a name, otherwise we're going Condorcet :)
15:15:06 <dhellmann> #vote yes
15:15:08 <nsaje> #vote yes
15:15:08 <thomasem> #vote no
15:15:08 <yassine> #vote yes
15:15:08 <ildikov> #vote yes
15:15:09 <nadya_> #vote no
15:15:10 <terriyu> #vote no
15:15:12 <lsmola_> #vote yes
15:15:28 <llu-laptop> #vote yes
15:15:28 <jd__> #vote yes
15:15:38 <thomasem> Fair enough. =]
15:15:52 <jun> #vote yes
15:16:06 <jd__> vote ending in a few seconds
15:16:11 <jd__> tic-tac-tic-tac
15:16:22 <jd__> #endvote
15:16:23 <openstack> Voted on "Should Ceilometer pick "OpenStack Telemetry" as it's official project name?" Results are
15:16:24 <openstack> Yes (12): ildikov, apmelton, sileht, sandywalsh, jd__, eglynn, jun, llu-laptop, yassine, dhellmann, lsmola_, nsaje
15:16:25 <openstack> No (3): nadya_, thomasem, terriyu
15:16:35 <jun> looook like we are going to have this Telemetry
15:16:36 <jun> haha
15:17:01 <dhellmann> is this binding, or is this just polling the room so to speak? do we have anyone else who should be allowed to chime in? nijaba?
15:17:05 <sandywalsh> well done eglynn
15:17:27 <jd__> dhellmann: I don't think we have any written procedure for that, so…
15:17:55 <dhellmann> this feels like a big enough decision that we shouldn't make it just based on who can attend this meeting
15:18:05 <jd__> dhellmann: shall we ask the TC for a procedure? :)
15:18:09 <terriyu> dhellmann: +1
15:18:19 <dhellmann> it's good to see that there's a certain amount of consensus
15:18:20 <eglynn> dhellmann: well this meeting probably good enough to propose a patch on gerrit
15:18:37 <dhellmann> eglynn: that sounds like a good next step
15:18:42 <dhellmann> and a mailing list thread
15:18:43 <eglynn> (then nijaba can -2 the patch if he no likee ...)
15:18:46 <jd__> I think I'd go for a patch and add ceilometer-core as reviewer waiting for everyone to +1
15:19:41 <jd__> I'm ok doing that if that fits for you dhellmann
15:19:57 <eglynn> anyone can propose a patch to openstack/governance?
15:20:04 <jd__> eglynn: I'd hope so :)
15:20:05 <eglynn> (or just TC/board members)
15:20:06 <dhellmann> yes
15:20:08 <dhellmann> anyone
15:20:10 <eglynn> cool
15:20:28 <jd__> #action jd__ propose a patch to governance for Telemetry and add ceilometer-core as reviewers
15:20:53 <dhellmann> jd__: link to it on https://review.openstack.org/#/c/55877
15:20:59 <jd__> dhellmann: ack
15:21:01 <jd__> #topic Release python-ceilometerclient?
15:21:15 <eglynn> no need that I'm aware of
15:21:27 <jd__> me neither
15:21:47 <jd__> #topic hardware agent and central agent
15:22:00 <jd__> llu-laptop go ahaed
15:22:07 <lsmola_> is llu around?
15:22:19 <llu-laptop|2> just lost the internet connection. back just in time
15:22:25 <jd__> he was
15:22:37 <llu-laptop|2> i'm here now
15:22:37 <lsmola_> nice
15:23:22 <llu-laptop|2> first question, should we get hardware agent merged into central agent first, because I think improving central agent might take some time?
15:23:23 <lsmola_> so we need to move the whole baremetal agent into the Ironic codebase?
15:24:00 <jd__> llu-laptop|2: I'd say enhance the central one so it supports hardware, yes
15:24:10 <jd__> lsmola_: no
15:24:15 <lsmola_> llu-laptop|2, given the last conversation about the hardware agent, I understood Ironic guys wants to have it in ironic
15:24:28 <eglynn> #link https://etherpad.openstack.org/p/icehouse-summit-ceilometer-hardware-sensors
15:24:30 <jd__> the main need for hardware is the ability to provide resources in the pipeline and to make pollster protocol handle taht
15:24:47 <eglynn> "ceilometer agent running next to ironic conductor"
15:25:01 <lsmola_> eglynn, ok, that explains a lot
15:25:11 <jd__> and there's not only Ironic, there's a more general approach too
15:25:24 <jd__> which is what llu is trying to cover here
15:25:36 <eglynn> ... "running next to" == "separate process, same host"?
15:26:07 <llu-laptop|2> jd__: ok. things of the 'enhancement' in my mind is 1) 'resources' entry 2) membership and task distribution 3)abstraction layer of pipeline definition loading
15:26:19 <lsmola_> eglynn, well what I understood it should run with ironic, be scalable with ironic, etc.
15:26:24 <llu-laptop|2> do we agree that we need that part 3)?
15:27:04 <eglynn> what usecase would the abstarction layer enable?
15:27:11 <eglynn> *abstraction
15:27:16 <jd__> llu-laptop|2: point 2) is not of your concern directly here, it concerns a larger part of Ceilometer so don't worry about it
15:27:43 <llu-laptop|2> That's Dan Dyer from HP proposed in the design summit. Maybe loading it from DB other than the file?
15:28:07 <lsmola_> llu-laptop|2, are you considering connectiong to tripleo ?
15:28:18 <llu-laptop|2> maybe a low priority of part 3?
15:28:24 <eglynn> OK, nice-to-have, but I don't see a really compelling usecase for that
15:28:33 <eglynn> llu-laptop|2: yep, agreed
15:28:54 <lsmola_> llu-laptop|2, if deployed via tripleo, you can obtain baremetals and their IPs from nova, and IMPI credentials from Ironic
15:29:36 <lsmola_> llu-laptop|2, that is what we want to be configurable, so it automatically polls all resources available
15:30:10 <jd__> lsmola_: that work will help in this regard anyway
15:30:18 <jd__> llu: anything else or are you clear enough?
15:30:25 <llu-laptop|2> lsmola_: yes using tripleO+Ironic seems good for ipmi data collection. But what about the situation of not having tripleO?
15:31:01 <lsmola_> llu-laptop|2, for for SNMP, you will have to get the IPs from somewhere, defining them by hard will be painfull
15:31:18 <jd__> not everybody will use Ironic so we'll support that too
15:31:25 <lsmola_> llu-laptop|2, and you would also define the IPMI credentials by hard
15:31:27 <jd__> no point in arguing about that
15:31:31 <llu-laptop|2> I'm not an advocate of SNMP. it's just from the original author, toni
15:31:56 <eglynn> lsmola_:  "defining baremtals by hand" == "listing IPs in the pipeline.yaml"
15:32:01 <eglynn> ?
15:32:21 <lsmola_> jd__, well as Tripleo will be official deployment program, and Ironic will become officila in Icehouse too, we should definitely support that, right?
15:32:22 <jd__> eglynn: and credentials if needed yeah
15:32:29 <jd__> lsmola_: yes, but not only
15:32:38 <eglynn> k, that does seem like badness
15:32:48 <eglynn> way too static to be useful IMO
15:32:49 <lsmola_> eglynn, yes basically
15:33:16 <jd__> eglynn: until OpenStack provides an inventory service, that may be a good solution for a lot of corner case
15:33:19 <lsmola_> jd__, yeah agree, it should be matter of configuration of agent
15:33:52 <eglynn> so wouldn't we have to restart the agent everytime a new baremetal hosts appears?
15:34:01 <lsmola_> eglynn, yeah :-D
15:34:03 <eglynn> (i.e. to force a re-read of the pipeline.yaml)
15:34:05 <dhellmann> didn't the ironic guys say they wanted to be the only thing talking ipmi, since there are security risks with spreading those credentials around?
15:34:21 <eglynn> dhellmann: yep, that rings a bell
15:34:26 <llu-laptop|2> sorry guys, I'm having internet jag here. maybe slow in response
15:34:36 <lsmola_> dhellmann, exactly
15:34:39 <dhellmann> so maybe we just need to talk to the ironic service to get the data we want?
15:34:56 <dhellmann> sorry, I'm catching up on this issue, so I apologize if I'm restating the obvious
15:35:31 <lsmola_> dhellmann, well i am not sure about the connection, all I heard is that the Agnet will be part of Ironic (or running next to) so it can access ironic
15:35:32 <eglynn> so I think the concern was not to limit to ironic only, or?
15:35:43 <jd__> no, the Ironic guy points is that *if* ironic is used, Ceilometer should ask Ironic, and not talk SNMP/IPMI directly and ask for the credentials Ironic knows
15:35:56 <jd__> but please, don't mix the "I use Ironic" and "I don't use Ironic" use-cases
15:35:59 <lsmola_> dhellmann, from what I know, originally Ironic should expose the data via API
15:36:09 <dhellmann> ok, well, talking to ironic seems like a good starting place at least
15:36:12 <lsmola_> dhellmann, but it's not the case anymore
15:36:28 <dhellmann> oh, when did that change?
15:36:40 <llu-laptop|2> lsmola_: what's the case now?
15:36:44 <lsmola_> dhellmann, apparently on the conference :-)
15:37:16 <lsmola_> well ndipanov told me that they don't want it, they rahter want to run an agent somewhere next to Ironic
15:37:39 <lsmola_> I am not sure what exact architecture it should be
15:37:51 <dhellmann> are they expecting us to write that agent, or is it just something different from their current agent that they are going to write?
15:38:19 <eglynn> lsmola_: run an agent next to the ironic conductor that depends on an API exposed by ironic, right?
15:38:32 <jd__> eglynn: I think so
15:38:46 <lsmola_> dhellmann, hmm not sure, I have to ask ndipanov again
15:38:54 <jd__> but really, this topic is not about Ironic
15:39:03 <lsmola_> dhellmann, because it seemed to me like the Ironic IPMI API idea died
15:39:24 <lsmola_> jd__, ok so lets talk about what we want to support
15:40:00 <jd__> can I say "no"? :)
15:40:09 <dhellmann> lsmola_: we don't need an IPMI API, we need a monitoring API
15:40:19 <lsmola_> jd__, for me minimum seems, defining it by hard, + option to allow agent to get the IP's and IPMI credentials from Nova and Ironic
15:40:49 <lsmola_> dhellmann, yeah I just named it badly
15:41:00 <jd__> lsmola_: agreed, but I don't think that was llu's questions initially
15:41:08 <dhellmann> lsmola_: ok, just making sure we're clear :-)
15:41:27 <eglynn> if relying on defining by hand, then in the least case we need some way of avoiding the agent restart on pipeline.yaml change
15:41:44 <eglynn> (e.g. detecting a change in the file timestamp and re-reading in that case)
15:41:45 <jd__> eglynn: we have a reload system via SIGHUP
15:42:08 <llu-laptop|2> do we want the restart or avoid the restart?
15:42:12 <lsmola_> eglynn, yeah that makes sense
15:42:19 <jd__> llu-laptop|2: avoid
15:42:20 <llu-laptop|2> SIGHUP I think is the restart system
15:42:22 <eglynn> jd__: send a SIGHUP to the process and that forces a re-read?
15:42:27 <jd__> eglynn: IIRC yes
15:42:47 <eglynn> jd__: k, I wasn't familiar with that
15:43:14 <dhellmann> eglynn: what if we put that info in a different file from the pipeline, and just read that file in the pollster(s) (with caching)
15:43:24 <lsmola_> jd__, also we will want to get list of switches and routers from Neutron later
15:43:43 <jd__> sure
15:43:50 <eglynn> dhellmann: yep, that would be neater
15:43:57 <jd__> I'm restating that this is not the subjet of llu intervention here
15:44:03 <llu-laptop|2> jd__: I think our current SIGHUP implementation is to automatically restart the service, so new pipeline definition applies
15:44:16 <jd__> llu-laptop|2: don't have details in mind, that may be :)
15:44:53 <llu-laptop|2> Fengqian did this in Havana cycle. I'll ping him to double check
15:45:01 <llu-laptop|2> tomorrow
15:45:07 <jd__> is there any more question than you need an answer llu or can I move on to the next topic?
15:45:19 <llu-laptop|2> please move on, thanks
15:45:29 <jd__> #topic integration tests discussion
15:45:36 <jd__> nadya_: floor is yours
15:45:45 <nadya_> yep, thanks
15:46:18 <nadya_> so the first item is resolved. As I see all crd were restored and is being reviewed now
15:46:39 <lsmola_> llu-laptop|2, would be great if you could ping ndipanov and devananda
15:46:45 <nadya_> JFYI I will care about https://review.openstack.org/#/c/55276
15:47:10 <lsmola_> llu-laptop|2, to make sure if we are thinking about it correctly :-)
15:47:22 <eglynn> might be useful to do a show of hands as to who is interested in beefing up ceilo coverage in tempest?
15:47:40 <eglynn> then maybe do a rough division of functional areas to concentrate on?
15:47:49 <nadya_> I guess we've covered all tempest crs
15:47:51 <eglynn> (to avoid possible duplication)
15:47:58 <jd__> I think yassine is
15:48:16 <eglynn> o/ ... I am also
15:48:27 <yassine> o/
15:48:29 <nadya_> me too o/
15:48:36 <zhikunliu> me too
15:48:37 <litong> @eglynn, certainly, yes.
15:48:48 <jd__> using the blueprint whiteboard or todo list to state what people are working on could be a good idea
15:49:14 <jd__> #link https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests
15:49:14 <eglynn> jd__: yep, good call
15:49:54 <eglynn> will one blueprint suffice?
15:50:11 <eglynn> that one is skewed a bit towards the more basic functionality
15:50:39 <jd__> I've no opinion, but it's possible to create sub-blueprints with dependencies
15:50:51 <eglynn> also doesn't tempest use its own client layer? (not sure that fits with "CLI basic functionalities")
15:50:57 <nadya_> agreed. So will we determine any period of time within which test plan should be completed?
15:51:23 <eglynn> nadya_: let's aim for early next week
15:51:27 <eglynn> say Monday?
15:51:45 <nadya_> ok
15:52:28 <nadya_> should we write in email?? Or let's refuse amount of letters? :)
15:52:36 <nadya_> *reduce
15:53:25 <eglynn> nadya_: an etherpad is probably better suited to getting multiple contributions lined up
15:53:33 <zhikunliu> https://etherpad.openstack.org/p/ceilometer-test-plan
15:53:34 <eglynn> (i.e. better than an email thread)
15:53:41 <eglynn> zhikunliu: thanks!
15:53:55 <nadya_> oh, I saw this doc, yes
15:54:34 <nadya_> ok. So Monday is the day when we have test-plan for Ceilometer+Tempest
15:54:50 <lsmola_> have to run, see you all next week, we have angularjs beer meeting :-D
15:55:02 <zhikunliu> :)
15:55:12 <nadya_> and one more question from me about devstack+ceilometer. Who is an expert in this area? We started to look into devstack issues
15:55:15 <jun> :)
15:55:32 <jd__> I think sileht knows a lot
15:55:41 <jd__> though feel free to ask to everybody on #openstack-metering
15:55:55 <eglynn> nadya_: yep re. the test plan ... I'll start by setting out the areas that I intended to concentrate on, and also some general thoughts on the approach
15:56:21 <eglynn> the devstack+ceilometer issue is the sqlalchemy connection pooling thingy, right?
15:56:28 <terriyu> nadya_: I complain a lot about devstack+ceilometer -- i.e. report bugs
15:56:30 <sileht> nadya_, I have made the lists of the pendings review to have a working devstack in gate in the bp
15:57:02 <nadya_> eglynn, sure. I'm planning to work on test-plan tomorrow too
15:57:09 <eglynn> nadya_: cool
15:57:55 <nadya_> terriyu, sileht, great, will keep in touch
15:57:57 <jd__> PA: meeting is ending on a few minutes
15:58:22 <nadya_> I think we can move on to general discussions
15:58:49 <jd__> #topic Open discussion
15:59:09 <nadya_> jd__, when bps from design sessions should be finished?
15:59:28 <jd__> nadya_: as soon as possible, especially ones targetting icehouse-1
16:00:01 <eglynn> let's try to get blueprints filed by next week's meeting if poss
16:00:12 <eglynn> (while the summit is still fresh in the mind ...)
16:00:22 <jd__> good idea
16:00:40 <litong> I always wonder which db ceilometer wants to use as the first option.
16:00:41 <eglynn> so icehouse-1 is due when, Dec 4th?
16:00:42 <ildikov> Is there a schedule available for icehouse?
16:00:54 <dhellmann> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
16:01:02 <dhellmann> that's not final yet
16:01:03 <litong> devstack config for ceilometer shifts from mongodb to mysql.
16:01:14 <ildikov> Thanks
16:01:15 <jd__> eglynn: yess
16:01:17 <jd__> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
16:02:11 <eglynn> cool, we get "Off" weeks this time :)
16:02:18 <litong> anyone know why devstack setup for ceilometer uses mysql now vs using mongodb before?
16:02:27 <jd__> I'm closing the meeting as we already late, please follow up in #openstack-metering as needed
16:02:35 <eglynn> litong: issue with mongodb 2.4 on precise
16:02:45 <jd__> litong: discussed during the summit btw
16:02:47 <jd__> #endmeeting