| Chipaca | good morning all! | 09:10 |
|---|---|---|
| mthaddon | o/ | 09:12 |
| Chipaca | mthaddon: how's things? | 09:15 |
| mthaddon | staying healthy so far thanks - and you? | 09:15 |
| Chipaca | mthaddon: healthy *and* sane! | 09:16 |
| * Chipaca is winning | 09:17 | |
| mthaddon | :) | 09:18 |
| Chipaca | mthaddon: I keep on going back to your 'operator framework documentation' document, and i'm thankful for it every time | 09:19 |
| mthaddon | ah cool, yeah, I saw you'd started work on rewriting the README. Glad that's proving useful | 09:20 |
| Chipaca | t0mb0: 👋 | 09:46 |
| facubatista | Muy buenos días a todos! | 11:07 |
| Chipaca | facubatista: ｇｏｏｏｄ ｍｏｒｎｉｎｇ！ | 11:08 |
| facubatista | hola Chipaca | 11:08 |
| * Chipaca takes a braek | 11:26 | |
| 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:51 |
| facubatista | it exploded to me, I was doing a quick self.framework.observe(self.on.upgrade_charm, lambda e: logger.info("====== upgrade ok")) | 11:52 |
| 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:54 |
| Chipaca | facubatista: maybe better filed as a bug, people seem off today | 11:59 |
| niemeyer | facubatista: Events are persisted | 12:04 |
| niemeyer | facubatista: We don't want to store code in the database | 12:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| niemeyer | Such a productive conversation | 12:10 |
| Chipaca | yes | 12:10 |
| Chipaca | you are being obtuse | 12:10 |
| Chipaca | please stop | 12:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| facubatista | ah, right, it may be a pure internal event | 12:25 |
| niemeyer | facubatista: This entire logic works any time something calls emit() | 12:25 |
| facubatista | niemeyer, great, I see now all the picture, thanks! | 12:27 |
| * facubatista adds a note to improve that error message | 12:28 | |
| niemeyer | facubatista: np, and it sounds healthy to continue challenging such options | 12:32 |
| Chipaca | niemeyer: question: in what situations do we expect snapshot/restore to be used? | 12:41 |
| niemeyer | Chipaca: Hopefully not much.. it's the underlying mechanism that enables StoredState, which is a much nicer interface for normal development | 12:42 |
| 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:43 |
| 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 | 12:45 |
| niemeyer | I won't be around for the standup today, but please drop me a note here if you need something | 13:07 |
| facubatista | niemeyer, comments on this would be great, thanks! https://docs.google.com/document/d/1zKwzo26bNVFgohaRB_kdUCsFPY3OcjfcpQklGpkOHpc/edit# | 13:15 |
| * facubatista brb | 13:15 | |
| * facubatista is back | 13:21 | |
| * Chipaca wishes all standups went like that | 14:04 | |
| axino | ah so this is where the cool kids hang | 14:32 |
| axino | hang out | 14:32 |
| axino | (is probably better English !) | 14:32 |
| facubatista | hello axino | 14:35 |
| 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:44 |
| mthaddon | Chipaca: nice! definitely like the format, makes sense | 14:46 |
| Chipaca | this assumes i understood the questions tho :-D | 14:46 |
| niemeyer | facubatista: Replied with a few comments | 15:01 |
| niemeyer | facubatista: In general it looks nice | 15:01 |
| niemeyer | Hello new people | 15:01 |
| facubatista | niemeyer, ack | 15:03 |
| 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:22 |
| facubatista | and confirmed! | 15:27 |
| 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:28 |
| 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:29 |
| facubatista | yay, my first spec here :p | 15:30 |
| niemeyer | 👏 👏 👏 👏 👏 | 15:30 |
| Chipaca | facubatista: it's even better than that | 15:31 |
| Chipaca | facubatista: it's _the_ first spec here :-D | 15:31 |
| facubatista | jajaja | 15:32 |
| * facubatista -> lunch | 15:32 | |
| * facubatista is back | 16:34 | |
| Chipaca | hmm | 17:15 |
| Chipaca | facubatista: i just set the approved date on that spec, but then thought | 17:15 |
| 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:16 |
| 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:17 |
| facubatista | Chipaca, who would be the persons to contact about this? | 17:18 |
| Chipaca | facubatista: I'll see if rick_h has a moment | 17:18 |
| Chipaca | facubatista: ok, no answer on that front, so I'd say let's leave it with jam | 18:17 |
| facubatista | YES YES YES | 20:23 |
| * facubatista dances the success dance | 20:23 | |
| * facubatista eods and eows | 21:00 | |
| facubatista | see you all on Monday | 21:00 |
| Chipaca | aw man i missed the success dance | 21:37 |
| niemeyer | Never too late for dancing.. | 21:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!