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