#smooth-operator 2020-04-27
<niemeyer> Good mornings
<facubatista> Muy buenos dÃ­as a todos!
<jam> morning facubatista and niemeyer
<facubatista> hola jam
<jam> plenary in 7
<jam> btw, Chipaca, there was some discussion about presenting in Blue Jeans and needing to use real Chrome and not chrome-from-a-snap. Something about BJ needing Flash and not being able to install that in a snap
<Chipaca> niemeyer, jam, facubatista, I've added a couple of things to our calendars
<Chipaca> jam: yeah, i still need to dig into that
<Chipaca> jam: that's part of the reason for me not diving straight into "let's each present a little bit" mode
<jam> you still have time, but you'll certainly want to try it out before Thurs
<Chipaca> yup
<jam> Chipaca, yeah, typically in a Roadmap we alternate through people, but that feels harder to do virtually
<jam> since none of us have BlueJeans experience.
<Chipaca> jam: facubatista: what browsers do you use/have already working?
<facubatista> jam, I failed to make chromium to use flash, will interact with meetings through the phone
<facubatista> Chipaca, ^
<jam> FF and Chrome
<Chipaca> facubatista: firefox doesn't work either?
<Chipaca> and that's just as a client, the onerous bit is when you present :-|
<Chipaca> sigh
<facubatista> Chipaca, didn't try firefox, as mails kept telling to use chrome/ium to have some interactivility
<jam> Chipaca, for "let's talk packaging" I have a conflict with a Juju session, but I probably don't need to go to that one.
<Chipaca> facubatista: chrome, not chromium, to be clear
<Chipaca> facubatista: for the client
<Chipaca> facubatista: to present, chromium and not chrome (????)
<Chipaca> but that's all hearsay
<facubatista> Chipaca, I'm on the phone already
<Chipaca> d'oh. half an hour later?
<jam> 1 minute to Opening Plenary
<Chipaca> facubatista: I'm asking because I'm thinking about our presentation, not because of this one
<jam> people are at least saying hello in bluejeans chat
<facubatista> grrr, I'm getting serious interruptions
<jam> I had a couple of blips from mark, but generally was smooth
<niemeyer> Yeah, works well for me as well
<facubatista> It's almost not working for me :( and my internet connection is fine: low ping, and speedtest is giving me >20Mbps
<facubatista> in international speed tests I get ~2.5Mbps, and I'm barely getting anything from bluejeans :(
<jam> Chipaca, so far the groups seem to just do the one presenter
<Chipaca> jam: yes but with a lot of the team there
<jam> Chipaca, indeed
<Chipaca> facubatista: have you tried in the browser instead of the phone?
<facubatista> Chipaca, yes, same
<jam> Chipaca, so you, you, you and you? You have multiple devices, right?
<Chipaca> :'(
<facubatista> (I thought it was my wifi)
<facubatista> I phone-dialed a local number, at least I have audio, but this doesn't scale for the whole week :(
<Chipaca> facubatista: did you get the prompt about switching to low-bandwidth mode on the desktop?
<facubatista> Chipaca, yeap, still sucking
<facubatista> this on firefox, however, couldn't make it work in chromium
<mup_> Issue operator#174 closed: Support application-version-set hook tool <Created by stub42> <Closed by jameinel> <https://github.com/canonical/operator/issues/174>
<mup_> PR operator#238 closed: ops/model.py: Unit.set_workload_version <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/238>
<jam> are we all back from our coffee breaks
 * facubatista doesn't see any other particular today to attend
<Chipaca> facubatista: me neither :) (except 1:1s)
<facubatista> Chipaca, do we have ours?
<Chipaca> facubatista: not this week unless you need it
<facubatista> Chipaca, nop, I'm fine
 * facubatista -> lunch
<jam> taking the dog out for an "early lunch" bbiab
<facubatista> do we have an example of a charm under operator framework that is registering a method to be called when an **action** happens?
<jam> facubatista, https://github.com/dshcherb/ceph-iscsi/blob/master/src/charm.py has 'create_target_action'
<jam> and add_trusted_ip_action
<facubatista> jam, line 123 there, `self.on` is charm.CharmEvents ?
<jam> facubatista, yeah, I believe so
<facubatista> jam, and where/how does it grow an `add_trusted_ip_action` attribute?
<jam> facubatista, https://github.com/canonical/operator/blob/master/ops/charm.py#L433
<facubatista> jam, thanks
<jam> np
<jam>  good night all, I hope you had a good first day. I'm off to sleep
 * facubatista eods
#smooth-operator 2020-04-28
<jam> morning all
<Chipaca> jam: morning!
<jam> Chipaca, I didn't expect to see you here so early :)
<Chipaca> jetlag :-|
<Chipaca> (turns out, it was stress all along)
<Chipaca> jam: working on the slides for our plenary now (sent you a link in the canonical irc)
<Chipaca> probably going to step away and have breakfast and other non-sprint stuff in a bit
<jam> Chipaca, sounds like a musical "it was stress, all a long"
<Chipaca> doo be doo be dooo
<jam> Chipaca, https://youtu.be/yOeUXEpxzcc?t=104
<niemeyer> Morning folks
<facubatista> Muy buenos dÃ­as a todos!
<jam> morning facubatista
<facubatista> hola jam
<Chipaca> facubatista: EventSetBase??
<Chipaca> facubatista: you probably want to merge master into #233, i guess?
<mup_> PR #233: Execute the registered methods to events under PDB if proper envvar is set <Created by facundobatista> <https://github.com/canonical/operator/pull/233>
<facubatista> oh, yes
<facubatista> Chipaca, pushed
<Chipaca> charmcraft#1
<mup_> PR charmcraft#1: Draft to show several characteristics <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/1>
<Chipaca> niemeyer: dunno if mup follows renames; if not, can you update its conf to look at ^?
<niemeyer> Chipaca: Will do, thanks for the note
<axino> hi
<axino> should I expect juju to fire a leader-elected hook when it first deploys a unit ?
<axino> it apparently did in 2.7.3, and doesn't do anymore in 2.8 beta1
<niemeyer> axino: Sounds like a bug..
<niemeyer> axino: First unit is the leader in general
<axino> (and I relied on that via self.framework.observe(self.on.leader_elected, self.configure_pod))
<niemeyer> axino: Is that you mean?  The first unit of an app?
<axino> niemeyer: yeah the first unit of an app
<niemeyer> axino: It should work.. jam?
<axino> juju deploy'ing a new app basically
<axino> my charm worked in 2.7.3, but not with 2.8 beta1
<jam>  axino I would expect leader-elected to fire, if something has changed there I would definitely file a bug w/ Juju
<axino> jam: ack, I will
<niemeyer> jam: Sounds worth looking deeper into it with axino.. it's a bug worth catching if something went wrong there
<jam> axino, I would expect relation-created to fire before leader-elected, in case you were looking for an exact order of hooks
<jam> and relation-created is new in 2.8
<axino> jam: nah, no relation here, this is a very basic charm without relation
<jam> axino, link and context in a bug is very much appreciated
<axino> jam: I know I know
<jam> axino, you've always done well, just helps to remind sometimes :)
<axino> :) np
<axino> jam: https://bugs.launchpad.net/juju/+bug/1875675 I think this is "just" hook ordering
<jam> axino, for juju 2.7.? (I think .6) and 2.8 Juju will now fire the Install hook, which is a point where the initial handlers can be registered.
<Chipaca> jam, facubatista, niemeyer, i think i'm going to cancel the wordpress k8s review session
<jam> I think firing leader-elected before 'start' is more expected behavior, as it is how non-k8s has worked for a long time
<facubatista> Chipaca, or move it
<jam> Chipaca, k. I was going to ask for a bit of a breather, but doing the review still seems worthwhile
<Chipaca> moved!
<axino> jam: hook ordering changed between 2.7.3 and 2.8 beta1
<axino> jam: at least one of leader-elected or config-changed (or upgrade-charm) used to fire after start, and now fire before
<jam> axino, non-k8s charms have always fired install, leader-elected, config-changed, start
<jam> I think 2.7.3 to 2.8b1 is making k8s act more like the rest of the system
<axino> jam: so should k8s charm use the "install" hook to "bootstrap" themselves ?
<jam> axino, however, #juju is better place to discuss this.
<jam> axino, yes 'install' should be used if it fires.
<axino> ok
<niemeyer> Chipaca: Thanks
<jam> axino, operator framework itself has a even for 'install' to do so
<niemeyer> Chipaca: The deck review today is on the late side.. can we put it inside the sprint window today or tomorrow?
<axino> jam: I think we have slides somewhere that lead us to use "start"
<Chipaca> niemeyer: I didn't realise you were invited to that
<Chipaca> niemeyer: that might be an oversight :)
<niemeyer> I'm surprised you think I wasn't :)
<Chipaca> niemeyer: i thought it was just me and sohini
<axino> jam: this appears to be https://bugs.launchpad.net/juju/+bug/1854635 !
<niemeyer> Chipaca: Can we get it moved inside the sprint window?
 * facubatista -> lunch
<Chipaca> niemeyer: trying to figure it out, there might be some confusion, sorry
<crodriguez> Can I get some advice about debugging k8s models with the operator framework? I'm not sure what is causing my charm to crash on the install hook, I only see this "application-mssql: 11:45:32 ERROR juju.worker.uniter.operation hook "install" (via explicit, bespoke hook script) failed: exit status 1"  in the juju debug-log, and I can't really debug with kubectl commands because the pods do not come up since it
<crodriguez> fails on install
<crodriguez> I looked this up https://discourse.juju.is/t/live-debugging-at-python-level/2914/4 but that's not provided on k8s models
<Chipaca> crodriguez: what juju version are you running?
<crodriguez> Chipaca: 2.8.beta-1
<Chipaca> jam: did the change to logs land in that?
<jam> crodriguez, I would imagine the operator pod is running, if you wanted to connect to it, since it isn't part of the application pod
<jam> Chipaca, the debug level changes did land in 2.8.beta1
<jam> crodriguez, so if you're using the latest operator framework, you should be able to set "juju model-config logging-config=DEBUG" and juju should show you more information about what was going wrong
<crodriguez> okay I'll try that thank you
<Chipaca> crodriguez: the if at the beginning of jam's statement is important :-D
<Chipaca> latest as in master from 6 days ago or newer
<jam> Chipaca, taking the dog out on a walk during the lunch break, bbiab
<Chipaca> jam: ð
<crodriguez> lol it changes quickly uh! I'll update that too... Idk, I was deploying the same piece of code a month ago and it wasn't failing on install. I wonder if something in my code might not be compatible with an update or juju and/or framework
<jam> crodriguez, juju <=2.7.5 didn't run install
<Chipaca> niemeyer: moved
<facubatista> jam, may you know why/if "juju debug-code is not supported on kubernetes models"? https://discourse.juju.is/t/live-debugging-at-python-level/2914/5
<jam> facubatista, I believe SSH into an operator container isn't supported, which is what juju debug-hooks and debug-code use to get into the machine
<jam> facubatista, it seems like it could be implemented on top of something like kubectl exec, but it is a matter of implementing support for it
<crodriguez> I love the new debug logs <3
<jam> crodriguez, did you work out the problem?
<crodriguez> yeah, it showed that my submodule wasn't found, so the import of ops.whatever was failing. I reinitialized it, updated it to latest, and I think I'm back on track now. Thanks!
<facubatista> crodriguez, this is related to your comment here? https://discourse.juju.is/t/live-debugging-at-python-level/2914/5
<crodriguez> facubatista: I posted it when I was blocked earlier, yes, but it is more of a general inquiry. I feel that we're not as well equipped to debug with juju for k8s models compared to openstack/vmware/baremetal.
<mup_> PR operator#245 closed: use path.open() instead of open(str(path)) <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/245>
<Chipaca> niemeyer: wrt plastic in your mate, don't google "food defect action levels"
<Chipaca> e.g. chocolate is fine until there is an average of 60 or more insect fragments per 100 grams
 * Chipaca omnoms chocolate
<niemeyer> Chipaca: Ouch.. let me guess.. FDA doesn't consider plastic to be an issue
<niemeyer> Okay.. I did Google.. apparently it's much worse
<facubatista> crodriguez, we will improve there! glad to know you're not blocked
<crodriguez> facubatista: I'm sure! :)
<mup_> PR operator#233 closed: Execute the registered methods to events under PDB if proper envvar is set <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/233>
<jam> good night all
<Chipaca> EOD here as well
<Chipaca> ð
<facubatista> bye jam
#smooth-operator 2020-04-29
<mup_> PR operator#246 opened: Made breakpoint handling code to use already parsed JUJU_DEBUG_AT, and isolated the message showing logic <Created by facundobatista> <https://github.com/canonical/operator/pull/246>
<jam> "morning" all
<Chipaca> moin moin
<niemeyer> o/
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: heyyy
<facubatista> hola Chipaca
<Chipaca> facubatista: q'acelga caezn
<facubatista> jejej
<jam> morning facubatista  and Chipaca
<jam> "morning" :)
<facubatista> hola jam
<facubatista> Chipaca, juju (maybe) never will set JUJU_DISPATCH_PATH as absolute, but a user may; if it's absolute, are we ok with it?
<jam> facubatista, are you sure we don't handle abspath correctly? Because if I do:
<jam> 0
<jam> https://paste.ubuntu.com/p/7rdWThBDjc/
<jam> base = Path('/var/run')
<jam> print(base / '/something/else')
<jam> I just get
<jam> '/something/else'
<jam> so self.charm_dir / dispatch_path
<jam> will give an abspath if it is set
<facubatista> jam, it depends on what "correctly" means... if we're ok with using an abspath if it's given, yes, we're handling it correctly, but then it bothers me a previous comment saying that the path "will be relative"
<jam> facubatista, so Juju will always pass a relative path
<facubatista> jam, the user may not
<jam> facubatista, but that is only if someone is intentionally not treating the object as a Juju charm and running something direcly
<facubatista> FTR, I'm +1 to improving the comment
<jam> in which case, they can do what they need to
<facubatista> let's fix the comment so when somebody reads it don't get confused with the code
 * Chipaca updates the comment to say "if the path is not relative, the absolute value of the path's eigenvector is used to compute its state in P-space before proceeding"
<jam> Chipaca, what about fourier domain ?
<Chipaca> so first fourier transform, *then* get the eigenvector?
<Chipaca> seems reasonable to me
<jam> o/ Chipaca
<jam> so chip is chipaca but isn't chip...
<Chipaca> Chipaca, chipakeitor, __chi__, ChipaPhone, and ChipAway are all grouped to me
<jam> "has been a joy to work with" \o/
<niemeyer> !!!
 * facubatista -> lunch
 * facubatista -> *really* lunch now
 * facubatista is back
 * Chipaca goes to have dinner
<jam> heading out, bbiab
<jam> back
<Chipaca> facubatista: you there?
<facubatista> Chipaca, yes, with my head inside shotcut, but heading to the meeting
<Chipaca> wooooooooooooâ°â°â°â°â°â°â°â°â°â°
 * facubatista eods
#smooth-operator 2020-04-30
<jam> morning. just finished the town hall
<Chipaca> moin moin moin
<facubatista> Muy buenos dÃ­as a todos!
<niemeyer> Moring jam, Chipaca, facubatista
<facubatista> hola niemeyer. jam, Chipaca
<Chipaca> I just heard back from the person that owns 'ops'
<Chipaca> we'll see how it goes
<niemeyer> Ah, nice!
<niemeyer> jam: Can you respond Casey's question on the Q&A?
<niemeyer> jam: With a link to your doc
<jam> sure
<niemeyer> jam: Or a point about it
<facubatista> jam, this is the bug regarding "we need exec for k8s, not ssh", right? https://bugs.launchpad.net/juju/+bug/1875422
<facubatista> mthaddon, ^
 * mthaddon waits with interest :)
<jam> mthaddon, facubatista : that is the bug for ssh, we probably want a slightly different one for debug-hooks/debug-code since they "don't have an easy workaround via kubectl exec"
<mthaddon> would love to be able to use the code debugging stuff on k8s
<mthaddon> I'd be happy to file one if you like?
<jam> mthaddon, if it super important, we might be able to work with you to get a hack together with a custom bash + kubectl exec script
<niemeyer> We'll be significantly improving the kid support in the near future.. that will be easier to do when we're finished with that
<niemeyer> k8s
<niemeyer> Kid support will take a bit longer
<facubatista> jajajaj
<mthaddon> :)
<jam> mthaddon, I haven't tried it, but the juju agent looks for special files to decide to run in debug mode, so we should be able to inject those via kubectl, I think.
<mthaddon> Is it worth filing the bug now, and seeing how long it'll take to implement on the juju side, as that'd be needed either way, right? (even if you're planning improvements to support k8s)
<niemeyer> Being able to track it certainly won't hurt.. I suggest just pointing out the note above with it, and mentioning it's for tracking for when the time comes
 * mthaddon nods
<mthaddon> https://bugs.launchpad.net/juju/+bug/1876105
<niemeyer> Thanks! Complemented it with the note mentioned.
<mthaddon> oh sorry, I must have misunderstood which note you meant :(
<niemeyer> No worries
 * facubatista -> lunch
<mup_> Issue operator#247 opened: Circular dependency error after pulling in latest version of framework <Created by gnuoy> <https://github.com/canonical/operator/issues/247>
 * facubatista bb~30'
 * facubatista is back
<mup_> PR operator#248 opened: Import internal modules in a controlled way. Fixes #247 <Created by facundobatista> <https://github.com/canonical/operator/pull/248>
<jam> facubatista, thanks for the pr, reviewed
<jam> and I'm heading to bed. night all
<facubatista> jam, thank you
 * facubatista eods too
#smooth-operator 2020-05-01
<jam> morning all
<jam> mup seems to be having a hard time
<niemeyer> Yeah, my network seems to have had many hiccups overnight
<facubatista> Muy buenos dÃ­as a todos!
<jam> morning facubatista
<facubatista> hola jam
<facubatista> jam, would you please help me to debug something?
<jam> facubatista, certainly, what's up?
<facubatista> I'm experimenting with this charm: https://paste.ubuntu.com/p/jvJdZ9mxdd/
<facubatista> jam, see lines 76-80
<facubatista> I have this charm deployed in a unit, apache2 deployed in other one
<jam> ok
<jam> Often during relation-joined the other side might not have had the chance to set any data yet
<jam> you also want on.relation_changed for when they do change the data
<facubatista> nice
<facubatista> however, if I run
<facubatista> juju add-relation bdv:server apache2:website
<facubatista> I see
<facubatista> unit-bdv-12: 16:48:34 INFO unit.bdv/12.juju-log server:4: ============ relation joined; event=<ops.charm.RelationJoinedEvent object at 0x7fc1d52c2940>
<facubatista> unit-bdv-12: 16:48:34 DEBUG unit.bdv/12.server-relation-joined ==== rdata <ops.model.RelationDataContent object at 0x7fc1d52c28d0>
<facubatista> so far, so good (even if no really data there), the problem is other
<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.
<jam> facubatista, so the rdata object is a wrapped dict
<jam> you can do print(dict(rdata)) if you want to see the items
<jam> We could probably improve the __str__ of RelationDataContent
 * facubatista improves a little the code
<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
<jam> facubatista, I definitely think logging at DEBUG for every Juju event and whether or not there is a handler
<facubatista> good idea
<facubatista> jam, so, *the* problem I get is:
<facubatista> jam, in other terminal, I issue: juju debug-code bdv/12
<facubatista> (note that in my code the .breakpoint() call is commented out)
<facubatista> then I go and I add the relation again (I had it removed before, of course): juju add-relation bdv:server apache2:website
<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):
<facubatista> unit-bdv-12: 08:18:27 INFO juju.worker.uniter.runner executing server-relation-created via debug-hooks; unknown/invalid hook handler
<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
<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
<jam> facubatista, it *sounds* like there is a script there that has an invalid #! line, but we'd want to check.
<facubatista> let me ssh into the machine to see what is really there
<facubatista> jam, where the charm is located inside the units?
<jam> facubatista, /var/log/juju/agents/unit-bdv-12/charm IIRC
<jam> sorry
<jam> not /var/log
<jam>  /var/lib
<facubatista> yes
<facubatista> jam, I don't have a server-relation-created hook
<jam> facubatista, are you using 'dispatch' ?
<jam> (the error doesn'at seem to say that)
<jam> ah, I'm wrong
<facubatista> jam, nop, our framework still doesn not support it
<jam> executing server-relation-created via debug-hooks
<jam> that last line is important
<jam> its trying to run relation-created as a debug-hook shell
<facubatista> note however that without the `juju debug-code` call in other terminal, it works!
<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.
<jam> facubatista, I assume this is with juju edge 2.8b1 ?
<facubatista> jam, 2.8-rc1-genericlinux-amd64
<jam> right, so ege
<jam> edge
<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
<facubatista> or I'm missing something?
<jam> facubatista, it sounds like a bug in juju that it either:
<jam> a) doesn't know how to invoke relation-created via debug-code
<jam> b) the framework is getting relation created, but then exiting badly
<facubatista> I don't think the framework gets to do anything here, as I don't have the hook in the hooks/ dir
<jam> facubatista, /snap/bin/juju --debug version
<facubatista> jam, I can try *adding* the hook
<jam> just to make sure that I'm running the same code as you
<facubatista> jam, 2.8-rc1 3596 7507bb48aaf8d93cde47977b895d09d33f616e53 gc go1.14.2
<jam> facubatista, ok, that is latest/edge
<mup_> Issue operator#249 opened: Let's instrument all registered methods' calls <Created by facundobatista> <https://github.com/canonical/operator/issues/249>
<jam> facubatista, I'm seeing if I can reproduce
<jam> also, roadmap in 5
<facubatista> yeap
<jam> facubatista, I think I figured out the bug in Juju
<jam> the issue is with debug-code
<jam> If you are in debug-hooks session, then all hooks get intercepted by debug-hooks
<jam> however, under 'debug-code' they get intercepted *and then still run*
<jam> but if the file doesn't exist
<jam> then you get this weird behavior
<jam> I'll file a bug
<jam> facubatista, https://bugs.launchpad.net/juju/+bug/1876290
<facubatista> jam, thanks!
<Chipaca> facubatista: feliz dÃ­a che
<facubatista> Chipaca, gracias, igualmente :)
<facubatista> jam, FTR, adding the hook 'server-relation-created' unblocked me
<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
<facubatista> jam, have 10' to help me understand some basic juju? a short HO would be great
<facubatista> thanks
 * facubatista bb ~10'
<jam> facubatista, I'm happy to. let me know when you're around. dinner is coming up soon, but food hasn't arrived yet
<jam> facubatista, food just arrived. I'll ping you when dinner is done
<facubatista> jam, ack, thanks
 * Chipaca reads how to run k8s on old laptops and suddenly has a bigger backlog
 * facubatista brb
<jam> facubatista, I'm back
<facubatista> jam, me too
<facubatista> jam, https://meet.google.com/veq-yfqm-kdk ?
<jam> facubatista, joining standup
<jam> but I can meet you there
<Chipaca> "this will enable you to connect to your cluster using Kubectl from the internet." â sounds like a bad idea to me
<jam> Chipaca, Twitch Plays Kubernetes ?
<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 ?
<jam> debug-hooks currently drops you into the debugger. and if you are using 'dispatch' then the operator framework will interrupt it
<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.
<jam> The other option is that you drop to 'bash' like you do for 'juju debug-hooks'b
<jam> maybe I can say that more clearly.
<jam> if you run 'juju debug-code unit/0' and it doesn't have 'dispatch' and it doesn't have 'hooks/install'.
<jam> when Juju wants to run 'install'
<jam> should it
<jam> a) just ignore it
<jam> b) drop you into a bash prompt
<jam> like we do for 'juju debug-hooks'
<Chipaca> jam: what does 'ignore it' look like to the user?
<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
<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'
<Chipaca> if it's "leave the user looking at a shell forever" then no :)
<jam> Chipaca, likely it is 'blip a shell that never gets focus because it exits too quickly'
<jam> debug-code is trying to hand off to the charm for it to handle the event
<jam> but if the charm doesn't implement dispatch or the hook, then it has no way to 'handle the event'
<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
<jam> (which is what debug-hooks currently does)
<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
<jam> The *current* debug-code behavior is that we spin throwing errors because we try to exec "" or something to that effect.
<jam> Chipaca, 'handle anything' is just dispatch
<jam> so we already have that handled
<Chipaca> i meant a handler that only gets added for debug-code when there ins't an actual handler
<jam> Chipaca, the particular issue is 'relation-created' because Dmitrii's patch hasn't landed, so we don't create hooks/*-relation-created yet.
<jam> Chipaca, and neither has *your* patch landed, so we don't handle dispatch either :)
<jam> I think dispatch fills the use case nicely. Because we already know that if you set 'juju debug-code --at hook'
<jam> we can do whatever we want if you don't have an event handler registered for a Juju event.
<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"
<jam> facubatista, if you have no breakpoint(), we 'run the hook in the background and log a WARNING'
<jam> I believe is what we discussed.
<facubatista> yes, we opened an issue for that
<jam> facubatista, so in that case, we don't leave you in the "waiting state"A
<jam> I was thinking to drop back to the debug-hooks implementation
<jam> so that you are aware that your charm isn't implementing 'relation-created'
<jam> otherwise during 'juju debug-code' you don't even see that it happened.
<facubatista> from my developer perspective, it should leave me in "waiting" state so I can actually get the breakpoint on relation joined
<jam> ah, you're saying not interrupt you but wait for other hooks to fire
<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
<jam> btw, wordpress review in 5
<jam> facubatista, Chipaca coming ?
<Chipaca> yes
<facubatista> yes
<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>
<jam> Chipaca, facubatista I'll be back around for the k8s charms meeting. for now I'm off to take the dog out
<facubatista> jam, ack
<Chipaca> i'm off to take myself out :)
<Chipaca> see you all in an ahh
<jam> one ahh later
<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
<jam> Walk the John
<ballot> Hello !
<Chipaca> ballot: hi!
<jam> according to this: https://blog.questionable.services/article/kubernetes-deployments-configmap-change/
<jam> changing a config map does *not* generate an event
<jam> the end up including an env variable which is the hash of the config
 * facubatista -> mate for the final part of the day
<Chipaca> facubatista: https://mobile.twitter.com/JenMsft/status/1256007715425382400
<facubatista> Chipaca, I love Gru
<Chipaca> facubatista: :)
<mup_> Issue operator#250 opened: Improve __str__ of developer exposed objects <Created by facundobatista> <https://github.com/canonical/operator/issues/250>
<Chipaca> jam: have a great weekend, and see you Tuesday!
