[04:40] morning all [06:34] o/ [08:32] mo'in [08:35] jam: https://r.chipaca.com/land_shallow_topo.jpg (to be fair it might have bitrot at this point, without me noticing :) ) [08:36] Chipaca, it doesn't render very well here. [08:37] yeah, here either, and imagemagick now has limits in place that block it from touching the image even (without further tweaking) [08:37] which was precisely the point the image was trying to make, so i won i guess? [08:40] Chipaca, "I Win" :) [08:40] quite [08:41] jam: an interesting thing came up in the call yesterday, with narinder [08:41] jam: he's going to file a bug about it, but i don't think he has yet [08:42] jam: but if you look at https://github.com/narindergupta/charm-k8s-kafka/blob/master/src/charm.py [08:42] jam: at expose_relation_data [08:43] jam: ISTM that having to do that getnameinfo thing is not particularly friendly [08:46] Chipaca, indeed. I know that there has been discussions on the Juju side of how to present a hostname when you have one [08:46] It certainly is never guaranteed that there *is* a hostname for a unit [08:47] And if there is one (in say, MAAS) it may not be accessible because the DNS server is local [08:47] I also know of bugs like https://bugs.launchpad.net/juju/+bug/1867168 [08:50] jam: yeah, that sounds like exactly the issue [08:54] facubatista: this Friday we scheduled a meeting with people writing a postgres charm (i'm assuming for k8s). Neither jam nor I work this Friday :) should we reschedule, or are you happy to carry it alone? [08:54] is he in yet? [08:54] I would recommend rescheduling, as that is one that I'd like to be at [09:00] jam: I'll ask sohini to transfer these to me so we can move them around [09:00] Chipaca, given that the bug is about the charm-k8s-mongodb it sounds very much like that bug [09:21] jam: btw, are https://github.com/narindergupta/charm-k8s-kafka/ and https://github.com/narindergupta/charm-k8s-zookeeper/ on the list? (i don't see them) [09:22] Chipaca, they are now :) [09:22] jam: taw [09:25] Chipaca, is there a notes doc about Kafka meeting? [09:26] jam: i need to transfer my notes onto a doc [09:26] jam: and, in future ones, start with a shared doc so we edit it as we go [09:32] Chipaca, so I mentioned I was investigating creating symlinks earlier (before instantiating the charm) [09:32] it is certainly 'doable' but it changes a bit [09:33] namely, Events currently get their name from being assigned as an attribute to a class [09:33] (install = EventSource(InstallEvent) is how we know the hook is 'install') [09:33] I could change it so that the name of the associated hook is part of the base event, but it felt like a pretty significant departure [09:33] so I wanted to check before I proceeded [09:34] it does feel a bit nastier [09:35] OTOH the know-thy-name magic might prove to be too magic at some point [09:47] Chipaca, so in my head I was going to a registry of hook events so that we can easily iterate them. right now that "registry" is CharmEvents and iterating the attrs of it [09:48] Chipaca, ObjectEvents.events() uses inspect.getmembers(type(self)) [09:48] which seems an odd way to do a registry to *me* [09:49] jam: oh so it _doesn't_ use set_name-like magic [09:50] my bad :) [09:50] Chipaca, oh, it does [09:50] it does both :0 [09:51] Chipaca, event_kind is used as the name, which is populated during __init__ because of calling getattr() [09:51] AFAICT [09:51] _create_event_link looks at 'bound_event' which has an 'event_kind' which is the name of the attribute [09:52] (it could have just as easily used the 'key' portion of the key:bound_event map, but chose to just call values() and then iterate those) [10:53] Muy buenos días a todos! [10:54] facubatista: buen día! [10:55] facubatista: could you review #258? [10:56] Chipaca, sure [10:58] Chipaca, regarding friday meeting, I can take it, but if jam wants to be there, we can reschedule it, yes [10:59] morning facubatista [10:59] hola jam [11:01] meeting is in standup room? [11:02] I added a room, but I'll happily move to standup since I added it late [11:02] ah, no [11:02] I'm in the other one [11:02] Chipaca, coming? https://meet.google.com/pmg-hccz-tqd [11:04] niemeyer, hello! any chance you leave a mup with us? [11:05] facubatista: Sorry, machine crashed yesterday and I forgot to bring it back up.. still haven't managed to put it in a stable place [11:24] niemeyer, no worries! thanks! [12:05] jam, Chipaca, ...? [12:10] jam, we lost you [12:10] brb [12:40] https://paste.ubuntu.com/p/GFFXXrwKCW/ [13:51] jam, facubatista, wrt ops.lib.use, in practice it'll be lib.use(), no? because 'from ops import <>' is the pattern we're encouraging [13:51] or maybe even use() [13:52] I like lib.use() [13:52] from ops.lib import use as frameworkify [13:52] * Chipaca hides [13:53] mysql = frameworkify('mysql') [13:53] nice [14:07] jam: also, binding.ports[1000:1024].open() [14:57] binding.ports[1000:1024].open(name='foo') [14:58] binding.ports.close('foo') [14:58] binding.ports[1000:1024].close() [15:42] facubatista: where are we planning on saving 'foo'? [15:58] Chipaca, some StoredState? [15:59] facubatista: AIUI this means the ports depends on saving state in the controller [16:00] Chipaca, we can not depend on that? [16:01] Chipaca, we're saving the events already, right? [16:01] facubatista: not in the controller yet [16:01] it's saved in a local db [16:15] Chipaca, why the ports storage would be different? [16:16] facubatista: i might be getting this wrong but i think the pod can be replaced at any time at which time we lose? but maybe not, the local db [16:16] ah no the db is not in the pod [16:16] that's the problem with actions [16:17] facubatista: ignore me, brain wongled [16:17] facubatista: but don't ignore me _too_ much :-p [16:18] * facubatista ignores odd chars in Chipaca sentences [16:19] facubatista: any char < 2019 is rubbish anyway [16:19] facubatista: 🧉🧉🧉 [16:20] ja [16:31] facubatista: plz don't forget to review the docs one [16:41] extensions = [ [16:41] 'sphinx.ext.autodoc', [16:41] ops.lib.use('autodoc') [16:45] Chipaca, some questions inline [16:46] also, I don't remember why we still don't have a proper requirements-dev.txt file with flake8, autopep8, etc [16:47] facubatista: I don't remember what happened to your PR with that [16:48] Chipaca, it's a good moment to add it [16:49] facubatista: what happened to that PR? [17:04] Chipaca, we end up not automatizing the virtualenv creation, so the dependencies ended up in the README [17:05] (I landed that improvement over "you find out by trial and mistake what you need" as a middle ground) [17:10] facubatista: you _don't_ need sphinx for dev though, rtd will build them for us [17:13] Chipaca, unless you want something to be fixed, for when you want to check how it looked before and after [17:13] but yes, that will not happen always [17:14] Chipaca, maybe a docs/requirements.txt ? [17:14] docs/requirements-build.txt ? [17:14] * Chipaca adds a facubatista/requirements.txt [17:14] * facubatista is very requiremented [17:14] * Chipaca also adds a .snapcraft/you-might-be-lost.md