[04:44] morning all [07:33] moin moin moin [07:57] Issue operator#224 opened: [Idea] provide some form of scaffolding [07:58] morning Chipaca [07:58] jam: how's things? [07:58] Pretty good. how are things with you? [07:59] jam: not bad. I'm not in hospital, so that's winning, right? [07:59] Chipaca, yeah, not sick, stuck at home, but healthy and well fed. :) [07:59] jam: on a less serious note I managed to install windows on my work laptop without nuking the linux installation (not even grub) so that's also a plus [08:00] so that should help dell figure out what's going on with it without having to come out [08:00] Chipaca, ah, dell requires Windows to do support? [08:00] normally i would've gone "i bought this with linux off of you, do your job", but that would've meant sending someone out just to figure it out [08:00] I'm surprised you didn't have to reinstall grub [08:01] jam: remote diagnostics, yes, apparently it's a windows-only thing [08:01] jam: me too! apparently uefi means windows is not as aggressive to the bootloader as it used to be [08:03] * Chipaca wonders what happened to issue 224 [08:03] Issue #224: [Idea] provide some form of scaffolding [08:03] yep, 404ing for me [08:03] ran away ? [08:03] but mup seems to find it [08:04] found it from https://github.com/canonical/operator/issues/224 [08:04] Chipaca, mup has a bad url [08:04] 'issue/224' vs 'issues/224' [08:04] ah [08:04] niemeyer: ^ that one's on you probably [08:04] the mup issue i mean :) [08:09] Chipaca, the email from Sohini "Weekly Update". Elements we will be working to prioritize with the charmtech team [08:09] mhmm [08:09] "Options" seems particularly misplaced, as options only exists because of reactive (AIUI) [08:10] (they had an options section as a way to configure a layer, but since we use instantiation of a class as the way to 'bring in a component' it doesn't feel like you need YAML config.) [08:10] jam: I have no idea what that is, so I'll believe you =) [08:10] unless I'm misunderstanding what they were trying to do. [08:10] Chipaca, it sounds like we need to be having some form of discussion with whoever is asking for these things ): [08:10] :) [08:11] I missed sohini yesterday with my hardware shenanigans, but will catch up today [08:11] Sorry, I'll get that mup issue fixed today.. waited to fix it in that batch of changes but missed it [08:11] Debug as an action is something I'm curious about. [08:11] wait, tomorrow (it's moved) [08:12] jam: debug-as-an-action i imagine is "have an action that's just for using via debug-hook" but irunno [08:13] i'm good at imagining stuff :-| [08:13] Chipaca, maybe. Or maybe it's 'juju run-action --wait debug' which dumps out a databag of stuff you might want to figure out what the charm is doing [08:13] but as a line-item its a bit ill defined. [08:17] Chipaca, I've been trying to think about how we could handle 'ensuring enough packages are installed by the time you get to your charm code'. [08:18] jam: any conclusions so far? [08:18] The problem being you can't just put "import external_lib" at the top of your src/charm.py because when the install hook runs nothing is installed yet [08:18] Chipaca, so I think you can do things like lazy importing (wait to import until you need it), and put it in install, but it all feels a bit cludgy. [08:18] jam: if it's just an import yes, the problem is if you need a system package, isn't it? [08:18] I was considering being evil and saying that 'hooks/install' runs before Charm.on.install, and you can put your dependency handling in there. [08:19] but you still have the problem of src/charm.py struggling to start up if you do it the 'natural' way [08:19] Chipaca, right, so if you have "on_start(): import package"; but "on_install(): import ops.apt; ops.apt.install(python-package)" [08:19] you could make it work [08:19] but it does feel kludgy [08:20] jam: wait, why a python package? [08:20] 'system package' i meant something like postgres [08:20] Chipaca, so for system packages generally, you can just apt install it during on_install so no problem [08:20] right [08:20] the problem, IMO, is python packages needing to be installed before your charm can import them. [08:20] and python packages should be in the charm already [08:21] via the build step [08:21] (of course this is me living in the future where the build tool is done and platform is a thing) [08:21] Chipaca, how does the PYTHONPATH get setup to find them? [08:21] jam: properly [08:22] :) [08:22] jam: but more seriously, via having the charm.py shepang point at something that sets up the pythonpath [08:22] So *a* step needs to rewrite something for '/var/lib/juju/agents/unit-/charm/???' to be a place that we can satisfy imports from, right? [08:23] shebang* [08:23] jam: whether that something is a virtualenv python, or just a wrapper, i don't know yet (nor particularly care), but both would work [08:23] Chipaca, but what rewrites that path? [08:23] and what installs the venv? [08:23] jam: the build step [08:24] Chipaca, how does that handle the fact that it installs to a different path-on-disk during 'juju deploy' ? [08:24] relative paths? [08:24] eg, what sets up the venv on the target system [08:24] we package a python binary in the charm? [08:25] relative paths should work, we need to test that [08:25] otherwise things get even more interesting [08:25] i'd rather not ship a python binary in the charm but i'm not ideologically opposed to it [08:26] all it _should_ take in my mind is a wrapper to set up the environ before calling system python [08:26] but i have yet to carve out time to play with this [08:26] Chipaca, does that wrapper end up being 'dispatch' ? [08:27] jam: that could work also [08:27] Isn't all that what we already have? [08:27] niemeyer: what do you mean? [08:29] I'm just trying to understand what the discussion was about.. it sounds like we have what was being described: [08:30] A wrapper that sets up Python paths and calls the charm, including known locations inside the charm in sys.path [08:31] niemeyer: are you still writing? [08:32] No :) [08:32] We need a mup plugin.. [08:32] niemeyer: where do we have that wrapper? [08:33] Chipaca: dispatch, per jam note [08:33] niemeyer: where is it [08:33] the wrapper, where, on github, is it [08:34] Chipaca: Wasn't support for dispatch in jam's agenda? [08:34] niemeyer: you said we already have what was being described; where do we have it? [08:36] Chipaca: It's not implemented.. it's agreed, in jam's agenda, in juju development code as well.. I was simply asking if that's what the discussion was about.. not sure why we're now arguing about where in GitHub it is? [08:37] I think the confusion is that we were discussing how it should hang together, and you seemed to claim that while we have plans for it, we haven't actually implemented those yet. And I was asking about concretely how it would/should function. [08:37] niemeyer: because "Isn't that what we already have?" shuts down the discussion we were having [08:38] Do we bundle what would otherwise be system libs, so that it is all served from a not-touched-by-the-system venv. [08:38] niemeyer: so, as you shut down the discussion, I'm calling you out so that you explain yourself [08:38] Oh my.. You know you can say "no, because...".. right? [08:39] Chipaca: I literally said "I'm just trying to understand".. [08:39] niemeyer: yes, now that I know what you meant, I can say that, but the discussion is still dead and needs resurrecting to continue it [08:39] yeah [08:39] Sorry, I'm stepping out.. I'm not in a good vibe to have this kind of discussion right now [08:42] Might want to look at charms.reactive bootstrap process. It setup a virtualenv (so subordinates are insulated from version conflicts with primaries), installs python dependencies and deb packages, then reinvokes itself with the virtualenv interpreter. [08:44] stub, indeed. I have looked at it a bit, though actually finding where the bits are is a bit convoluted, and hidden behind the various yaml definitions, etc. [08:44] Trying to determine if the only way is to go via wheelhouses with full depedencies and isolated venvs [08:44] I think it was mostly in layer:base [08:44] It also built stuff in production, which seems unwise [08:44] wheelhouses were a pain because we want platform independent, and wheels are not always [08:44] But stub is right, it's some incarnation of that [08:45] incarceration of that? [08:45] :) [08:45] And we should definitely learn from it [08:45] jam: to much covid [08:45] too much [08:47] stub: Is there a way to avoid the platform dependency, though? [08:47] stub: I would love to justify having pure python charms, but the conversations so far make me believe we can't do without [08:48] I think my problems were due to having old versions of setuptools/distutils etc. in the chain. And python dependencies that built C extensions even when they were told not too (looking at you cassandra client) [08:48] stub: Wheelhouses also feels like an insufficient solution in the sense we need to carry C lib dependencies, etc [08:48] stub: Building *in deployment* right? Yeah, we need to kill that [08:49] I think I hit both cases. Things building in deployment, and things building at build time and embedding platform dependent shared libraries. [08:50] Yes, we want to avoid both. [08:50] stub: You mean shared libraries that have unsatisfied symbols at the target? [08:50] stub, so why not use the platform libs for interacting with the platform app that you're installing? [08:51] * Chipaca steps out for a bit [08:51] amd64 shared libraries getting embedded in the charm, which isn't going to work if someone tries to deploy on z-series [08:51] jam: There are not always platform libraries, and offline deployments make pulling them in from PPAs a pain. [08:52] (it feels like venvs reinvent the distribution problem, which is the point of distribution platforms) [08:52] The cassandra charm needed to connect to cassandra, which has a really fat client with c extensions and a complex build and not in Ubuntu main or universe. [08:53] jam: Yeah, and I don't know how to get charms forward without us diving into that for the hundredth time [08:53] The original charm pulled it in from a PPA. The reactive rewrite managed to get it from the wheelhouse. [08:53] I would love to just be able to say "charms need to be pure Python" [08:53] stub, but still had to compile it for the arch? [08:53] But it sounds unrealistic [08:54] jam: I think I managed to get it to avoid building the C extensions ('charm build' tries to enforce that, but it didn't work). But I would not be surprised to find amd64 specific shared libraries in the wheels. [08:57] niemeyer: 'charms need to be pure Python' may well be the best approach. Bootstrap can inject platform specific binaries before the main charm.py is imported. Bootstrap installing deb packages would solve 90% of the use cases. [08:58] stub: The issue with recommending that is that we force charmers to become deb packagers as well.. and not only that.. we now need alternative binary deployment strategies for every platform [08:58] stub, certainly the Juju model that charms are architecture independent was premised on arch specific things would be handled at the apt layer [08:58] bbiab, making coffe [08:58] Other 10% would be weirder stuff, like pulling a tarball from a Juju resource (say, a JVM). Or installing wheels from a wheelhouse. [08:59] stub: That's why I'm finding difficult to workaround the need for charms to become yet another binary package [08:59] Yes, 'learn to package debs' is a high barrier to entry :-/ [08:59] and distribute! [09:00] ... and even then not have a cross-platform strategy [09:07] And it would be sad if it put a heavy burden on charmers dealing with the more common situation, where pure python and maybe a deb package from main. [09:07] Yeah, this case should remain simple [09:15] Maybe it is just a case of declaring arch: ['amd64','arm64'] in metadata.yaml, and having arch/amd64 or arch/arm64 directories added to $PATH and $PYTHONPATH. Fat charms. [09:17] stub: Yeah, that sounds unavoidable as soon as we agree to do binaries [09:17] stub: Otherwise we have no control of the outcome whatsoever [09:17] stub: The new charm hub will also deal with multiple architectures gracefully [09:17] The fat could move to resources, which could be intelligently pulled down (or attached at deploy time for offline deployments). But that is more complex. [09:18] So again we get back to the issue of building and organization of both the source and the result of that operation [09:18] facubatista has that on his agenda, but we don't have something clear yet [09:18] stub, I think resources make a strong case for binary deps [09:19] stub: Agreed about resources [10:45] niemeyer: fwiw facu is waiting for feedback on the build tool email before continuing that work (because he isn't blocked on other fronts) [10:47] brb, rebooting into windows (eugh) [11:10] Muy buenos días a todos! [11:13] * Chipaca now has to decide whether to be without his work laptop for at least a week, or be with an extremly slow laptop until the big Q is over [11:14] morning facubatista [11:14] hola jam [11:14] Chipaca, they just extended ours 'indefinitely' (until further notice) :( [11:15] yeah :-( [11:15] ours isn't going away anytime soon [11:15] facubatista: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄｍｏｒｎｉｎｇ！ [11:16] Chipaca, hola! [11:17] * facubatista is reading previous conversation, why are we discussing AGAIN if we'll freeze a Python binary inside the charm, etc? [11:18] do not discuss this again in the air, let's comment on the proto-spec I created, otherwise we're always in t0 [11:19] facubatista: agreed [11:19] "the problem, IMO, is python packages needing to be installed before your charm can import them." <-- this is already solved, I'm waiting feedback on that [11:19] facubatista: my intention is to play with this stuff based on your build tool thing, and get back to it [11:23] niemeyer, shall we just cancel the weekly 1:1? We can always schedule time to chat when we have a topic instead. [11:30] facubatista, I updated https://docs.google.com/document/d/1RHrOMbqsXz9qwk_3sHJ7AJOdlh-Mb-TkFUAtbXb37Og/edit# with a discussion of the plans for the Operator framework. Feel free to leave comments that we can use to help clarify anything. [11:30] jam, thanks! [11:39] jam, what do you mean with " The intent is that each of those handlers is maintaining its own state engine, "? [11:39] jam, each method registered in my charm should maintain one state engine?? [11:41] facubatista, generally handlers are going to be maintaining some sort of state in response to events. And while they ultimately share some of that state, the intent is that you shouldn't ever stop sending them lifecycle events just because something else is also responding to it. [11:41] facubatista, for your charm "have I written out the blog's static files" "do they need updating" feels like the state engine that you're using. [11:41] the apache interaction of "have I configured apache to serve my files" is separate logic. [11:42] mmm [11:42] I wasn't planning to maintain that state, but maybe I'm too naive? [11:42] I don't think it is usually explicitly model as a state machine, but functionally it is. [11:43] facubatista, for simple charms, I feel it is perfectly fine to determine your state by querying the model, rather than storing it separately. [11:43] if I get the install event it means that I have not written out the static files yet; if I get the upgrade event it means that the install ended correctly, and files are there, etc [11:43] facubatista, but like the pgsql interface needs to know what you've requested of pg, and whether it has told you that it has done its preparations for you (what roles you need, what you want to call your database, etc.) [11:44] jam, sorry, we're moving away from the static files example, right? [11:44] facubatista, so Juju generally guarantees "at least once" events, and otherwise hooks should be idempotent. If something fails, it may call a hook >1 time. [11:45] facubatista, yeah, I was giving a clearer example of a state machine. For static files, your plan seems fine. [11:45] I don't know if there will be config, which might indicate you need to write new files, etc. [11:45] I understand that idempotency, it's orthogonal to needing to have a state machine [11:46] jam, I'm trying to parse you're sentence about pgsql, 1' [11:49] jam, I'd really to "see" that pgsql example; in my mind when I instantiate the PG interface I will tell it whatever I need, then the interface when receives the relation event will configure the DB engine, and trigger the "all ready" event for me [11:49] facubatista, correct. but that is the state engine that the DB component keeps track of. [11:49] 'what did you ask for, has the DB told me that it is ready, ok, ready to fire the DB is ready event" [11:50] my point is: no state machine is needed for that [11:50] "what did you ask for" -> this is stored in the interface [11:51] "has the DB told me that it is ready" -> this is what "receiving the relation event" means [11:51] etc [11:51] (that's why I need to "see" the code, maybe I'm missing parts and/or complexity here) [12:01] facubatista, so that is still a state machine, even if you are storing the state in the interface [12:01] Chipaca, did we forget to add a meet link to the bug revue calendar entry? [12:01] just use standup? [12:01] jam: yeah let's just use standup [12:01] jam, I'm not storing state for a state machine, I'm storing the asked DB engine config [13:07] Issue operator#161 closed: self.model.pod.set_spec should only be run on leader [14:41] Issue operator#225 opened: BoundSharedState changed events is misnamed (or misleading) [14:56] * facubatista brb [15:44] * facubatista -> lunch [16:18] * facubatista is back [17:05] Alright.. off from the last call of the day, and calling it a day [17:05] Have a good eod folks [17:06] niemeyer, have a nice rest [17:27] facubatista: i'm off as well. enjoy the evening solitude! [17:28] facubatista: or, don't. You do you. [17:28] * facubatista is alone in the office, turns the music volume on to the max [20:08] niemeyer, ended trying to collect our thoughts here: https://docs.google.com/document/d/1270Fl9c6NzfMMA71xkqTwyO5nUIyBO6GQnvy34wtH5w/edit# [20:31] * facubatista eods