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