18:01:22 <vipul> #startmeeting cue
18:01:23 <openstack> Meeting started Tue Jul 21 18:01:22 2015 UTC and is due to finish in 60 minutes.  The chair is vipul. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:27 <openstack> The meeting name has been set to 'cue'
18:01:37 <vipul> same time.. new day
18:01:41 <vipul> roll call..
18:01:51 <esmute_> 0/
18:02:06 <dkalleg> hey o/
18:02:26 <vipul> sputnik13, abitha[tab][tab]
18:02:56 <vipul> #agenda https://wiki.openstack.org/wiki/Meetings/Cue
18:03:38 <vipul> #topic action items
18:03:42 <vipul> #link http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-07-13-18.01.txt
18:03:46 <sputnik13> o/
18:04:14 <vipul> ok i'll skip davide's actions
18:04:32 <sputnik13> http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-07-13-18.01.html
18:04:36 <sputnik13> this one has links :)
18:04:55 <vipul> html pfft
18:04:58 <vipul> sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:05:10 * sputnik13 kicks the can further down
18:05:19 <vipul> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka
18:05:20 <sputnik13> I couldn't get kafka to work at all
18:05:39 <sputnik13> I'm trying to pass a message to kafka and consume it when it's clustered
18:05:45 <sputnik13> and it just kept breaking
18:05:57 <vipul> hmm.. that's kind of foundational stuff..
18:05:58 <esmute_> sputnik13: is this just a standalone kafka?
18:05:59 <sputnik13> I think there's more investigation to be done, and I need to get help from someone who's done this before
18:06:09 <sputnik13> esmute_ clustered kafka
18:06:13 <esmute_> or are you trying to get it in cue?
18:06:28 <vipul> ok we should understand how to stand it up properly.. and see if that impacts cue in any way..
18:06:35 <vipul> in terms of our api, etc.
18:06:44 <sputnik13> esmute_: standalone
18:06:53 <sputnik13> vipul: agreed, I'll continue banging away at it
18:07:13 <vipul> ok cool
18:07:13 <vipul> esmute__ to follow up with patch (https://review.openstack.org/#/c/194324/) and ensure it gets merged
18:07:22 <vipul> why does esmute_ have an underscore
18:07:30 <esmute_> vipul: that merged long ago
18:07:51 <esmute_> the int-tests are now voting and they are run during gating
18:07:52 <vipul> oh yes.. its voting now
18:07:59 <vipul> they seem to be pretty consistent too..
18:08:09 <sputnik13> vipul I think you're looking at the wrong list
18:08:25 <sputnik13> the one at the top are the topics from last week, we talked about those actions last week
18:08:33 <vipul> oh damn
18:08:36 <vipul> what's the link
18:08:36 <sputnik13> the actions from last week are half way down
18:08:55 <vipul> got it..
18:08:55 <sputnik13> it so happens that we've had the same two issues for davide and I for the past 2 weeks :)
18:09:15 <vipul> ok so only other one is sputnik13 to follow up on confirming https://bugs.launchpad.net/cue/+bug/1429304
18:09:16 <openstack> Launchpad bug 1429304 in Cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] - Assigned to Steve Leon (steve-leon)
18:09:18 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete]
18:09:19 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] https://launchpad.net/bugs/1429304
18:09:35 <sputnik13> still to be done
18:09:49 <esmute_> sputnik13: going back to kafka, doesnt monasca use kafka for their checks? perhaps you could go ask them
18:09:53 <sputnik13> I'll work with esmute_ to get it confirmed
18:10:07 <sputnik13> esmute_: I'm using monasca's kafka playbook
18:10:26 <sputnik13> yeah I'm planning to talk with them
18:10:53 <vipul> #action sputnik13 to follow up on confirming https://bugs.launchpad.net/cue/+bug/1429304
18:10:55 <openstack> Launchpad bug 1429304 in Cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] - Assigned to Steve Leon (steve-leon)
18:10:56 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete]
18:10:57 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] https://launchpad.net/bugs/1429304
18:11:47 <vipul> Ok that's it for actions..
18:11:51 <vipul> we don't have any discussion topics
18:12:04 <vipul> Anyone have anything they wnat to bring up before we go to bugs/
18:12:38 * vipul needs to do a better job at adding stuff to agenda prior to meeting
18:13:03 <vipul> #topic bugs
18:13:21 <sputnik13> let's squash them bugs
18:13:51 <vipul> get ready.. this link is going to be awesome
18:13:52 <vipul> https://bugs.launchpad.net/cue/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&field.importance%3Alist=MEDIUM&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&fiel
18:13:52 <vipul> d.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
18:13:58 <vipul> damn that didn't work
18:14:07 <esmute_> doesnt work
18:14:15 <vipul> http://bit.ly/1MChDwJ
18:14:27 <vipul> ^ much better
18:14:31 <sputnik13> hah, beat me to it
18:14:40 <sputnik13> same link as mine
18:14:55 <vipul> consistent hashing :)
18:15:09 <sputnik13> yeah but the has is so small, I wonder how they make it unique
18:15:17 <sputnik13> whatever...  bugz
18:15:34 <vipul> are there bugs on that list that need to be scrubbed?
18:15:47 <sputnik13> there are 2 High
18:15:53 <sputnik13> in New state
18:15:58 <sputnik13> so we should look at them and triage them at minimum
18:16:05 <vipul> ok let's start with https://bugs.launchpad.net/cue/+bug/1452959
18:16:06 <openstack> Launchpad bug 1452959 in Cue "cluster does not ERROR on missing broker metadata" [High,New]
18:16:06 <esmute_> use a tiny url
18:16:06 <esmute_> or bitly
18:16:07 <uvirtbot> Launchpad bug 1452959 in cue "cluster does not ERROR on missing broker metadata" [High,New]
18:16:09 <uvirtbot> Launchpad bug 1452959 in cue "cluster does not ERROR on missing broker metadata" [High,New] https://launchpad.net/bugs/1452959
18:16:19 <sputnik13> esmute_: we did, keep up with the convo man :)
18:16:29 <vipul> 15 lines up :P
18:16:30 <esmute_> i cant access those link for some reason
18:16:44 <esmute_> my internet is shitty
18:17:24 <vipul> so this one should be easy to fix..
18:17:35 <sputnik13> is it High?
18:17:58 <vipul> It's unlikely that we will have missing broker metadata.. if you've followed the deployment docs though
18:18:03 <vipul> so i wouldn't think it's a high pri
18:18:21 <sputnik13> there's also no loss of data and no complete failure
18:18:32 <vipul> it's a deployment error, not something the user can influence
18:18:53 <sputnik13> right but, the workaround is just delete it
18:18:53 <esmute_> how can the metadata get missing?
18:19:13 <sputnik13> oh wait I get it
18:19:27 <sputnik13> esmute_: this is broker metadata, it's a cue control plane setup issue
18:19:35 <vipul> esmute_: it can't.. unless you've set things up incorrectly
18:20:04 <vipul> ok changing status to confirmed / priority to medium?
18:20:08 <sputnik13> on the positive side cue doesn't die :)
18:20:19 <esmute_> so its a deployment issue... but this could be a small issue of something larger
18:20:21 <sputnik13> confirmed and I'd say low
18:20:35 <vipul> esmute_: how so
18:20:43 <esmute_> we should introduce a timeout so that the cluster get to ERROR if something is wrong
18:21:06 <sputnik13> Medium = Failure of a significant feature, with workaround or Failure of a fringe feature, no workaround
18:21:12 <esmute_> there will be cases of random issues when deployment doesnt go as planned..
18:21:17 <vipul> is this a case where we don't actually begin to invoke the flow?
18:21:31 <vipul> there may be some stuff on the API side that isn't catching errors correctly
18:21:44 <sputnik13> wait, let's not talk about how to do it
18:21:46 <vipul> but i agree esmute_  we need to be do a catch all to error
18:22:03 <sputnik13> what I mean is "timeout" is a specific implementation
18:22:07 <sputnik13> and in this instance it's the wrong one
18:22:24 <sputnik13> what we want is for the indication to be ERROR instead of BUILDING
18:22:42 <vipul> sputnik13: why didn't the flow revert handle thigs
18:22:47 <vipul> s/thigs/this
18:22:48 <esmute_> sputnik13: can cue detect that the broker metadata is missing?
18:23:21 <sputnik13> that's what the bug is also indicating as the failure, so the resolution is for the flow to fail and set ERROR rather than leaving things in BUILDING
18:23:59 <sputnik13> vipul: I think this might be related to an issue we had in the past where failure in subflows was not triggering a rollback of the surrounding flow
18:24:18 <vipul> although you fixed that in taskflow
18:24:18 <sputnik13> we addressed that bug, and this could be resolved, it might not
18:24:25 <esmute_> sputnik13: is the task retrying or does it just fail due to metadata missing and it doesnt report the status to the flow?
18:24:32 <vipul> ok.. the other thing i was thinking is maybe this is a api side issue..
18:24:36 <sputnik13> I think this bug predates that fix
18:24:40 <vipul> where we haven't actually submited a job
18:24:54 <sputnik13> that's another possibility
18:25:04 <vipul> would be nice to have a stacktrace :P
18:25:20 <sputnik13> yes *somebody* filed an incomplete bug report
18:25:27 <esmute_> so are we trying to come up with a fix here or are we debating whether this bug should be fixed and its priority?
18:25:33 <sputnik13> *somebody*...  not going to say who
18:25:44 <vipul> updated status to incomplete
18:25:49 <vipul> let's find out if this is really an issue
18:25:53 <esmute_> some guy whose name is 'min pae'
18:25:54 <sputnik13> esmute_: we should be debating the bug and its priority
18:25:56 <vipul> or if taskflow fixed things
18:26:21 <sputnik13> vipul: it should also be reprioritized, either medium or low
18:26:31 <vipul> it's set to low
18:26:55 <vipul> if someone gets a deployment without broker metadata.. try to build a cluster and capture the errors
18:27:13 <sputnik13> ok
18:27:16 <esmute_> it should be low because it is a deployment issue.... in happy path deployment, this should not happen right?
18:27:26 <vipul> that's the theory
18:27:26 <sputnik13> esmute_: correct
18:27:30 <vipul> https://bugs.launchpad.net/cue/+bug/1469823
18:27:31 <openstack> Launchpad bug 1469823 in Cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,New]
18:27:33 <vipul> next up
18:27:41 <uvirtbot> Launchpad bug 1469823 in cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,New]
18:27:42 <uvirtbot> Launchpad bug 1469823 in cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,New] https://launchpad.net/bugs/1469823
18:28:42 <vipul> ok this is a hard one to repro
18:28:49 <esmute_> so does this happen because the list-port task is not checking whether the vms exist?
18:28:56 <sputnik13> vipul: davideagnello has a fix for it already
18:29:03 <sputnik13> esmute_: yes
18:29:07 <vipul> well in that case.. :D
18:29:17 <sputnik13> is the priority correct though?
18:29:29 <vipul> does it leak resources?
18:29:34 <esmute_> sputnik13: are ports associated with VMs? ie can a port exist on its own?
18:29:43 <sputnik13> esmute_: yes and yes
18:29:59 <sputnik13> vipul: not sure, I guess it's a possibility
18:30:23 <esmute_> sputnik13: so why does it need to check whether the VM exists? Shouldnt it check only if the port exists and delete them if they do.
18:30:30 <esmute_> i guess i can look at davide's patch
18:30:31 <vipul> i would say if there is a potential of things being left around and the user can't clean them up.. then it probably is at the right priority
18:30:40 <sputnik13> esmute_: there's a nova port list prior to the port delete
18:31:02 <sputnik13> vipul: ok
18:31:02 <vipul> you mena a neutron port list?
18:31:21 <sputnik13> vipul: no I think it's a nova port list
18:31:26 <sputnik13> to get the ports that belong to the vm
18:31:31 <esmute_> #link https://review.openstack.org/#/c/196332/
18:31:36 <vipul> davide uses hotmail :P
18:31:39 <esmute_> its this one right?
18:32:00 <sputnik13> davideagnello is of soft micro
18:32:55 <vipul> ok other ones are all medium
18:33:04 <sputnik13> should we go through the mediums?
18:33:18 <vipul> we do have some time let's go quick
18:33:33 <vipul> ok https://bugs.launchpad.net/cue/+bug/1425130
18:33:34 <openstack> Launchpad bug 1425130 in Cue "Refactor Cue TaskFlow tasks" [Medium,New]
18:33:35 <uvirtbot> Launchpad bug 1425130 in cue "Refactor Cue TaskFlow tasks" [Medium,New]
18:33:36 <uvirtbot> Launchpad bug 1425130 in cue "Refactor Cue TaskFlow tasks" [Medium,New] https://launchpad.net/bugs/1425130
18:33:53 <sputnik13> that's a wishlist at best
18:34:10 <sputnik13> it's related to the os_tasklib stuff as well, there's no bug
18:34:13 <sputnik13> it's a refactor
18:34:13 <esmute_> i dont understand this bug
18:34:23 <esmute_> sputnik13: can you ELI5?
18:34:28 <vipul> yea it's more of a nice to have
18:34:33 <sputnik13> it's refactoring, we should make it wishlist
18:34:36 <vipul> ELI5?
18:34:54 <esmute_> Explain Like I'm 5?
18:35:02 <sputnik13> ELI5
18:35:06 <vipul> you redditors
18:35:14 <sputnik13> http://bfy.tw/vFY
18:35:18 <dkalleg> upvote
18:35:25 <sputnik13> power of the google
18:35:40 <sputnik13> esmute_: it's a refactor
18:35:45 <sputnik13> next bug
18:36:00 <vipul> https://bugs.launchpad.net/cue/+bug/1426103
18:36:01 <openstack> Launchpad bug 1426103 in Cue "Validate UUID API parameter's at API layer instead of DB interface" [Medium,New]
18:36:01 <uvirtbot> Launchpad bug 1426103 in cue "Validate UUID API parameter's at API layer instead of  DB interface" [Medium,New]
18:36:03 <uvirtbot> Launchpad bug 1426103 in cue "Validate UUID API parameter's at API layer instead of  DB interface" [Medium,New] https://launchpad.net/bugs/1426103
18:36:34 <sputnik13> that looks like another refactor to me
18:36:49 <vipul> are we returning the wrong error code?
18:37:03 <sputnik13> not sure...  so it's incomplete as well
18:37:09 <vipul> ok i'll put a comment
18:37:14 <dkalleg> Does this make it more difficult to debug an invalid UUID issue?
18:37:31 <dkalleg> Or is the current output still obvious?
18:37:36 <esmute_> this seems like a validate needs to happen at the API level?
18:38:17 <vipul> dkalleg: i think we should be doing input validation.. instead of relying on a lower level subsystem to catch the input error
18:38:20 <sputnik13> esmute_: that may be true but if the functionality is correct then it's a refactor not a bug
18:38:33 <sputnik13> in which case it would be more low or wishlist, not medium
18:38:59 <vipul> +1 if we should be returning a 500 or something else.. and we're not.. then it's a higher priority and a real bug
18:39:05 <dkalleg> vipul: agreed.  I ask if it is currently made obvious when a invalid UUID is passed in to help prioritize
18:39:15 <esmute_> vipul: 500 sounds scary
18:39:19 <esmute_> it should be 404
18:39:29 <esmute_> 500 internal server error
18:39:50 <vipul> 404 not found ?
18:40:09 <vipul> yes that makes sense actually on a GET
18:40:18 <esmute_> vipul: yes.. 404 not found... the user is sending an invalid UUID
18:40:39 <vipul> in that case this is a bug
18:40:50 <dkalleg> If it doesn't currently say "<error code>: you passed in an invalid UUID dum dum", then it seems important to correct that more quickly.
18:41:19 <vipul> sounds like you just get a 400 bad request
18:41:31 <vipul> sputnik13: are you updating the ubg?
18:41:35 <vipul> s/ubg/bug
18:41:48 <sputnik13> I asked the question "is the response correct?"
18:41:59 <sputnik13> "Is the response code correct? What is the anomalous behavior?"
18:42:07 <vipul> we should be returning a 404 sputnik13
18:42:24 <sputnik13> I think he's saying we're returning 400
18:42:42 <vipul> yea that sounds like we should just confirm it and prioritize
18:42:53 <sputnik13> 400 vs 404 seems not that bad to me
18:43:03 <vipul> it's not accurate..
18:43:28 <sputnik13> true, but other functionality is fine
18:43:43 <vipul> REST is all about response codes.. and if we can't tell the user the right response code then our api sucks
18:43:56 <sputnik13> cue is doing what it's supposed to
18:44:20 <sputnik13> no argument there, but that's more a design change than a defect, it's doing things as designed
18:44:26 <vipul> that's subjective.. you could say Cue should be telling me that ID doesn't exist
18:44:28 <sputnik13> tomato tomato :)
18:45:21 <vipul> i think it's at least a Medium priority confirmed bug..
18:45:28 <esmute_> i think it is a simple enought fix that we can take care of it fast
18:45:29 <sputnik13> I can see it either way, medium sounds fine
18:45:38 <dkalleg> +1
18:45:39 <esmute_> like a low hanging fruit
18:45:41 <sputnik13> is it confirmed?
18:46:12 <vipul> If davide has seen it.. then probably
18:46:34 <vipul> ok let's move on to the next one
18:46:36 <vipul> https://bugs.launchpad.net/cue/+bug/1429649
18:46:37 <openstack> Launchpad bug 1429649 in Cue "Consolidate cue.conf and worker.conf" [Medium,New]
18:46:37 <uvirtbot> Launchpad bug 1429649 in cue "Consolidate cue.conf and worker.conf" [Medium,New]
18:46:39 <uvirtbot> Launchpad bug 1429649 in cue "Consolidate cue.conf and worker.conf" [Medium,New] https://launchpad.net/bugs/1429649
18:47:48 <dkalleg> Seems like another refactor
18:47:52 <sputnik13> that's definitely wishlist
18:47:55 <vipul> this is a simple copy and paste to cue.conf
18:48:02 <vipul> and a rm of woker.conf right?
18:48:09 <dkalleg> and verify and test, yada yada
18:48:20 <sputnik13> yeah
18:48:24 <dkalleg> Is Medium too high?
18:48:26 <esmute_> why not just have separate conf for both?
18:48:33 <sputnik13> dkalleg: there's no failure
18:48:36 <vipul> cuz they 99% the same
18:48:55 <vipul> low hanging fruit..
18:48:58 <dkalleg> sputnik13: Right.  Seems like a refactor.  So how are we prioritizing refactors?
18:49:01 <vipul> although probably in the refactor category
18:49:13 <sputnik13> dkalleg: https://wiki.openstack.org/wiki/Bugs
18:49:22 <sputnik13> https://wiki.openstack.org/wiki/Bugs#Importance
18:49:31 <dkalleg> sputnik13: gracias
18:49:35 <esmute_> so this is for the 1%?
18:50:05 <vipul> esmute_: so we're saying we shouldn't maintain 2 separate confs for the 1% case
18:50:07 <dkalleg> Wishlist +1
18:50:12 <sputnik13> it's a refactor, let's push it to wishlist and move on to other bugs, the finer point of how to get it done can be offline
18:50:43 <vipul> ok last bug https://bugs.launchpad.net/cue/+bug/1436116
18:50:44 <openstack> Launchpad bug 1436116 in Cue "Cluster create API should accept username/password for rabbit endpoints" [Medium,New]
18:50:46 <uvirtbot> Launchpad bug 1436116 in cue "Cluster create API should accept username/password for rabbit endpoints" [Medium,New]
18:50:47 <uvirtbot> Launchpad bug 1436116 in cue "Cluster create API should accept username/password for rabbit endpoints" [Medium,New] https://launchpad.net/bugs/1436116
18:51:14 <sputnik13> that's also not a defect
18:51:14 <esmute_> This is a feature.. so should be a BP and not a bug no?
18:51:18 <sputnik13> that's a new feature
18:51:23 <vipul> BP sounds right
18:51:32 <vipul> sputnik13: you're filing one right
18:51:46 <esmute_> that BP should include also work in the client and dashboard
18:51:54 <sputnik13> esmute_: I thought I did already
18:52:10 <esmute_> you probably did sputnik13
18:52:11 <sputnik13> hmm guess not
18:52:11 <vipul> we need to review the api changes this would have
18:52:28 <vipul> and see if those make sense for qpid, kafka, etc
18:52:40 <sputnik13> oh, right
18:52:43 <sputnik13> yes bp :)
18:52:59 <sputnik13> regardless this is wishlist, there's no "bp" importance
18:53:24 <vipul> put a comment saying it shoudl be a BP
18:53:30 <vipul> and link it when we have one
18:53:34 <esmute_> this is coming up soon though
18:53:53 <esmute_> its at the top in the backlog
18:53:54 <vipul> yep.. something we want to get to soon
18:54:17 <sputnik13> we shouldn't confirm this a s a bug right?
18:54:22 <sputnik13> it should be "won't fix"
18:54:25 <sputnik13> it's not a bug
18:54:36 <sputnik13> err sorry "Invalid"
18:54:37 <vipul> #action sputnik13 to file a BP for user defined credentials for brokers
18:54:52 <sputnik13> marked it Invalid and Wishlist
18:54:55 <vipul> ok
18:55:00 <vipul> done with bugs for today
18:55:08 <vipul> #topic open discussion
18:55:08 <sputnik13> yay we're done 5 minutes early
18:55:12 <sputnik13> instead of 5 minutes late
18:55:26 <sputnik13> mid cycle!
18:55:31 <vipul> oh yes!
18:55:33 <sputnik13> we need a mid cycle
18:55:36 <vipul> it will be held in seattle
18:55:39 <vipul> at the HP offices
18:55:46 <sputnik13> booooo
18:55:48 <vipul> details to come
18:55:49 <vipul> ;D
18:56:03 <sputnik13> we need to get some non-HP contributors
18:56:17 <vipul> indeed
18:56:45 <sputnik13> somebody should go start a Cue company
18:56:56 <vipul> so we can have a Cue day?
18:56:59 <sputnik13> a Tesora for Cue
18:57:11 <sputnik13> they're essentially a Trove company right?
18:57:15 <vipul> pretty much
18:57:22 <sputnik13> we need the equivalent for Cue, so we can do mid cycles :-D
18:57:47 <sputnik13> how many talks have we submitted for Tokyo?
18:57:48 <vipul> brb.. getting some funding
18:58:05 <vipul> i believe around 5
18:58:10 <sputnik13> I can invest $100 in your company, where does that put us in funding?
18:58:11 <sputnik13> :)
18:58:23 <vipul> and you want 10% i bet
18:58:33 <sputnik13> no, I'm not that greedy, just 9%
18:58:39 <vipul> ok with that..
18:58:41 <vipul> #endmeeting