[04:03] <mup_> Issue operator#293 opened: passing k8s_resources to pod.set_spec does not work <Created by jetpackdanger> <https://github.com/canonical/operator/issues/293>
[08:41] <Chipaca> good morning peeps!
[09:53]  * Chipaca takes a break
[11:10] <facubatista> Muy buenos días a todos!
[11:18] <Chipaca> facubatista: 👋!
[11:19] <facubatista> hola Chipaca :)
[12:18] <MarkMaglana> question: is it possible to emit an interface event that comes with a data structure which the charm then fills in with data? i tried it but it looks like the data that the charm set doesn't make its way back to the interface. i suppose it's cloned before being passed to the charm?
[12:27] <Chipaca> MarkMaglana: you'd need to implement custom serialisers and de-serialisers
[12:27] <Chipaca> MarkMaglana: other than that i'd expect it to work
[12:28] <MarkMaglana> Chipaca: got an example? That's not the `snapshot` and `restore` methods is it?
[12:29] <Chipaca> MarkMaglana: i don't have an example, no -- and yes, snapshot and restore
[12:30] <Chipaca> MarkMaglana: 'The current storage state is committed before and after each observer is notified.' (what it doesn't say is that _emit is just _reemit with more steps)
[12:30] <Chipaca> ie the event gets written out, and then read back in
[12:37] <MarkMaglana> OK thanks! Let me try that out then.
[12:38]  * Chipaca goes back to having lunch
[12:40] <Chipaca> facubatista: https://www.pythonpodcast.com/pip-resolver-dependency-management-episode-264/ fwiw
[12:40] <facubatista> Chipaca, will read, after I finish the review of your branch
[12:40] <Chipaca> facubatista: I approve of this ordering
[13:01] <MarkMaglana> Chipaca: I may be doing something wrong. The data that the charm set doesn't make its way back to the interface.
[13:01] <MarkMaglana> Here's the data structure with custom snapshot and restore: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/interface_prometheus.py#L14-L39
[13:02] <MarkMaglana> Here's the interace's handler/emmitter: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/interface_prometheus.py#L85-L95
[13:03] <MarkMaglana> ...and here's the charm code that tries to modify the data structure: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/charm.py#L73-L80
[13:18] <Chipaca> MarkMaglana: and what do you see in the logs?
[13:22] <MarkMaglana> Chipaca: https://gist.github.com/relaxdiego/dc3af6827f150cd1b698e2da9106b603
[13:23] <Chipaca> MarkMaglana: but that shows you getting the data
[13:23] <Chipaca> MarkMaglana: what are you seeing as broken?
[13:23] <MarkMaglana> from the interface to the charm, yes. i was hoping that the additional 'test': 'test1' that I set from inside the charm would make its way back to the interface.
[13:24] <MarkMaglana> see line 14 of that gist
[13:26] <Chipaca> ohhhh
[13:27] <Chipaca> MarkMaglana: sorry, I had misunderstood
[13:28] <Chipaca> MarkMaglana: I don't think that's going to work
[13:28] <MarkMaglana> did i misunderstand the concept of interfaces? i thought it was meant to be a dumb pipe that both ends of the interface can send and receive messages through.
[13:41] <Chipaca> facubatista: you froze
[13:41] <MarkMaglana> Chipaca: oh. I should call `framework.relation_data_set()` inside the charm, huh?
[13:43] <MarkMaglana> ok i need to revisit this.
[13:43] <MarkMaglana> time to call it a day for now
[13:48] <Chipaca> MarkMaglana: i don't see a relation_data_set, but let's talk more tomorrow
[13:49] <Chipaca> also ja_m comes on early tomorrow so maybe that's more timely for you (he's off today)
[13:49]  * Chipaca feels like half his brain is off today too
[15:42] <Chipaca> facubatista: addressed all your concerns with ops.lib except the have-a-dict-per-api one
[15:42] <Chipaca> still thinking about that one
[15:43] <facubatista> Chipaca, ack, thanks!
[15:44] <Chipaca> facubatista: it can't be exactly as you show because then we'd risk overwriting an newer patch-level with an older one for the same api
[15:44] <Chipaca> but it's an easy tweak
[15:44] <facubatista> yes, (api, patch)
[15:44] <Chipaca> but, but, not sure it's simpler. OT1H it's got a better behaviour in a pathologic case
[15:45] <Chipaca> facubatista: nah, you don't want the patch in that dict, just the api
[15:45] <facubatista> Chipaca, in any case, even if we keep the current structure, let's think about "repeated" stuff there
[15:45] <Chipaca> and if d[api] < the_one_i_just_found, then replace it
[15:45] <Chipaca> facubatista: ok let's do that
[15:45] <facubatista> mmm... you still need to put 5.4 in that structure, even if you have 5.5, because the user may specify 5.4
[15:46] <Chipaca> facubatista: no they mayn't
[15:46] <Chipaca> facubatista: the user may only specify api, not patch
[15:46] <facubatista> ah, right
[15:46] <Chipaca> so we only need to keep one
[15:50] <Chipaca> facubatista: that's we the list is kept sorted
[15:50] <Chipaca> facubatista: but
[15:50] <Chipaca> facubatista: the common case is going to be to have just one of these things
[15:50] <Chipaca> two is already stretching it
[15:50] <Chipaca> so the current approach seems fine
[15:50] <facubatista> Chipaca, ok
[15:51] <Chipaca> if it turns out we're wrong about this and need to change to a dict because, it's a private, invisible change
[15:51] <Chipaca> so i'm happy as is
[15:54] <facubatista> Chipaca, +1 with a comment
[15:54] <facubatista> OTOH, I'm concerned about the quantity of exit points in None, after not finding exactly what we want, without any logging or anything.
[15:54] <facubatista> this would make debugging that part of the lib really hard
[15:55] <Chipaca> facubatista: yes. I'm thinking about that a bit.
[15:55] <facubatista> Chipaca, I propose to be silent only when checking all the sys.path and searching for "opslib" dir... but after that, if we do find a "opslib", we should log in debug why we're skipping what we found
[15:55] <Chipaca> facubatista: OTOH², I was thinking of writing a second ops.lib.use
[15:55] <Chipaca> ]:-)
[15:56] <facubatista> a second one?
[15:56] <Chipaca> facubatista: one that you run at build time
[15:56] <Chipaca> facubatista: or at debug time
[15:56] <Chipaca> and it tells you what it would find, what you're missing, that sort of thing?
[15:57] <facubatista> ops.lib.search
[15:57] <facubatista> super verbose
[15:57] <Chipaca> "you have ops.lib.use('foo') but no foo anywhere", or "you have ops.lib.use('foo') but your requirements do not include those from the foo opslib"
[15:57] <Chipaca> dunno, spitballing here
[15:57] <facubatista> ops.lib.use('foo', debug=True)
[15:58]  * Chipaca wonders why it's called 'spitballing', that's disgusting
[15:58] <facubatista> verbose=True
[15:58] <facubatista> explain=True
[15:58] <Chipaca> facubatista: i was thinking more "charmcraft build runs the charm with DEBUG_OPS_LIB=1"
[15:58] <facubatista> "foo opslib found, discarding it because LIBPATCH constant is not an int"
[15:59] <Chipaca> in any case, these are incremental improvements we can … improve
[15:59] <Chipaca> or we can increment them :-p
[16:00] <facubatista> Chipaca, checking this "at lib building" (through charmcraft, for example) would bring issues when all these checkings evolve ("it's clean when I build it but in production is not getting found", then to realize the user has OF 0.7 in dev and 0.6 in prod)
[16:01] <Chipaca> facubatista: so we should be logger.debug(...) stuff in any case
[16:01] <Chipaca> or logger.info() even
[16:01] <facubatista> Chipaca, logging in debug why the opslib that we find is not really considered, at .use() time, would be a nice thing
[16:01] <Chipaca> right
[16:02] <facubatista> in any case, after we find the "opslib" dir, none of those loggings should be seen, unless the lib itself is malformed
[16:02] <facubatista> "misformed"? "misshaped"?
[16:03] <Chipaca> "an mp3 file of a scream"?
[16:17] <Chipaca> d'oh, forgot to drop the XXX
[16:18] <facubatista> Chipaca, this is a good source about the "solver": https://github.com/pypa/pip/issues/988
[16:18] <Chipaca> facubatista: ack
[16:19] <facubatista> it starts ~7 years ago :)
[16:19] <Chipaca> facubatista: it's almost as if this stuff were hard
[16:19] <facubatista> jajaja
[16:19] <facubatista> go figure
[16:43]  * facubatista -> bank errands, bb~1h
[17:56]  * facubatista is back
[18:48] <mup_> PR operator#294 opened: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <https://github.com/canonical/operator/pull/294>
[20:39]  * facubatista eods