[10:28] <jam> morning all
[10:28] <jam> mup seems to be having a hard time
[10:29] <niemeyer> Yeah, my network seems to have had many hiccups overnight
[10:53] <facubatista> Muy buenos días a todos!
[10:58] <jam> morning facubatista
[10:58] <facubatista> hola jam
[11:10] <facubatista> jam, would you please help me to debug something?
[11:10] <jam> facubatista, certainly, what's up?
[11:11] <facubatista> I'm experimenting with this charm: https://paste.ubuntu.com/p/jvJdZ9mxdd/
[11:12] <facubatista> jam, see lines 76-80
[11:12] <facubatista> I have this charm deployed in a unit, apache2 deployed in other one
[11:12] <jam> ok
[11:12] <jam> Often during relation-joined the other side might not have had the chance to set any data yet
[11:13] <jam> you also want on.relation_changed for when they do change the data
[11:13] <facubatista> nice
[11:13] <facubatista> however, if I run
[11:13] <facubatista> juju add-relation bdv:server apache2:website
[11:13] <facubatista> I see
[11:14] <facubatista> unit-bdv-12: 16:48:34 INFO unit.bdv/12.juju-log server:4: [11:14] <facubatista> unit-bdv-12: 16:48:34 DEBUG unit.bdv/12.server-relation-joined [11:14] <facubatista> so far, so good (even if no really data there), the problem is other
[11:14] <jam> facubatista, btw, we should make sure that the framework itself logs the juju hooks (at least at DEBUG, possibly at INFO), so that people don't have to instrument their own handlers.
[11:14] <jam> facubatista, so the rdata object is a wrapped dict
[11:14] <jam> you can do print(dict(rdata)) if you want to see the items
[11:15] <jam> We could probably improve the __str__ of RelationDataContent
[11:16]  * facubatista improves a little the code
[11:17] <facubatista> jam, btw, yes, logging in debug when the operator framework calls *my* code, and then when *my* coded ended (and how, possibly), would be great
[11:18] <jam> facubatista, I definitely think logging at DEBUG for every Juju event and whether or not there is a handler
[11:18] <facubatista> good idea
[11:18] <facubatista> jam, so, *the* problem I get is:
[11:19] <facubatista> jam, in other terminal, I issue: juju debug-code bdv/12
[11:19] <facubatista> (note that in my code the .breakpoint() call is commented out)
[11:20] <facubatista> then I go and I add the relation again (I had it removed before, of course): juju add-relation bdv:server apache2:website
[11:21] <facubatista> jam, and now in the logs I see this lot of times (every couple of seconds, until I remove the relation so it stops):
[11:21] <facubatista> unit-bdv-12: 08:18:27 INFO juju.worker.uniter.runner executing server-relation-created via debug-hooks; unknown/invalid hook handler
[11:21] <facubatista> unit-bdv-12: 08:18:28 ERROR juju.worker.uniter.operation hook "server-relation-created" (via unknown/invalid hook handler) failed: exit status 1
[11:22] <jam> facubatista, so unknown/invalid hook handler for relation-created is interesting. can you look at what is in hooks/* there should be a symlink for hooks/server-relation-created according to the above complaint
[11:22] <jam> facubatista, it *sounds* like there is a script there that has an invalid #! line, but we'd want to check.
[11:22] <facubatista> let me ssh into the machine to see what is really there
[11:23] <facubatista> jam, where the charm is located inside the units?
[11:23] <jam> facubatista, /var/log/juju/agents/unit-bdv-12/charm IIRC
[11:23] <jam> sorry
[11:24] <jam> not /var/log
[11:24] <jam>  /var/lib
[11:24] <facubatista> yes
[11:25] <facubatista> jam, I don't have a server-relation-created hook
[11:26] <jam> facubatista, are you using 'dispatch' ?
[11:26] <jam> (the error doesn'at seem to say that)
[11:26] <jam> ah, I'm wrong
[11:26] <facubatista> jam, nop, our framework still doesn not support it
[11:26] <jam> executing server-relation-created via debug-hooks
[11:26] <jam> that last line is important
[11:27] <jam> its trying to run relation-created as a debug-hook shell
[11:27] <facubatista> note however that without the `juju debug-code` call in other terminal, it works!
[11:27] <jam> facubatista, indeed. the key there is the "via", even if you don't have a shell script, we still drop you into a debug hook session for all Juju events.
[11:28] <jam> facubatista, I assume this is with juju edge 2.8b1 ?
[11:28] <facubatista> jam, 2.8-rc1-genericlinux-amd64
[11:29] <jam> right, so ege
[11:29] <jam> edge
[11:30] <facubatista> I'm ok with getting into the "waiting mode" where I called `juju debug-code`, I just expect that nothing happens there as I don't have a breakpoint in my code, but the hook/event to work just fine as before
[11:30] <facubatista> or I'm missing something?
[11:30] <jam> facubatista, it sounds like a bug in juju that it either:
[11:30] <jam> a) doesn't know how to invoke relation-created via debug-code
[11:30] <jam> b) the framework is getting relation created, but then exiting badly
[11:31] <facubatista> I don't think the framework gets to do anything here, as I don't have the hook in the hooks/ dir
[11:31] <jam> facubatista, /snap/bin/juju --debug version
[11:31] <facubatista> jam, I can try *adding* the hook
[11:31] <jam> just to make sure that I'm running the same code as you
[11:32] <facubatista> jam, 2.8-rc1 3596 7507bb48aaf8d93cde47977b895d09d33f616e53 gc go1.14.2
[11:34] <jam> facubatista, ok, that is latest/edge
[11:35] <mup_> Issue operator#249 opened: Let's instrument all registered methods' calls <Created by facundobatista> <https://github.com/canonical/operator/issues/249>
[11:40] <jam> facubatista, I'm seeing if I can reproduce
[11:40] <jam> also, roadmap in 5
[11:40] <facubatista> yeap
[11:47] <jam> facubatista, I think I figured out the bug in Juju
[11:48] <jam> the issue is with debug-code
[11:48] <jam> If you are in debug-hooks session, then all hooks get intercepted by debug-hooks
[11:48] <jam> however, under 'debug-code' they get intercepted *and then still run*
[11:48] <jam> but if the file doesn't exist
[11:48] <jam> then you get this weird behavior
[11:48] <jam> I'll file a bug
[12:02] <jam> facubatista, https://bugs.launchpad.net/juju/+bug/1876290
[12:15] <facubatista> jam, thanks!
[13:23] <Chipaca> facubatista: feliz día che
[13:25] <facubatista> Chipaca, gracias, igualmente :)
[13:36] <facubatista> jam, FTR, adding the hook 'server-relation-created' unblocked me
[13:36] <jam> facubatista, sure. the bug is that if you run 'debug-code' then we blindly try to run all hooks, even if they don't exist
[13:47] <facubatista> jam, have 10' to help me understand some basic juju? a short HO would be great
[13:47] <facubatista> thanks
[13:54]  * facubatista bb ~10'
[14:04] <jam> facubatista, I'm happy to. let me know when you're around. dinner is coming up soon, but food hasn't arrived yet
[14:08] <jam> facubatista, food just arrived. I'll ping you when dinner is done
[14:13] <facubatista> jam, ack, thanks
[14:31]  * Chipaca reads how to run k8s on old laptops and suddenly has a bigger backlog
[14:46]  * facubatista brb
[14:47] <jam> facubatista, I'm back
[15:07] <facubatista> jam, me too
[15:08] <facubatista> jam, https://meet.google.com/veq-yfqm-kdk ?
[15:08] <jam> facubatista, joining standup
[15:08] <jam> but I can meet you there
[15:22] <Chipaca> "this will enable you to connect to your cluster using Kubectl from the internet." ← sounds like a bad idea to me
[15:37] <jam> Chipaca, Twitch Plays Kubernetes ?
[15:38] <jam> facubatista, question about 'juju debug-code'. What would you want to happen if you don't have a hook implemented. Should juju just ignore the event ?
[15:38] <jam> debug-hooks currently drops you into the debugger. and if you are using 'dispatch' then the operator framework will interrupt it
[15:39] <jam> I think the most sensible thing is to just skip the script if it doesn't exist. Since there is no way to 'drop into a breakpoint' of a hook that doesn't exist.
[15:39] <jam> The other option is that you drop to 'bash' like you do for 'juju debug-hooks'b
[15:39] <jam> maybe I can say that more clearly.
[15:40] <jam> if you run 'juju debug-code unit/0' and it doesn't have 'dispatch' and it doesn't have 'hooks/install'.
[15:40] <jam> when Juju wants to run 'install'
[15:40] <jam> should it
[15:40] <jam> a) just ignore it
[15:40] <jam> b) drop you into a bash prompt
[15:40] <jam> like we do for 'juju debug-hooks'
[15:42] <Chipaca> jam: what does 'ignore it' look like to the user?
[15:43] <Chipaca> if it's "don't even start the shell", or "drop out of the shell as soon as it figures this out with a message explaining things", then that sounds alright
[15:43] <jam> Chipaca, so today, if you run 'juju debug-hooks' and a given hook isn't implemented, you end up in a bash shell, with a prompt that says you are debugging 'install'
[15:43] <Chipaca> if it's "leave the user looking at a shell forever" then no :)
[15:44] <jam> Chipaca, likely it is 'blip a shell that never gets focus because it exits too quickly'
[15:44] <jam> debug-code is trying to hand off to the charm for it to handle the event
[15:44] <jam> but if the charm doesn't implement dispatch or the hook, then it has no way to 'handle the event'
[15:45] <jam> I'm trying to figure out whether dropping into bash is better, because it lets the charmer know that an event did happen that they weren't handling
[15:45] <jam> (which is what debug-hooks currently does)
[15:45] <Chipaca> we could also detect this in the framework and have a 'handle anything' thing that gets called in this scenario, which starts with a message to the user about how they're not seeing their code because it doesn't exist
[15:45] <jam> The *current* debug-code behavior is that we spin throwing errors because we try to exec "" or something to that effect.
[15:46] <jam> Chipaca, 'handle anything' is just dispatch
[15:46] <jam> so we already have that handled
[15:46] <Chipaca> i meant a handler that only gets added for debug-code when there ins't an actual handler
[15:46] <jam> Chipaca, the particular issue is 'relation-created' because Dmitrii's patch hasn't landed, so we don't create hooks/*-relation-created yet.
[15:47] <jam> Chipaca, and neither has *your* patch landed, so we don't handle dispatch either :)
[15:47] <jam> I think dispatch fills the use case nicely. Because we already know that if you set 'juju debug-code --at hook'
[15:47] <jam> we can do whatever we want if you don't have an event handler registered for a Juju event.
[15:49] <facubatista> jam, if I'm not handling the event (no script, or no method registered, etc) I should get the same behaviour than handling the script but not having a .breakpoint() call in there... just nothing should happen, it should leave me there in the "waiting state"
[15:49] <jam> facubatista, if you have no breakpoint(), we 'run the hook in the background and log a WARNING'
[15:49] <jam> I believe is what we discussed.
[15:51] <facubatista> yes, we opened an issue for that
[15:51] <jam> facubatista, so in that case, we don't leave you in the "waiting state"A
[15:51] <jam> I was thinking to drop back to the debug-hooks implementation
[15:51] <jam> so that you are aware that your charm isn't implementing 'relation-created'
[15:51] <jam> otherwise during 'juju debug-code' you don't even see that it happened.
[15:53] <facubatista> from my developer perspective, it should leave me in "waiting" state so I can actually get the breakpoint on relation joined
[15:53] <jam> ah, you're saying not interrupt you but wait for other hooks to fire
[15:54] <facubatista> I mean, without `juju debuc-code` I see my function called, I add a .breakpoint() call there, with `juju debug-code` I should get a pdb
[15:55] <jam> btw, wordpress review in 5
[16:00] <jam> facubatista, Chipaca coming ?
[16:01] <Chipaca> yes
[16:01] <facubatista> yes
[16:19] <mup_> Issue operator#214 closed: Operator framework should support pod readiness event <Created by tcuthbert> <Closed by chipaca> <https://github.com/canonical/operator/issues/214>
[16:50] <jam> Chipaca, facubatista I'll be back around for the k8s charms meeting. for now I'm off to take the dog out
[16:50] <facubatista> jam, ack
[16:50] <Chipaca> i'm off to take myself out :)
[16:50] <Chipaca> see you all in an ahh
[16:55] <jam> one ahh later
[16:56] <jam> Chipaca, there are several people that I've heard during the pandemic pick up the phrase "I'm off to take myself out"A
[16:56] <jam> Walk the John
[17:03] <ballot> Hello !
[17:23] <Chipaca> ballot: hi!
[18:30] <jam> according to this: https://blog.questionable.services/article/kubernetes-deployments-configmap-change/
[18:31] <jam> changing a config map does *not* generate an event
[18:32] <jam> the end up including an env variable which is the hash of the config
[18:53]  * facubatista -> mate for the final part of the day
[19:39] <Chipaca> facubatista: https://mobile.twitter.com/JenMsft/status/1256007715425382400
[19:41] <facubatista> Chipaca, I love Gru
[19:42] <Chipaca> facubatista: :)
[19:46] <mup_> Issue operator#250 opened: Improve __str__ of developer exposed objects <Created by facundobatista> <https://github.com/canonical/operator/issues/250>
[19:52] <Chipaca> jam: have a great weekend, and see you Tuesday!