[07:19] PR operator#400 opened: Fix trivial typo in docstring [08:10] !!!! [08:10] Good Morning [08:11] bthomas: goooooooooooooooooooooooooooooooooooooooooooooooood morning! [08:14] bthomas: does erc do colours? [08:14] Morning Chipaca. Yes ERC does colours by default [08:15] phew [08:15] What really love is it supports LaTeX too. I recently switched to ERC from Pidgin after finding this out. [09:01] bthomas: right there insid erc? [09:01] inside* [09:02] Chipaca: You mean LaTeX . If so yes it is using ERC-TeX https://www.emacswiki.org/emacs/erc-tex.el [09:02] neat [09:02] I changed the delimiter to $$ from $ since $$ is what other IRC clients seem to use for TeX markup [09:03] I presume you have seen https://github.com/millejoh/emacs-ipython-notebook [09:04] and https://sites.google.com/site/imaximaimath/ which is now part of official upstream [09:19] i had not, i will add them to my interesting-stuff backlog :) [09:43] ¡Muy buenos días a todos! [10:01] नमस्ते facubatista [10:02] hola bthomas ! [10:11] Chipaca: I am seeing harness.update_config values set in one unit test persisting in a different unit test even though I have done self.addCleanup(self.harness.cleanup) in setUp(). Is this because I have not used the "unset" argument to update_config ? [10:11] bthomas: sounds like you're carrying the stored state database between tests [10:12] bthomas: this shouldn't happen (tm) [10:14] Chipaca: how to I clear StoredState() between tests ? [10:15] bthomas: it's an in-memory sqlite, it should not be surviving between tests [10:15] I do see if I add unset argument to update_config, I can resolve the problem. Is this good enough for now ? [10:15] bthomas: i'd even say it can't [10:16] hmmm [10:16] bthomas: something deeper is wrong, so no [10:16] bthomas: this is using harness, yes? [10:16] yes harness [10:16] Chipaca: ok let me dig, let us catchup after standup if you have time. [10:17] bthomas: that's a long time away :) but sure [10:17] Chipaca: I split my time between writing documentation/unit tests for charm and writing documentation for charmhub. [10:17] ok [11:20] I will be understanding the reactive Charm Hook docs (https://discourse.juju.is/t/charm-hooks/1040) and adapting it for Operator Charms. I am writing my draft in Markdown so that it can be imported into a google doc. If either of this sounds like a bad idea please let me know. [11:32] bthomas, google docs understand markdown? [11:33] awesome [11:33] facubatista: I googled and there seems to be options to import markdown [11:34] in any case I can always cut/pastes. Using my familar editor and familiar markup for now. [11:34] oh, nice! it has "export" too? but we'll end up in Discourse, so I don't want to loose that markdown [11:34] ok I will save it. [11:34] bthomas, I'm writing in markdown too, I just don't want to lose it [11:35] got it [11:57] facubatista: are we having the bug revue today, or is it docs docs docs? [11:58] copy-pasting from google docs into discourse preserves formatting (but it's slightly less pretty than hand-written markdown) [11:58] Chipaca, let's have it, it should be short [11:59] ok [12:12] Issue operator#398 closed: Improve opslib functionality [12:24] facubatista: https://k8syaml.com/ fwiw [12:28] nice [12:29] facubatista: yes but also an idea of the size of the problem :) [12:30] not a problem! but an opportunity :p [12:45] facubatista: you say potato i say ghoughpteighbteau [12:46] ja [13:16] Looks like I have introduced a bug in my prometheus yaml by a recent code change. So I will switch track back to the charm and fix that before continuing on documentation. [13:24] bthomas, a bug in the yaml because of a code change? [13:24] ah, prometheus specific yaml? not cham's? [13:24] facubatista: looks like it [13:24] yep prometheus yaml [13:25] The yaml is generated by code. If we use yaml loaded from disk then I could have validated the yaml by using it to launch prometheus on the host. [13:26] o/ [13:26] bthomas, as it's being generated by code, you can test that code [13:26] hola jam [13:27] indeed [13:27] morning facubatista [13:27] morning jam [13:28] jam, question! when "dispatch" explodes in juju's face (because of a syntax error in the charm, *for example*), juju logs in DEBUG the problem: https://pastebin.canonical.com/p/gVnm9SsDV2/ [13:28] jam, how difficult it would be that that error is logged in ERROR? [13:28] (so the user will see the problem by default, without needing her to get the model in DEBUG) [13:29] facubatista, IIRC, we log all of the stdout of a script at DEBUG, and we don't do anything special about content of that output [13:29] I don't think all stderr should end up at ERROR, maybe WARNING? [13:31] jam, I don't know if *all* stderr, but at least everything that was shown if the process not ends in 0? [13:31] or you log before knowing the final outcome? [13:31] s/you/juju/ :p [13:31] facubatista, that would imply buffering everything so that you could change the log level, which is possible but has its own risks [13:32] jam, which risks? we were thinking maybe about sending all stderr to a temp file and calling `juju-log` on that content, if retcode != 0 [13:32] (doing that in the dispatch script, I mean) [13:35] facubatista, do we know whether it is stderr or stdout? (I'm guessing err) [13:36] jam, stderr, as it's a standard "python crash" [13:38] facubatista: it sounds like dispatch should do this itself then [13:59] seems like I fixed bug. will test and push to github [14:05] * bthomas grabs coffee before getting back to writing eloquent prose for charmhub [14:28] Chipaca: Can I add a 20-30 min 1:1 at 5:00pm to your calendar today ? [14:38] bthomas: can it be at 4pm? [14:38] Chipaca: sure. Adding it now [14:59] facubatista, so Juju currently puts stdout and stderr into the same stream and then logs it all at DEBUG: https://github.com/juju/juju/blob/7901bce5eef92c2f7af11f0e38cb3f482a25e013/worker/uniter/runner/runner.go#L516 [15:00] I don't see why we couldn't split that [15:00] stderr feels more like Warning than Error to me, though tracebacks would be more Error. [15:01] jam, the detail is if you wait to have the process finished before logging (so you can decide based on its retcode) [15:52] https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html [15:52] * facubatista -> lunch [16:12] For a bit more info on the relations.. Both prometheus and grafana charms are deployed independently. However, "juju add-relation grafana prometheus" returns "ERROR no relations found" [16:13] It seems like the metadata.yamls for grafana [1] and prometheus [2] are not the issue as they have corresponding endpoints. [16:13] [1] https://github.com/justinmclark/grafana-charm-base/blob/master/metadata.yaml [16:13] [2] https://github.com/balbirthomas/prometheus-charm/blob/master/metadata.yaml [16:15] justinclark: are you providing any more arguments to the the add-relation command line other than application names ? [16:17] bthomas - just the relation names [16:17] In that case I do not understand how the two applications know which port and IP to use [16:18] justinclark: I will give this a try too. Could you try adding --via arguments to add-relation [16:18] justinclark: I am able to access the prometheus web page from my host system so I know it is serving an http api. [16:19] So the relation I'm struggling with is the juju relation itself. Regardless of the configuration that needs to happen between the two. [16:20] I have both apps deployed via juju and can access the grafana dashboard and even add the prometheus datasource to that manually. The problem is just the "juju add-relation" command. [16:21] bthomas: we can worry about how to set the relation data once we figure this out. Want to hop on a 1-1 call? [16:22] justinclark: ok will join stand up link in 30 sec [16:27] justinclark: your link froze and terminated [16:27] facubatista, we could do that, though it might be more straightforward if we just always put stderr into INFO/WARNING level, rather than conditional on return code. [16:31] justinclark: I have both grafana and prometheus charms running on my system [16:32] Okay - I'm about to rejoin the hangout [16:41] * facubatista is back [16:42] jam, my objective is that people will see errors in the called script by default [16:43] jam, so all stderr to info/warning, is fine (also to ERROR, as it's stdERR...) [16:43] if the charm/script is sending stuff to stdERR that is not an ERRor, well, that scrip/charm needs to be fixed [16:48] facubatista, well, stderr is for any content that you don't want in your output. eg 'curl' uses it for a progress bar [16:48] I don't think the "err" in stderr is that hard defined [16:48] yeap [16:48] that's why I'm fine with anything that shows the error to the user by default [16:49] (without needing to put the model in DEBUG, for example) [16:49] jam, shall I open an issue about this or you take it? [16:49] facubatista, I believe we already have a bug around it, i'll try to track it down, I was using you as a part sounding board for working through it. [16:50] jam, \o/ wonderful [16:50] facubatista, bug #1893993 [16:50] fwiw [16:54] jam, thanks [16:55] bthomas, about using google docs but keeping markdown... for me when I paste into google docs it eats all my newlines, does it happen for you too? [16:55] facubatista: I have not tried yet [16:59] bthomas, I'm not finding an "import" either [17:01] ah! "paste without formatting" doesn't eat my newlines [17:01] facubatista: import was external plugins. [17:02] thanks for the paste without formatting tip [17:49] * bthomas bbiab [18:11] PR operator#400 closed: Fix trivial typo in docstring [18:35] justinclark: I am back. Will be online for another hour or two. [18:50] bthomas: sounds good. I think I'm fairly close. The data is being passed correctly but for some reason isn't recognized by the grafana service. Possibly configuration issues but everything matches the grafana docs as far as I can tell. I'll keep you posted though [18:51] thanks justinclark : there is always the possibility of bugs in the prometheus code. Do message me at the slightest possibility of this so I can have a look. [18:52] Actually, I think it is working properly. [18:53] yay! [18:53] justinclark: there is a "monitor-k8s" option in the prometheus config, that [18:54] will make it gather monitoring data from the k8s cluster. I will try this tomorrow. If you are starved for data :-) try that. [18:59] PR operator#399 closed: Handle removal of non-existant relation data [19:00] I lied :( [19:00] * justinclark punts computer [19:03] :) [21:41] facubatista, to finish the thread we started here https://github.com/juju/juju/pull/11980 should address the tracebacks-by-default [21:41] PR juju/juju#11980: Change hook stderr output to be logged at WARNING level [22:26] jam, thanks