[08:27] Issue operator#286 closed: charms/test_main should not use Pickle [08:27] PR operator#363 closed: 0.8 test charm no pickle [08:31] ｇｏｏｏｏｏｏｄｍｏｒｎｉｎｇ！ [08:53] morning Chipaca [08:57] jam: 👋 how's things? [09:01] Chipaca, going pretty well. I still need your review on operator#364 [09:01] PR #364: ops/testing.py: Harness.begin_with_initial_hooks() [09:02] Chipaca, I'll probably miss the standup today, I have a conflicting meeting [09:02] ack [09:07] Chipaca, how's it with you? [09:07] jam: needing more coffee :) [09:24] * Chipaca has more coffee now [09:48] jam: instead of diving into preconditions, i've been tinkering with ops-lib-k8s [09:49] still haven't touched the tests though [09:52] Issue operator#237 closed: Feature request: Harness helper function/flag to run initial hooks as juju would execute? [09:52] PR operator#364 closed: ops/testing.py: Harness.begin_with_initial_hooks() [09:52] Chipaca, ah nice. I don't think I gave much feedback on that one, I should [09:53] jam: latest pr sets things up for them to work with opslib because design was wanting a real-world example of what a non-interface component looked like [10:34] Chipaca, I'm in the process of updating charmcraft issue 104. Would I be right in saying that for charms running in Juju <2.8 the operator framework needs to create the hook symlinks when the install hook runs ? [10:34] Issue #104: Symlink for `hooks/upgrade-charm` is not created when missing [10:40] * gnuoy assumes it should and updates the bug [10:43] gnuoy: yes [10:43] kk, thanks [10:43] gnuoy: bah, whatever hook runs first [10:43] yep, understood [10:43] in <2.8 on k8s that was 'start', for ex [10:43] and it couldbe upgrade-charm? i think [10:44] iffen you're upgrading :) [10:45] so I think the bug is correct, if you use charmcraft then a legacy deployment is never detected and the symlinks never created. [10:46] I assumed it was deliberate hence the min-version thing. I'll update the title. [10:46] gnuoy: what's a 'legacy deployment'? [10:47] Chipaca, I'm stealing the phrase from the ops framework. I believe it to mean a non-dispatch aware version of Juju [10:47] https://github.com/canonical/operator/blob/master/ops/main.py#L173 [10:47] ah :) [10:48] gnuoy: this is with juju <2.8? [10:48] right [10:48] hmm™ [10:48] I've put more detail in https://github.com/canonical/charmcraft/issues/104 [10:48] thanks [10:50] gnuoy: this is code i wrote, so it cannot _possibly_ have bugs [10:50] haha, must be feature. [10:52] gnuoy: https://youtu.be/qhXjcZdk5QQ?t=52 [10:53] exactly! [10:59] that's quite a pickle [11:03] ¡Muy buenos días a todos! [11:04] facubatista: (null) [11:04] er [11:04] * Chipaca checks his config [11:05] je [11:05] facubatista: 👋❗ [11:05] much better [11:06] https://imgflip.com/i/4adkoh [11:06] :) [11:07] facubatista: https://www.bbc.com/future/article/20160325-the-names-that-break-computer-systems [11:08] This one surely breaks a lot https://xkcd.com/327/ :-) [11:09] Chipaca, my mother's last name is Muñiz, and I remember the real life in the pre-unicode era, everything was Mu#iz for her [11:10] Chipaca, jam, in charmcraft#104, shouldn't the OF create the rest of the hooks? [11:10] Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 [11:10] facubatista: remember manuel de la peXa? [11:11] facubatista: yes the problem is that charmcraft is setting things up in such a way that ops thinks it's in post-2.7 [11:12] Chipaca, facubatista : the code is still there: https://github.com/canonical/operator/blob/master/ops/main.py#L175 [11:12] and it is even called: https://github.com/canonical/operator/blob/master/ops/main.py#L334 [11:13] jam: but the hooks are symlinks to dispatch [11:13] jam: and dispatch sets JUJU_DISPATCH_PATH [11:13] jam: and dispatch exists [11:13] and that's what ops uses to choose legacy or dispatch [11:13] Chipaca, in current charmcraft, after zipping, remember hooks are not symlinks (but will be in future charmcrafts) [11:14] Chipaca, but why is that a problem? [11:14] no difference, it's the fact that it sets JUJU_DISPATCH_PATH and exists that does it [11:14] self.is_dispatch_aware gets incorrectly set to True which causes an early exit from ensure_event_links [11:14] jam: because then no symlinks are created [11:14] Chipaca, ah, dispatch is setting JUJU_DISPATCH_PATH, why would it do that? [11:14] bad script no biscuit [11:14] :) [11:14] jam: other bugs :) [11:15] need to dig [11:15] Chipaca, ok. so it is a charmcraft bug (arguably), at the least, ops and charmcraft don't agree on signaling [11:15] yeup [11:17] Chipaca, https://github.com/canonical/charmcraft/commit/a0bdc74c5b2b63eff9248ad8c192a2c9f8a0f5e1 [11:18] yup [11:27] Chipaca, thinking about multipass and snapcraft/charmcraft. I find it interesting with snaps that it is so dangerous to depend on a executable in $PATH that the preferred route is to expose a service for anyone to poke via the network [11:27] Is it because it has been easier to grant Network as a policy than granting "access to executable Foo" as a policy? [11:27] jam: it isn't about it being dangerous, it's a limitation of the security layers [11:29] jam: (there's also the policy issue of letting a confined thing execute an unconfined thing meaning you've just unconfined the confined) [11:30] Chipaca, so find a way to execute the unconfined thing via an HTTP post instead of a CLI exec [11:33] jam: the thing is already exposing a grpc api over a socket to itself [11:34] Chipaca, I just mean, a CLI is an API just like an HTTP API is.snapcraft is able to confine things to not find executable, but doesn't have fine grained control to say what services you could talk to [11:34] but it means people break their confinement via HTTP requests instead of via CLI requests [11:57] gnuoy: we're going to be 5 minutes late [11:58] sure np [13:09] jam, facubatista, wrt charmcraft#104, not super clear to me what we can do [13:09] Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 [13:09] Chipaca, create all hooks symlinks everytime? [13:10] that's less than ideal for a couple of reasons [13:10] the issue is that calling charm.py drops the name of the hook [13:10] that is, we lose sys.argv[0] [13:10] Chipaca, not set JUJU_DISPATCH_PATH in dispatch [13:10] ah right [13:10] so it seems to me [13:10] is there a magic in 'exec' ? [13:10] that what we should do is set our _own_ variable [13:11] with blackjack and … [13:11] … built-in help? [13:11] jam: i think bash exec does, sh exec does not [13:11] but i'd have to double-check [13:11] Chipaca, 'exec --help' says 'exec -a NAME' [13:12] right, that's bash [13:12] Chipaca, the builtin help is a good idea, there's a recurrent question when dealing with this new "dispatch thing" that is "so I'm in here with debug-hook, how I call my hook manually?" [13:12] $ /bin/dash -c 'exec -a foo echo hello' [13:13] jam: ooh, undocumented? [13:13] /bin/dash: 1: exec -a: not found [13:13] jam: b'doh [13:13] nope, just copy&paste didn't work because IRC interpreted the opening '/' :) [13:13] Chipaca, I'm not opposed to #!/bin/bash in dispatch [13:14] or we could make it a python script ]=) [13:14] Chipaca, +1 [13:15] but bash sounds alright for a last-minute thing [13:15] facubatista, Chipaca we could. I know that breaks on RedHat because python3 isn't in the default instal [13:15] drop JUJU_DISPATCH_PATH, and use -a [13:16] or [13:16] OR [13:16] use symlinks [13:16] :) [13:16] Chipaca, symlinks how? [13:17] this all goes away if we stop flattening symlinks [13:17] doesn't it? [13:17] (maybe it doesn't) [13:17] Chipaca, if you change hooks/install => ../src/charm.py it would go away, but you can't do that because we want to put the "use the venv" somewhere [13:17] right [13:18] * Chipaca sets the venv on fire and sits back to watch [13:18] I'll write the "use bash w/exec -a" as the quickest way out [13:23] … that doesnt work [13:24] python's fiddling with argv [13:30] Chipaca, you that know Unix (?), is it ok to have a space rigth after the shebang in "#! /usr/bin/env python3" ? [14:34] facubatista: yep (and they've been documented as required at some point, although weren't) [14:36] thanks [14:46] facubatista: also, env -S exists (as of when? no idea) [15:04] Hello ! [15:05] hello ballot! [15:06] I'm looking for a way to retrieve the pod_spec using ops.testing. I see that self.harness.get_pod_spec is defined in 0.8 (https://github.com/canonical/operator/blame/master/ops/testing.py#L423). I guess I don't have a way to test this easily with 0.7 right ? :) [15:07] well, I don't really have a problem trying to use 0.8 for my charm tbh anyway, i'll give it a try [15:15] ballot: and 0.8 should be out this week :) [15:15] ballot: pre that, there wasn't an easy way of doing that, no [15:16] Chipaca: alright, just wanted to be sure I was not missing something. I have an issue with charmcraft build, I'll bring that to the right channel, thanks :) [15:16] ballot: 'charmcraft build' issues is also here :) [15:16] Ah ! [15:17] ballot: unless you're building something so secret you can't talk about it in public :-D [15:17] Well, I put "-e git+https://github.com/canonical/operator.git@master#egg=ops" in my requirement.txt and confirmed it works with "pip install -r requirements.txt" [15:17] When I do charmcraft build, in the full log I have [15:18] https://pastebin.ubuntu.com/p/jmyJh58WCT/ [15:18] (sorry bad habit of using the internal one) [15:19] whoa [15:19] Chipaca, jam, where I can read about the order of first events sent by Juju? [15:19] It's fine, I can workaround it easily by manually pulling the wheel in the right location, but probably bug worthy. Just wanted to be sure it was not something obvious on my side [15:20] ballot: does that still happen if your requirements.txt has 'git+https://github.com/canonical/operator.git' instead of your more funky line? [15:20] Chipaca: let me try [15:20] facubatista, https://discourse.juju.is/t/event-cycle/1117 [15:20] jam, thanks [15:20] https://discourse.juju.is/t/charm-hooks/1040 and https://discourse.juju.is/t/the-hook-environment-hook-tools-and-how-hooks-are-run/1047 are also relevant [15:22] Chipaca: :: ERROR: Could not detect requirement name for 'git+https://github.com/canonical/operator.git', please specify one with #egg=your_package_name [15:22] super strange, i've got that here and it works [15:22] Chipaca: also tried to remove the @master, but then, read-only filesystem again [15:22] ballot: this is with charmcraft 0.3 from the snap, yes? [15:23] Chipaca: yes [15:23] facubatista: ^ any ideas? [15:23] Chipaca: I think I know what happens, I just need to find in pip where is the default location for pulling the dependencies [15:24] Chipaca: ah, that's the "-e" [15:24] Chipaca: it works without the "-e" [15:24] augh [15:24] yeah right, makes sense [15:24] i totally ignored that :-) [15:24] * Chipaca needs a better parser in his brain [15:24] the -e tries to install it in your home or something? [15:24] it's the "develop" thing [15:25] Chipaca, I though it was why you suggested to use a simpler line [15:25] It's to point toward the module you're working on so you don't have to update your env [15:25] facubatista: yes, I missread, and did remove the "-e" [15:25] yep, like 'python setup.py develop' [15:26] ballot: but if you did that for a charm, you'd end up with a .pth and not the actual code you need inside your charm, right? [15:26] anyway, I don't think using -e makes sense for a charm anyway [15:26] Chipaca: yeah, it was merely a bad habit on my side [15:27] sounds like an argument against charmcraft supporting 'full' requirement.txt [15:27] :-/ [15:27] * Chipaca oh noes [15:27] sorry :/ [15:27] facubatista: maybe we should detect and fail early or with a clearer message [15:28] Chipaca: does charmcraft support constraints files ? [15:28] ballot: no [15:28] Chipaca, let's use fades, that doesn't support "-e" :p [15:29] ballot: but not because of philosophical reasons, just nobody's asked us :-) [15:30] Chipaca: well, "priorities" :) [15:31] Chipaca: I'm not sure it's worth spending time on it right now. The only use case I see is if the application code and charm are hosted on the same repository, then to limit in one place some module version for the app, the charm and the tests, it's better to use constraints rather than repeating the limitation in all requirements.txt [15:33] k [15:33] i need to step out (physio! here's hoping for a better back) [15:35] Chipaca: np, thanks !: [15:35] My tests are running now :) [15:35] (well failing of course, as one would expect, but for good reasons now) [15:45] :-D [15:45] * Chipaca disappears into the sunset [21:25] * facubatista eods