[05:18] jam: thanks for commenting on the Existing Tools section! Very good comments. Helps with thinking about and evaluating possible solutions. [05:19] MarkMaglana, happy to. I think we're also very invested in recommendations for how to get the dependencies into the charm and into the deployment [05:20] MarkMaglana, I should mention that the current plans are looking to have a build step for charms that can be run on a Launchpad build farm (like snaps and debs) so that charms end up series/architecture specific for deployment. [05:20] We've tried to avoid that in Juju for a long time, but it is just a practical matter that charms depend on python extensions [05:20] (even PyYAML uses libyaml) [05:21] note that the charm store and Juju don't currently support looking up charms by series+architecture so a lot of that ends up in 'room for growth' [05:33] jam is this build step plan documented anywhere? I'm curious and would like to reference that in my document. [07:33] Hey jam! [07:34] Ian Booth told me that the issue https://bugs.launchpad.net/juju/+bug/1882127 is fixed in 2.7/edge [07:35] davigar15, well, it now properly reports an error rather than a nil panic, we still need to understand what the underlying error is [07:36] jam: okay! great! I will investigate if I have time. Let me know if you find out anything [07:36] have a nice day :-) [07:38] davigar15, you too [08:13] good morning people! [08:52] jam: should I tell people to give #323 a try if they're interested in it? [08:52] PR #323: 317 state get [08:52] It isn't wired up yet, so I still need to do a bit [08:52] morning Chipaca [08:52] jam: ok, i'll just mention it's a WIP and on target for 0.7 then :) [08:58] hi jam - any chance you can take a one more look into the https://github.com/canonical/operator/issues/328? Still have no idea what could be wrong :/ [09:05] vgrevtsev, is src/charm.py executable and have the right #! line? [09:06] maybe python isn't found at the path you expect inside the application container? [09:07] replied to the bug [09:11] jam: yes it's exec-able, the charm itself is running fine [09:15] vgrevtsev: do you get debug logs? [09:22] vgrevtsev, that is running in the operator pod, while the actions run in the application pod [09:22] vgrevtsev, different python [09:22] jam: but the charm ran in the application pod as well, otherwise what created the symlink [09:23] jam: yeah but it didn't raise the bad interpreter or smth similar [09:23] Chipaca, juju when it copies the charm directory from the operator pod to the application pod during init [09:23] ahhh [09:24] vgrevtsev, $ ./foo [09:24] bash: ./foo: /bin/ash: bad interpreter: No such file or directory [09:24] that does say "No such file or directory" [09:24] but it also says "bad intepreter" [09:24] vgrevtsev, yeah, and there is some sort of python that is trying to exec the script [09:25] well wait [09:26] i think i found smth [09:26] `/bin/sh: /usr/bin/env: not found` [09:26] (in the app container) [09:26] while my `charm.py` has `#!/usr/bin/env python3` [09:34] hehe [09:34] /usr/bin/env bites again [09:34] (this wrt: people doing '/usr/bin/env bash' to make things more portable --- despite env being in /usr/bin less frequently than bash is) [09:35] s/(?<=than bash is)/ in \/bin/ [09:36] yeah, and here is another problem: my app container doesn't have python installed :\ [09:36] so that basically means that I can't run actions against it [09:36] yeah [09:37] vgrevtsev, you can write non-python actions, it depends what you want them to do [09:43] true [09:43] just wondering why the actions are executed at the app pod but charm itself runs on the operator pod? [09:44] vgrevtsev: I think there's an ongoing conversation about that [09:44] or a few actually? [09:44] seems a lot more work needs to be done still [09:44] mostly juju-side aiui [09:45] vgrevtsev, a lot of it depends on what you want out of an action. many types of actions require running with the appliaction (eg, backup the database) [10:32] BTW, PROMPT_COMMAND='printf "⏎%$((COLUMNS-1))s\\r"' FTW [10:55] jam: in zookeeper_cluster, am i reading it right that it uses both framework.model.get_relation(...) and framework.relations[...] for the same relation, despite the usage of the first meaning that any checks on the length of the second are spurious? [10:56] because get_relation raises an exception if it's not unique [11:01] Chipaca, meeting? [11:59] jam: another one? [11:59] oh wait [12:00] Chipaca, https://github.com/canonical/operator/pull/327 needs your review [12:00] PR #327: many: move Model.name to be read from _ModelBackend [12:00] * Chipaca gets out the red pen [12:01] Chipaca, 'oh wait' ? [12:01] Chipaca, if you can find a way to get your red pen marks online, I'm all for it [12:01] jam: saw your 'meeting?' message _after_ the meeting :) [12:03] stub: filed #329 [12:03] Issue #329: dependencies <🧠 big brain> [12:03] Issue operator#329 opened: dependencies <🧠 big brain> [12:04] jam: i'd actually gotten half way through reviewing that on Friday [12:04] I lie [12:04] Thursday [12:04] Chipaca, I can imagine it was "I reviewed it but didn't hit send" [12:05] i hadn't gotten to the bottom :) [12:08] Issue operator#223 closed: Operator fails on Juju 2.7.0 and below [12:08] PR operator#324 closed: model: don't use --app for relation-get/-set before 2.7.0 [12:08] PR operator#326 closed: make abc TestMain private to help pytest [12:26] * Chipaca stepping out for 30' [12:33] Issue operator#328 closed: k8s charm throws a "not found" error when invoking the action [13:00] jam: i'll be along as soon as i've figured out why i have a conflicting meeting [13:00] ok [13:02] Chipaca, so far nobody else is here [16:37] * Chipaca gives up [16:37] slightly early EOD from me [16:38] ttfn! might pop in later, but i'll go run now