15:03:21 <bcoca> #startmeeting ansbile core irc public meeting 15:03:21 <zodbot> Meeting started Thu Feb 28 15:03:21 2019 UTC. 15:03:21 <zodbot> This meeting is logged and archived in a public location. 15:03:21 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:21 <zodbot> The meeting name has been set to 'ansbile_core_irc_public_meeting' 15:03:36 <devyani7> .hello devyani7 15:03:37 <zodbot> devyani7: devyani7 'Devyani Kota' <devyanikota@gmail.com> 15:03:42 <bcoca> #topic https://github.com/ansible/ansible/pull/52045 15:03:44 * bcoca waves 15:03:52 <bcoca> alan? 15:04:22 <bcoca> #topic https://github.com/ansible/proposals/issues/155 15:04:30 <alongchamps> \o/ 15:04:33 <bcoca> ^ change 'retry files' to be disabled by deafult 15:04:47 <bcoca> +1 from me, simple change, annoying feature (IMHO) 15:05:02 <sdoran> +1 from me 15:05:18 <alongchamps> I like it, +1 to disable retry file 15:05:22 <sdoran> I do the same thing as agaffney: pretty much always disable and never really use it. 15:05:26 <sivel> +1 15:05:30 <sdoran> Though it is a neat feature. 15:05:37 <sivel> I wonder how many people actually use the resulting retry files 15:05:48 <sdoran> sivel: Same here. 15:05:48 <sivel> I never have 15:05:50 <alongchamps> I usually ignore them, personally 15:07:37 <bcoca> i would not vote against the feature existing, just being default 15:07:47 <sdoran> Yup. It's good to have just should be off by default. 15:07:59 <bcoca> alongchamps: i disable moslty cause then 'auto completion' requires 1 more character 15:08:14 <bcoca> k, think that passes, unless someone oposes? 15:10:28 <bcoca> #topic https://github.com/ansible/ansible/issues/52354#issue-410909935 15:10:47 <bcoca> @sivel https://github.com/ansible/ansible/pull/52581 for retry, you had review, i think it was addressed (mine was) 15:11:11 <bcoca> @cedwards 15:11:20 <sivel> -1 on XDG_CONFIG 15:11:42 <bcoca> lets hear him out before we vote 15:12:07 <bcoca> but there is strong opposition from core on this one 15:12:15 <sivel> bcoca: I approved 52581 15:12:44 <sivel> I had requested changes simply to force waiting for an IRC discussion 15:12:47 <bcoca> a) its linux only standard, b) not all linux distros follow this convention c) its non trivial change 15:13:21 <alongchamps> also windows and MacOS machines aren't going to necessarily follow that 15:13:31 <alongchamps> (I'm not sure if either of them do now) 15:13:49 <bcoca> @alongchamps covered in 'linux only' 15:14:04 <agaffney> can a user use an env var if they set their own remote_tmp? 15:14:32 <bcoca> yes, but the standard implies more than just tmp files 15:14:54 <bcoca> things like roles, user plugins, etc use .ansible/ as well as 'control persist' .. all configurable, but user would have to do manually 15:14:57 <bcoca> also local_tmp 15:15:00 <sivel> It's more trouble than it's worth are my 2c 15:15:16 <agaffney> sivel: agreed 15:15:26 <bcoca> so its possible to do for most dirs, but not all, and i also agree, not worth the time it takes 15:15:50 <sivel> seems like a no show in any case 15:15:54 <bcoca> once we implement 'platform' a user could have a 'xdg_compliant_linux.yml' to set those defaults 15:16:25 <bcoca> yep, i'll bring issue up next meeting, but he needs to have very compeling case from what we've discussed 15:16:44 <bcoca> @nitzmahone u alive? 15:17:22 <bcoca> #topic https://github.com/ansible/ansible/pull/52032 15:17:30 <bcoca> give assert a 'quiet' option 15:17:51 <bcoca> i dont really see the case, .. if i add an assert i WANT noise .. but im also not opposed since this is an OPTION 15:18:29 <felixfontein> bcoca: there has been a good example on the ansible-project mailinglist (by the PR author), he had assert with loops, and every output contained the full item (which was *a lot* of noise) 15:18:52 <felixfontein> using loop_control/label didn't really help, since verbosity prints the whole item anyway 15:19:21 <felixfontein> the only thing which helped was pre-massaging the thing to loop over so it only includes the things necessary for the assert conditions, but that's very tedious 15:19:29 <bcoca> as i said, not opposed, i would probably not use assert the same way the user does, but htat is just me 15:20:27 <agaffney> this same problem exists with debug, but the option would probably be less useful there, since it would squash all output 15:20:44 <felixfontein> yep 15:20:47 <bcoca> i really dislike the 'always verbose' flag .. but that is diff issue 15:20:56 <bcoca> debug is a pain because of it 15:21:23 <agaffney> debug unfortunately relies on it to function 15:21:36 <felixfontein> I wouldn't use debug in a loop anyway, but just output the whole structure (whereas looping is needed for assert) 15:22:01 <bcoca> its not needed, just useful in many cases 15:22:15 <bcoca> anyone actually against this feature? 15:22:24 <agaffney> perhaps another mechanism could be created for debug (or whatever) to signal to the callback plugin that some output should be displayed, rather than just using verbosity to show everything 15:22:44 <bcoca> main reason that is used is for 'respect newlines in output' 15:22:51 <bcoca> which should be diff settings 15:23:26 <sivel> I am +0. Really a meh 15:23:33 <bcoca> im 0 15:23:35 <sdoran> I didn't really see the use for it. 15:23:38 <sdoran> +0 15:23:51 <agaffney> +0.5 15:24:40 <bcoca> i dont see it adding too much complexity or problems so with a +1.5 i think it pases 15:24:44 <agaffney> I'd prefer a different mechanism like I talked about above, but that is more involved 15:24:50 <felixfontein> +1, once had a case where I would have liked it 15:24:54 <bcoca> agreed, we can change that later 15:25:04 <bcoca> felixfontein: he, had coutned you as +1 already 15:25:23 <shertel> +.5 15:25:29 <felixfontein> I like the different mechanism too, but I think that's for a later ansible version, 2.8 might be too close (for the work involved in adding that) 15:25:36 <felixfontein> bcoca: ok thanks ;) 15:25:59 <bcoca> #topic https://github.com/ansible/ansible/pull/46728 15:26:05 <bcoca> @raktajino ? 15:26:31 <bcoca> ^ agaffney this basically makes unixy kind of 'actionable' 15:27:18 <agaffney> does unixy not inherit from default? there are already options/logic for this there 15:27:31 <felixfontein> bcoca: thanks for merging! 15:27:40 <agaffney> I'm on my phone, so I can't easily look at the code 15:27:40 <bcoca> display_ok_hosts 15:27:41 <felixfontein> I have to run to catch a train, see you later this evening ;) 15:27:49 * bcoca waves 15:27:58 <bcoca> agaffney: are you driving? 15:28:53 <agaffney> no, the wife is right now :) 15:28:58 <raktajino> hi sorry here now 15:29:25 <bcoca> he, was about to table it and put note in PR, see above, there is display_ok_hosts=true|false in default callback, you could just use the same options 15:30:14 <raktajino> i'd be glad to go the display_ok_hosts / display_skipped_hosts the way the default callback is doing 15:30:35 <raktajino> i think i made this PR before i spotted those changes 15:30:36 <bcoca> idk if that is a doc_fragment, but might be worth doing as such 15:31:41 <bcoca> hmm, docs for unixy say its already an option ... probably not correctly implemented 15:31:50 <bcoca> so its more of a bugfix at this point 15:31:59 <raktajino> Probably not. Do you just want me to match waht default is doing for these things? 15:32:04 <bcoca> it is importing the 'default' shared options 15:32:21 <bcoca> yeah, if its using default options .. it should implement them 15:32:35 <raktajino> 👍 will do, thank you 15:32:47 <bcoca> note: when adding stuff to default callback, ensure all others sharing the fragment also have that option 15:33:04 <bcoca> #topic https://github.com/ansible/ansible/pull/32214 15:33:14 <bcoca> akasurde? 15:34:26 <dag> whoops, missed the meeting 15:34:58 <bcoca> no worries, we assigned all the work to you 15:35:22 <bcoca> devyani7 ? 15:35:29 <devyani7> bcoca, hi o/ 15:35:36 <bcoca> #topic https://github.com/ansible/ansible/pull/45997 15:35:37 <dag> :-) 15:35:52 <devyani7> hi all... 15:35:55 <jtyr> hello 15:35:57 <devyani7> so I wrote the gather_facts module to get the status of gluster self-heal and rebalance operations 15:36:17 <devyani7> it now sends a dictionary of the files that are still in process of the respective selected operations 15:36:30 <devyani7> undergoing the operations* 15:36:43 <bcoca> https://github.com/ansible/ansible/pull/49399 <= this might also interest you 15:36:43 <devyani7> I had got few review comments that I have addressed 15:37:02 <bcoca> seems akasurde is pending on rereview 15:37:04 * devyani7 clicks 15:37:06 <dag> devyani7: This would be best to check with other Mac users (macOS Working Group) 15:37:20 <dag> ansibot didn't identify this as macos-related so the WG was not involved 15:37:44 <bcoca> dag: wrong ticket 15:37:45 <devyani7> dag, not sure I get the context of mac here? 15:37:57 <dag> bcoca: owh 15:38:00 <bcoca> we moved on from that topic due to noshow 15:38:10 * jtyr has some open floor questions. Please ping him when the time comes... 15:38:10 <dag> carry on :) 15:38:58 <bcoca> devyani7: mostly lgtm, i would jsut wait for asakurde to rereview 15:39:19 <devyani7> bcoca, alright. thanks. 15:39:25 <bcoca> #open floor 15:39:32 <bcoca> #topic open floor 15:39:37 <jtyr> me me me 15:39:41 <bcoca> https://github.com/ansible/ansible/pull/49801 <- i know dag wants this 15:39:51 <jtyr> https://github.com/ansible/ansible/pull/51353 15:40:19 <bcoca> jtyr: one at time 15:40:33 * jtyr waiting ... 15:40:34 <bcoca> anyone against/for the 'non moustached templating'? 15:41:20 <agaffney> bcoca: my only "complaint" is that it will confuse users, but that's not a reason not to merge, especially since it's optional to use 15:41:32 <dag> On a weekly basis I have a need for this to avoid triple-quoting 15:41:37 <bcoca> that is my fear also, but it does make playbooks look prettier 15:41:40 <sivel> I am a meh 15:41:46 <bcoca> and yes, makes quoting a LOT simpler 15:41:50 <sivel> also, you can avoid triple quoting by using | in yaml 15:41:53 <sivel> or > 15:42:00 <agaffney> ^^ 15:42:12 <agaffney> I routinely use that trick 15:42:14 <jtyr> +1 for the 'non moustached templating' 15:42:29 <sivel> I mean if I am being honest I am a -1 15:42:44 <agaffney> +0 15:42:44 <sivel> I care more than just meh 15:42:49 <dag> +1 15:43:31 <bcoca> sivel: any reason other than 'we already have other ways to do it'? 15:43:49 <bcoca> which is mostly enough for me, but its -1/+2 at this point 15:44:28 <sivel> It's unnecessary syntactic sugar, that may very well make understanding playbooks more complicated 15:44:36 <bcoca> main reason i wrote it was to save myself typing {{ }} 15:44:36 <sivel> It also may further complicate things for awx/tower 15:44:53 <bcoca> how so? 15:45:02 <sivel> as users will no doubt try to provide syntax like that in the vars fields 15:45:13 <sivel> just a thought 15:45:16 <bcoca> ah, but that wont work at all 15:45:19 <sivel> but I find it less clear 15:45:33 <bcoca> hmm, more commiters want to weigh in? 15:45:37 <raktajino> you know people will be upset when they learn they can't do this in vars fields 15:45:49 <raktajino> i mean, that is also not necessarily a reason not to merge, just worth noting. 15:45:56 <sivel> shertel sdoran nitzmahone ? 15:46:02 <sivel> any of you weigh in here too? 15:46:04 <shertel> +0, I don't have strong feelings about it 15:46:05 <sdoran> I am -1 to this. 15:46:13 <cyberpear> In these cases, I usually just do '>-' and put it on the next line... 15:46:48 <bcoca> k, so tie, .. im still not sure which way to vote 15:46:49 <agaffney> maybe we just need an official "tips and tricks" page with things like that 15:46:51 <sdoran> I have never really like the `!foo` in fields. They definitely make playbooks a bit harder to reader. 15:46:57 <bcoca> agaffney: good idea 15:47:00 <dag> Why would this not work in vars-fields, the integration tests do it 15:47:03 <sivel> sounds now like -2/+2 15:47:04 <sdoran> Because you have to go look up what that special syntax does. 15:47:11 <sivel> and a bunch of 0s 15:47:12 <bcoca> dag: its a webform and not real yaml parser 15:47:19 <dag> I am sure you can ring up some Red Hat people to tip the odds over ;-) 15:47:26 <bcoca> he 15:47:34 <alongchamps> it looks like the meat of it changes {{ testvar }} to !j testvar which to me seems more confusing 15:47:42 <alongchamps> from what I gather on the ticket 15:47:44 <dag> bcoca: what is a vars field ? I mean is it not `vars:` ? 15:47:56 <dag> is it AWXTower related ? 15:48:15 <bcoca> dag: no, aws/tower users webforms to allow users to create vars .. already an issue when they try to do !vault in the value, since its not really using yaml to store those in psql 15:48:15 <agaffney> dag: is there a reason you can't use the YAML block syntax to deal with triple quoting issues? 15:48:24 <sdoran> @alongchamps Yup. And that is just odd. And it has the potential to result in playbooks littered with `!j` all over the place. 15:48:31 <sivel> I'm trying to round up more people 15:48:38 <alongchamps> ok then based on that understanding, I'm -1 15:48:39 <sdoran> To avoid writing `"{{ foo }}"`. 15:48:42 <bcoca> the only other issue !j 'helps' with is {{ }} escaping, but !unsafe is already there for most cases 15:48:43 <dag> bcoca: so we should not have allowed !vault :-) 15:49:01 <sivel> honestly !vault is probably more trouble than it's worth ;) 15:49:02 <bcoca> dag: we alllowed it casue there is no other way of doing it, being persuaded by | 15:49:06 <dag> littered with !j 15:49:09 <bcoca> already handling most escape issues 15:49:12 <dag> djee 15:49:25 <dag> now it's litteed with '{{ }}' :-) 15:49:40 <sivel> I'm feeling like I'm not going to get any more people here right now 15:49:47 <sivel> Thursdays are often hard due to the "early 15:49:48 <sdoran> dag: touché. But '{{ }}' is at least a standard syntax, not specific to Ansible. 15:49:50 <sivel> " time 15:49:51 <cyberpear> It does save a single char in the trivial case '"{{ ' and ' }}"', but the escaping help makes it save more chars 15:50:25 <sivel> Sounds like we don't have concensus 15:50:29 <dag> sdoran: only for jinja, the point is that with !jinja we can offer alternative template engines 15:50:34 <bcoca> its a tie, and im undecided 15:50:53 <sivel> ew, that makes me hate it even more. No more templating engines 15:50:55 <dag> gundalow approved 15:51:08 <sdoran> dag: Other templating engines? That hurts my head. :) 15:51:09 <bcoca> dag: er .. no, we can have other template modules, i really dont want more templating engines inside core 15:51:31 <dag> well, if you guys think Jinja is the best thing ever, then there won't be another template engine added 15:51:39 <dag> but I don't believe Jinja is a very good template engine 15:51:48 <dag> and I hope something better comes along at some point 15:51:50 <sivel> jinja is the defacto standard in the python world 15:51:52 <alongchamps> if the door is opened to more templating engines, then more will probably come 15:51:57 <bcoca> i dont think its best thing ever, but i have not seen much better one 15:52:16 <sivel> in fact many other languages have said they wished they had something like jinja, called out by name often 15:52:19 * jtyr is making a note - ERB is coming to Ansible ... 15:52:22 <bcoca> ^ not just code wise, but also distributed in most OSs 15:52:31 <dag> sure, today 15:52:32 <maxamillion> jtyr: please no 15:53:00 <bcoca> dag: open to better engine tmrow, but it must be prevalent in most 'desktops' our users are likely to use 15:53:10 <agaffney> dag: it's decent for its intended purpose (HTML), but not as great for the ansible use case 15:53:21 <dag> let's discuss the "other template engine" when there is one, will we ? :) 15:53:22 <bcoca> jinja2 fits that bill, i have other templating i would use serverside ,but alas its not as easy to do that with clients 15:53:46 <sivel> in any case, we are going off into the weeds 15:53:58 <sivel> With no concensus, we should move on 15:54:05 <bcoca> and im still undecided, but leaning to -1 at this point 15:54:25 <dag> it's a virus 15:54:31 <bcoca> ? 15:54:36 <sivel> I'll infect the world! 15:54:51 <dag> in the PR gundalow and akasurde approved too, remind me to make sure they are in the next meeting 15:55:01 <dag> (and have no contact with other Red Hat people in the meantime) 15:55:26 <agaffney> when even the PR author is leaning toward -1... 15:55:40 <sivel> bcoca: should we try to fit in one more open floor topic? 15:55:43 <bcoca> agaffney: i wrote package and i was a strong -1 for that 15:55:46 <bcoca> also telnet ... 15:55:49 <agaffney> heh 15:56:01 <bcoca> sivel: if we can discuss in <5mins 15:56:02 <dag> agaffney: https://github.com/ansible/proposals/issues/101 15:56:02 <nitzmahone> bcoca: still need me? (sorry, this meeting is right in the middle of kid->school time) 15:56:15 <dag> bcoca :-D 15:56:18 <sivel> bcoca: likely not 15:56:25 <bcoca> nitzmahone: how do you feel about !j or !jinja2 to remove need for {{ }} 15:56:42 <bcoca> https://github.com/ansible/ansible/pull/49801 15:57:28 <bcoca> agaffney: i dont only author things i want, i sometimes try to give people what they ask for to show them its not what they need .. and sometimes it still gets merged ... 15:57:59 <jtyr> never my case ;o) 15:58:11 <dag> bcoca is a giver 15:58:38 * dag needs to get kids from school 15:58:48 <dag> nitzmahone's kids :-) 15:58:58 <bcoca> i try to compromise when i see a possible solution .. reason we have 'gathering' after dag and MPD spent 3 weeks fighting about it 15:59:01 <dag> alternate universes 15:59:13 <sdoran> Thanks for your input and discussion, dag. 15:59:42 <nitzmahone> see also: `package` action ;) 16:00:17 <bcoca> k, will try to bring up next meeting, see if more input/votes give us clear directive, at this point im still undecided, which i think means there is no clear winner 16:00:29 <bcoca> @nitzmahone alreayd mentioned, please stop displaying my shame! 16:01:27 <nitzmahone> yeah, I'd need to think through that one; in general I think I like the idea, esp for basic "dict key = {{ template value }}" scenarios 16:01:40 <jtyr> bcoca: time for https://github.com/ansible/ansible/pull/51353 ? 16:01:59 <nitzmahone> ps, don't be a creeper, dag ;) 16:02:20 <bcoca> #topic https://github.com/ansible/ansible/pull/51353 16:02:24 <bcoca> jtyr: no, but lets try 16:02:29 <jtyr> ;o( 16:02:41 <jtyr> it needs some love ... the current output is horrible ... 16:02:57 <bcoca> idk that the PR makes it better or worse imho 16:03:10 <sivel> bcoca: I am recalling we were not in favor of it in our triage meeting 16:03:14 <sivel> pretty much collectively 16:03:16 <jtyr> it makes it better, for sure ... 16:03:18 <bcoca> for 'nice graph' there is ansible-inventory-grapher which does require extra graphic libs 16:03:30 * nitzmahone waits for "ansible-inventory output plugins" ;) 16:03:34 <sivel> In fact, multiple people actually said they thought the non-unicode version was less readable 16:03:42 <bcoca> @jtyr yeah, now that sivel mentions, many people thought it was not an improvement 16:03:43 <sivel> and we were against another flag offering --unicode 16:04:09 <jtyr> sivel: I can change soem characters to make it more readable ... 16:04:24 <sivel> I don't find the current version not readable 16:04:47 <jtyr> the current version has too many vertical lines ... 16:05:04 <sivel> why do you hate vertical lines?! 16:05:10 <shertel> The ASCII is harder to read but I love the unicode output 16:05:12 <jtyr> it makes the output less readable if you have the extra vertical lines there 16:05:47 <jtyr> sivel: it should look like the "tree" command in Linux ... 16:05:50 <nitzmahone> if a group's children exceed a screenful (or are very long) the extra vertical lines help, but I agree for small inventories 16:06:01 <jtyr> lines only where the branch continues ... 16:06:23 <nitzmahone> yeah, I can definitely see arguments for both cases 16:06:24 <bcoca> i made it look like tree command on BSD 16:06:52 <jtyr> BSD sucks ... everybody knows that ... this is why there is Linux ... ;o) 16:06:57 <bcoca> if your graph exceed screen .. you should not be using graph 16:07:38 <nitzmahone> I'm kinda +0.5; if anything, I'd rather a generic format argument that we could add other formats to (or, actually, format plugins, heh), rather than adding new args ad nauseum 16:07:39 <jtyr> bcoca: if the graph exceeds screen then there is something wrong about the inventory ;o) 16:07:58 <nitzmahone> so like `--format=unicode` or whatever 16:07:59 <bcoca> jtyr: not really, people do have 10k hosts and grouping gets complex 16:08:23 <bcoca> at one point i was goint to do --template=json|yaml|graph 16:08:34 <jtyr> bcoca: those people definitely don't use ansible-inventory to visualize their inventory 16:08:36 <bcoca> and let users define their own jinja2 template 16:08:37 <sdoran> I think I'm with @shertel: I think the output should look like `tree` with less vertical lines. 16:08:41 <bcoca> jtyr: that is my point 16:09:35 <sdoran> I don't think it should be another option, though. It should just be the default, unless that breaks something. 16:09:36 <bcoca> ansible-inventory-grapher gives you nice image for complex groups/relationships and scales better for larger inventories (just be prepared to have lots of ram if you do on 10k hosts) 16:09:48 <jtyr> sdoran: tree is using unicode characters only ... ;o) 16:09:55 <bcoca> sdoran: not all terminals handle unicode output 16:10:17 <bcoca> jtyr: only if your terminal supports unicode 16:10:18 <shertel> I prefer the current default though, so I'm split. +0 16:10:21 <bcoca> it uses ascii otherwise 16:10:24 <jtyr> bcoca: people need nice visualization even in the console ... not only in a picture (need to download and open to see ...) 16:10:50 <bcoca> jtyr: you can see images in terminal, also .. downloading implies its on other machien, image is local 16:11:03 <bcoca> grapher is not remote tool, its another cli 16:11:22 <jtyr> bcoca: nice cli output is important ... 16:11:47 <bcoca> 'nice' is subjective 16:11:48 <nitzmahone> yeah, unless we add some smarts (and knobs to turn to explicitly return to the old format) I wouldn't be in favor of changing the default, but not opposed to having it as an option 16:11:52 <jtyr> bcoca: how do you detect if your terminal uses unicode font? 16:12:30 <nitzmahone> terminfo fun probably 16:12:40 <jtyr> hm 16:12:56 <bcoca> you can chekc term and locale info, but even that is not 100%, mostly its 'display unicode and see if it renders' 16:12:58 <nitzmahone> go take apart bsd tree and see what they do- IIRC it falls back on elderly terminals 16:13:20 <nitzmahone> (hence why smarts are fine, but need a knob to change it if that falls down) 16:13:25 <jtyr> bcoca: so how "tree" is doing it? 16:13:46 <bcoca> probably looking at term and seeing if 'xterm' 16:14:44 <bcoca> locale's charmap is probably best bet 16:14:55 <jtyr> let's vote, people ... I promise 1 beer to everybody who gives +1 ... ;o) 16:15:18 * bcoca has microbrewery in basement 16:15:45 * jtyr will send yeast to bcoca if he gives +1 16:16:25 <bcoca> -1 i think the default replacement is worse, unicode might be nicer but i really don't think we need it 16:16:47 <jtyr> bcoca: I can still amend some characters to make it look better 16:17:01 <jtyr> te vote should be about removing the useless vertical lines 16:17:17 <sivel> -1 16:17:22 * nitzmahone conditional +1 if generic format arg, and (not the default or new smart default w/ config knobs) 16:17:36 <shertel> I'd rather not change the default so even though I like how it looks with the unicode flag better, -1 16:18:22 <bcoca> jtyr: so seems current PR wont go through, if you can take the feedback and come back with ammended we can discuss again 16:18:35 <jtyr> ok ;o( 16:18:41 <bcoca> #endmeeting