[09:10] <Chipaca> good morning all!
[09:12] <mthaddon> o/
[09:15] <Chipaca> mthaddon: how's things?
[09:15] <mthaddon> staying healthy so far thanks - and you?
[09:16] <Chipaca> mthaddon: healthy *and* sane!
[09:17]  * Chipaca is winning
[09:18] <mthaddon> :)
[09:19] <Chipaca> mthaddon: I keep on going back to your 'operator framework documentation' document, and i'm thankful for it every time
[09:20] <mthaddon> ah cool, yeah, I saw you'd started work on rewriting the README. Glad that's proving useful
[09:46] <Chipaca> t0mb0: 👋
[11:07] <facubatista> Muy buenos días a todos!
[11:08] <Chipaca> facubatista: ｇｏｏｏｄ  ｍｏｒｎｉｎｇ！
[11:08] <facubatista> hola Chipaca
[11:26]  * Chipaca takes a braek
[11:51] <facubatista> the Framework.observe method gets whatever we pass it as a callback and checks isinstance(observer, types.MethodType)
[11:51] <facubatista> why it has to be a method?
[11:52] <facubatista> it exploded to me, I was doing a quick         self.framework.observe(self.on.upgrade_charm, lambda e: logger.info("[11:54] <Chipaca> I don't know why, when I saw that I thought "that should be something like `callable`"
[11:54] <facubatista> let's see if somebody has a reason for that, otherwise I'll fix it
[11:59] <Chipaca> facubatista: maybe better filed as a bug, people seem off today
[12:04] <niemeyer> facubatista: Events are persisted
[12:04] <niemeyer> facubatista: We don't want to store code in the database
[12:05] <niemeyer> facubatista: Hopefully the error method was indicative of what it needed to be, or was it not?
[12:05] <niemeyer> s/error method/error string/
[12:06] <Chipaca> niemeyer: I don't understand how one thing follows from the other
[12:06] <facubatista> RuntimeError: Observer method not provided explicitly and function type has no "on_upgrade_charm" method
[12:07] <facubatista> I understand now "Observer" as I read the framework code
[12:07] <niemeyer> facubatista: That's not entirely clear
[12:07] <facubatista> niemeyer, right
[12:07] <niemeyer> facubatista: Might be improved indeed
[12:07] <niemeyer> Chipaca: Which things thing follows what?
[12:08] <facubatista> Chipaca, we store the *method name*, not the method itself
[12:08] <Chipaca> niemeyer: events are persisted, we don't want to store code in the database, so the handler needs to be a method
[12:08] <facubatista> Chipaca, later we do a getattr, I guess
[12:08] <Chipaca> we store the method name? why?
[12:08] <niemeyer> Chipaca: Deferring
[12:09] <Chipaca> but we stored the event, and the charm is initialized so all the handlers are hooked up
[12:09] <niemeyer> Chipaca: we don't call the same observer twice unless it asks to be called again
[12:09] <Chipaca> why would we store the method name?
[12:09] <niemeyer> Chipaca: I just responded that one.. :)
[12:09] <Chipaca> no you didn't :)
[12:10] <niemeyer> Such a productive conversation
[12:10] <Chipaca> yes
[12:10] <Chipaca> you are being obtuse
[12:10] <Chipaca> please stop
[12:11] <niemeyer> Chipaca: I've been trying to explain things, and meanwhile you've been saying the equivalent of "I don't understand it".. unless you ask intelligent questions, I can't help you
[12:11] <facubatista> niemeyer, if I get an event foo, and I defer it, why can't we store "foo", then in the next run, we deliver "foo" to whatever is hooked at that time?
[12:11] <niemeyer> facubatista: Because of that issue above: we don't call the same observer twice unless it asks to be called again
[12:12] <niemeyer> facubatista: For that to happen, we need an identity for that "it asks"
[12:12] <niemeyer> facubatista: How would you do that for a lambda?
[12:12] <Chipaca> ok, now I understood, thank you
[12:13] <facubatista> but if I deferred it, I'm not asking to deliver me the event in the future? the problem is if I change the method or callable (charm upgrade) in the middle?
[12:13] <Chipaca> facubatista: but you might have multiple handlers for the event
[12:14] <Chipaca> facubatista: and only some of them deferred
[12:14] <facubatista> ah, right
[12:14] <facubatista> niemeyer, Chipaca, thanks!
[12:14] <facubatista> this is the kind of details we need to be sure is in the docs :)
[12:14] <Chipaca> facubatista: and in the errors :-D
[12:15] <niemeyer> facubatista: To be honest, I've been always double-hearted about the whole deferring thing
[12:15] <niemeyer> It might not pull its weight
[12:16] <niemeyer> It's also worth noting in this context that we err on the safe side..
[12:16] <niemeyer> Despite the apparent way it works, internally handlers don't really ask for deferring an event
[12:16] <niemeyer> They do the opposite: the ack the event as handled
[12:17] <niemeyer> The act of deferring prevents that acknowledgement
[12:17] <facubatista> niemeyer, deferring event across runs complicates a lot of little things (not only the code, also the developer thinking of the model) -- are there cases where deferring the event is the only sane option?
[12:18] <facubatista> (with "model" I didn't mean the juju model, but the "how my charm works and handle all system complexities")
[12:18] <niemeyer> This is a long way to say that deferring doesn't in fact trigger a complex path into the code.. we _always_ persist events, and then trigger a common path that handles pending events
[12:19] <niemeyer> That's what makes me feel a bit less bad about the complexity..
[12:19] <niemeyer> Our logic makes it harder for events to be lost, even if you never call defer() at all
[12:21] <niemeyer> facubatista: I would simply not explain any of that complexity until really required.. if people have to understand the details of that stuff, we failed
[12:21] <facubatista> niemeyer, mmm... if we don't persist it, and we crash while handling it... the Agent would not re-send it as we never acked it?
[12:22] <niemeyer> facubatista: I'm a bit confused about the context for this question.. we always persist it, right?
[12:22] <facubatista> (don't really know how the Agent works in this regard)
[12:22] <niemeyer> facubatista: Yeah, that's what I was trying to explain above: we *always* persist it
[12:22] <facubatista> niemeyer, yes, we always persist it; I'm challenging that decision :)
[12:22] <niemeyer> facubatista: This is not triggered by deferring
[12:22] <niemeyer> facubatista: The difference in deferring is actually very small in terms of overall behavior
[12:23] <niemeyer> facubatista: You simply flip a switch saying "do I remove this event now that I handled it?"
[12:23] <niemeyer> facubatista: Everything else is exactly the same
[12:23] <facubatista> niemeyer, yes, because we always persist it
[12:23] <niemeyer> Yeah
[12:23] <facubatista> niemeyer, bear with me a little in this other POV
[12:23] <niemeyer> facubatista: Which means that on crashes the event will be sent again
[12:24] <facubatista> niemeyer, what if we NOT always persist it? what if we persist it only when deferring? we may crash while handling it, yes, but shouldn't the Agent re-send the event?
[12:24] <niemeyer> facubatista: Not necessarily, and our events don't come only from the agent
[12:25] <facubatista> ah, right, it may be a pure internal event
[12:25] <niemeyer> facubatista: This entire logic works any time something calls emit()
[12:27] <facubatista> niemeyer, great, I see now all the picture, thanks!
[12:28]  * facubatista adds a note to improve that error message
[12:32] <niemeyer> facubatista: np, and it sounds healthy to continue challenging such options
[12:41] <Chipaca> niemeyer: question: in what situations do we expect snapshot/restore to be used?
[12:42] <niemeyer> Chipaca: Hopefully not much.. it's the underlying mechanism that enables StoredState, which is a much nicer interface for normal development
[12:43] <Chipaca> niemeyer: so https://github.com/johnsca/interface-mysql/blob/master/interface_mysql.py is not kosher then?
[12:43] <Chipaca> maybe it predates storedstate?
[12:45] <niemeyer> Chipaca: EventBase is not an Object at the moment.. I had an exchange here with facubatista recently covering that.. he was going to do some research to see how hard it would make it a more usual object
[12:45] <niemeyer> I think that's the only odd case we have
[13:07] <niemeyer> I won't be around for the standup today, but please drop me a note here if you need something
[13:15] <facubatista> niemeyer, comments on this would be great, thanks! https://docs.google.com/document/d/1zKwzo26bNVFgohaRB_kdUCsFPY3OcjfcpQklGpkOHpc/edit#
[13:15]  * facubatista brb
[13:21]  * facubatista is back
[14:04]  * Chipaca wishes all standups went like that
[14:32] <axino> ah so this is where the cool kids hang
[14:32] <axino> hang out
[14:32] <axino> (is probably better English !)
[14:35] <facubatista> hello axino
[14:44] <Chipaca> mthaddon: https://github.com/canonical/operator/blob/06d242ff31b4a5cc6e7e829f9e8f99c6974def86/tbd_examples.md FWIW
[14:44] <Chipaca> axino: welcome!
[14:44] <axino> o/
[14:44] <Chipaca> mthaddon: I'm just staging stuff in that PR while I finish getting our docs ducks docked
[14:46] <mthaddon> Chipaca: nice! definitely like the format, makes sense
[14:46] <Chipaca> this assumes i understood the questions tho :-D
[15:01] <niemeyer> facubatista: Replied with a few comments
[15:01] <niemeyer> facubatista: In general it looks nice
[15:01] <niemeyer> Hello new people
[15:03] <facubatista> niemeyer, ack
[15:22] <facubatista> niemeyer, we are in the same page, then; there's one extra case annotated now in the spec, but I need to check with juju one detail about multiple parameters
[15:27] <facubatista> and confirmed!
[15:28] <facubatista> (multiple --breakpoint parameters is possible in juju)
[15:28] <facubatista> there are current cases for this, e.g. --overlay in juju deploy
[15:28] <niemeyer> I'd just accept --breakpoint=a,b,c as you suggested
[15:29] <facubatista> niemeyer, in reality, if the user goes and write --breakpoint=a,b,c, juju would set up JUJU_BREAKPOINT to "a,b,c", and it will work just the same :)
[15:29] <niemeyer> Right
[15:29] <niemeyer> As long as you define that this is the behavior :)
[15:29] <facubatista> the Spec is in good shape
[15:30] <facubatista> yay, my first spec here :p
[15:30] <niemeyer> 👏 👏 👏 👏 👏
[15:31] <Chipaca> facubatista: it's even better than that
[15:31] <Chipaca> facubatista: it's _the_ first spec here :-D
[15:32] <facubatista> jajaja
[15:32]  * facubatista -> lunch
[16:34]  * facubatista is back
[17:15] <Chipaca> hmm
[17:15] <Chipaca> facubatista: i just set the approved date on that spec, but then thought
[17:16] <Chipaca> maybe we should ask our juju friends first :)
[17:16] <facubatista> Chipaca, what about?
[17:16] <facubatista> I mean, ask them?
[17:16] <Chipaca> facubatista: whether they're ok with the changes to debug-hook
[17:17] <Chipaca> can't imagine a scenario where they block it though
[17:17]  * Chipaca might just be short of imagination
[17:17] <facubatista> Chipaca, it's a step in the milestone, but it's a good idea indeed to gain consensus in the spec itself
[17:18] <facubatista> Chipaca, who would be the persons to contact about this?
[17:18] <Chipaca> facubatista: I'll see if rick_h has a moment
[18:17] <Chipaca> facubatista: ok, no answer on that front, so I'd say let's leave it with jam
[20:23] <facubatista> YES YES YES
[20:23]  * facubatista dances the success dance
[21:00]  * facubatista eods and eows
[21:00] <facubatista> see you all on Monday
[21:37] <Chipaca> aw man i missed the success dance
[21:41] <niemeyer> Never too late for dancing..