[07:45] hi [07:45] is it expected that my very basic charm weights ~10MB ? [08:03] crikey what did you put in there, a video instruction on installation? [08:25] just checked one or two of my operator charms, yeah they really are that big [08:25] git submodule and all that - though the charmcraft setup might change that quite a bit [08:53] I think it was ~300k a few days ago [08:53] and was deploying fine [09:50] I just removed the venv and it's back to ~300k [09:50] and it deploys fine [09:51] axino: 'sup [09:51] Chipaca: my charm was ~10M big because it included "venv" and a full python3.6 distro [09:52] axino: ! how [09:52] axino: steps to repro plz? [09:52] Chipaca: that's what happens if you follow README.md [09:52] from charmcraft init [09:52] (I'm developping on a 18.04 machine btw) [09:53] axino: with charmcraf from beta, or edge? [09:53] Chipaca: edge [09:54] Chipaca: I ran "charmcraft init" on Aug 17 though [09:54] if that helps [09:54] no, yes, totally, i can see what's happening now [09:54] axino: this is more of the issue we were discussing last night [09:54] axino: two workarounds to unblock you while we address it [09:55] Chipaca: I added "venv" to .jujuignore and it seems to work [09:55] axino: 1. add the venv to .jujuignore [09:55] :) [09:55] yeah :-) [09:55] axino: 2. was to create the venv outside of the project [09:55] axino: 3. was to run charmcraft from beta instead of edge [09:57] I suspect the fix is just to add "add venv to jujuignore" to the generated README, because "include everything not in jujuignore" has exactly this consequence, and it's what people requested [09:58] Chipaca: or just add venv to the jujuignore generated by charmcraft init ? [09:58] it already has /env [09:58] which might be a tyop [09:58] Chipaca: ah [09:58] so, yeah [09:58] Chipaca: because I saw /env and was wondering why it was there [10:00] yeah i'll push a fix that just env->venv in README.md.j2 [10:01] what we were discussing last night was venv in the generated charm, which isn't a venv at all [10:01] so not really related to this [10:02] Chipaca: Are you free anytime today for a 1:1 ? [10:02] bthomas: sure. in 30? [10:03] thanks. will wait for you ping [10:40] bthomas: belated ping [10:41] bthomas: standup meet [10:41] Chipaca: yep going there now [10:49] I HELPED! [10:49] * Chipaca celebrates [10:57] Yep : thank you Chipaca [10:58] ops-lib-k8s is not in pypi so I guess I have to add it as git repo to requirements.txt [10:59] ¡Muy buenos días a todos! [10:59] bthomas: correct [10:59] facubatista: ｇｏｄｍｏｒｎｉｎｇ！ [10:59] Morning facubatista [10:59] hah! [11:00] I was faster but didn't get the font right [11:00] facubatista: you have been blessed by the gods of $RANDOM [11:00] * bthomas hail facubatista [11:00] Chipaca, that's me, hello [11:00] hola bthomas [11:01] how 'eval printf "o%.0s" {2..$((RANDOM/512))}' can result in 'god' requires some thought [11:02] Chipaca, carrot time [11:02] * Chipaca goes [12:11] I do not see logs from my charm in juju debug-log. Will it make juju unresponsive if I set juju model-config update-status-hook-interval to a few seconds ? [12:14] Also "eval printf "o%.0s" {2..1}" produces oo and {2..0} produces ooo [12:39] Issue operator#387 opened: passing k8s_resources to pod.set_spec() requires a dict with a single key "kubernetesResources" [13:05] bthomas: update-status-hook-interval is documented as having a minimum of 1m [13:07] facubatista: i'm back fwiw [13:08] Chipaca, let's do it [13:09] Chipaca, same than before? [13:10] facubatista: actually, give me a minute to get a quick coffee thing [13:10] Chipaca, ack, I'm there [13:11] Chipaca: I am hosed then, am i not ? How do I debug why both original and refactored charms do not progress beyond waiting for pod to be setup ? [13:12] bthomas: are you doing a pod-set-spec and then waiting, in the same hook, for the pod to come up? [13:13] facubatista: did you drop? [13:13] Chipaca: yes that looks to be the case . [13:13] I have not changed this from the original charm. [13:14] bthomas: that's not going to work; pod-set-spec is done once the hook finishes successfully [13:14] Chipaca, nop, https://meet.google.com/eyx-jtan-dac [13:27] * justinclark awake [14:03] Question Chipaca/facubatista: I'm working on the GrafanaBase charm that has all the shared functionality between k8s and non-k8s and I think have an HTTP interface that works, but I want to get feedback in case I'm doing something silly. [14:03] Here's the interface_http.py file: https://github.com/justinmclark/grafana-charm-base/blob/grafana-base/src/interface_http.py [14:04] justinclark, let's talk in the standup? I'm in a meeting and have another one before that (I mean, standup is the earliest slot I may have to provide you feedback) [14:05] Sounds great. No rush. Thanks facubatista [14:24] https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606 <- Chipaca facubatista for our call in a few, though 90% of that is Docker stuff [14:30] justinclark: was your review of charmcraft#124 a +1? [14:30] PR charmcraft#124: cope with bionic's slightly broken pip3 command [14:31] Oh yes sorry about that Chipaca. Just gave it the official +1 [14:36] Chipaca: https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345 [14:47] Chipaca: https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606 [14:47] Line 285 of that diff, I was hoping for a cleaner way to do that [14:48] Though if I go with facubatista's suggestion of storing a dict in the state and unpacking it when I do the pod configuration, that solves that issue for me [14:48] So I guess it's sort of a matter of best practices for how to store data structures in state [14:51] deej: so a dict works, but if you'd rather use a class because db.user is better than db['user'], you can do one of two things: write an actual class with the appropriate methods, or, use a namedtuple and explicitly build it from state [14:51] Chipaca, facubatista: have ~charmcrafters as a requested reviewer for https://code.launchpad.net/~axino/charm-k8s-gunicorn/+git/charm-k8s-gunicorn/+merge/389554 fwiw (sorry for so many at once) [14:51] Chipaca: Nah, a dict totally works, I'm not fussy [14:52] * Chipaca marks them Disapprove and moves on [14:54] * mthaddon cries :( [14:54] deej: OTOH WRT that line in the diff itself, there isn't currently a better way but I don't see why we couldn't have one [14:54] I mean, given set_default, an update makes sense [14:54] i [14:54] i'll file a bug [14:55] ta [14:55] Awesome [15:00] deej: #388 [15:00] Issue #388: give BoundStoreState an update method to set multiple things [15:00] Issue operator#388 opened: give BoundStoreState an update method to set multiple things [15:08] facubatista: did you get to see that library with super interesting progress bars i shared a while ago? [15:09] Chipaca, I don't remember which one... I know about this https://pypi.org/project/progress/ and https://tqdm.github.io/ [15:11] facubatista: https://github.com/willmcgugan/rich [15:13] facubatista: it's rather big, but of interest to us are the tables and the progress bar i think [15:13] but it might be too much also :) [15:25] Chipaca, we can revisit it when we get the order to show help messages with markdown format [15:26] facubatista: FINE [15:26] facubatista: :-p [15:26] :) [15:29] have i mentioned how weird python is in windows [15:31] the actual weirdest thing is how much stuff just works [15:31] the second thing is the stuff that doesn't :) [15:31] so basically everything is weird [15:32] Chipaca, meeting [15:32] already? [15:32] mthaddon: oh yeah. and slow. [15:54] bthomas: 1 min and then we meet [15:54] Thanks Chipaca [15:55] Chipaca: we can't use the standup meeting url so https://meet.google.com/mhc-svks-wnx [16:14] justinclark: i'm not sure i followed what you meant in #378 but the fix addresses the issue you point out [16:14] Issue #378: Docstyle for `ops` is Google doc style but parsed with Sphinx [16:15] Thanks for you time Chipaca : I am also going to explore adding OCI resource feature to opslib, after looking at available implementations. If you have a preferred approach in this regard, do mention it. [16:16] bthomas: if you arrange it into opslib directly in your charm, we can look at pulling it out next week [16:16] will do [16:17] bthomas: my main concerns are wrt who the original author is, and ensuring when we do split it we bring authorage information along so we're not stealing without crediting it :) [16:17] bthomas: also I don't think it has any tests [16:17] so that's a problem [16:17] Understood. That is a fair. I like fair :). [16:18] bthomas: ultimately if it's more than a half hour of shunting code around just leave it and i can pick it up next week [16:19] Ok. It proabably is for me right now. [16:20] that's also fair :) [16:21] :) [16:32] facubatista: ping [16:32] Chipaca, meeting [16:32] facubatista: one I should be in? [16:32] Chipaca, don't know, nvidia one [16:33] facubatista: can you run charmcraft from your commands-long-help branch? i have a question for you [16:33] run it how? [16:34] facubatista: to see the help for build and for login [16:36] Chipaca, https://pastebin.canonical.com/p/7WnxW75jBt/ [16:36] facubatista: so, do you want the overview indented as in build, or not as in login? [16:37] i like it slightly indented as the build one but noted you use dedent elsewhere [16:43] facubatista it looks like others have had to check if event.unit is None. e.g. https://github.com/canonical/operator/issues/175#issuecomment-597042504 [16:48] Chipaca, ah, got it! No identation, please [16:54] facubatista: wrt version, i think we should drop "Version: " from its output [16:59] Chipaca, want me to include that change in this branch: [16:59] ? [16:59] facubatista: i'm editing them as you requested [16:59] (in the long-commands-help, I mean) [16:59] oh wait you mean Version:? [16:59] could be:) [17:02] i'm struggling with some of these texts but we can revisit, right? [17:18] facubatista: pushed, please let me know what you think [17:18] * facubatista checks [17:20] and i bungled something up, pushing a fix [17:22] Chipaca, I see it now (it was in my original text, I think): if we quote "latest", shouldn't we also quote edge, beta, etc? or unquote them all? [17:25] Chipaca, also, need to update version's test [17:25] psh [17:25] fixing [17:25] Chipaca, beyond those two details, I like it [17:25] so we need just a third eye on the branch [17:27] facubatista: ꙮ [17:28] ja [17:30] facubatista: wrt the quotes, probably, and we should probably use the right quotes also [17:31] facubatista: in this case the “right” quotes are ‘these’ [17:35] Chipaca, as you wish, I'm a quote impaired person [17:37] facubatista: http://www.eng-lang.co.uk/ogs.htm [17:37] facubatista: probably [17:38] facubatista: «Use quotation marks to enclose an unfamiliar word or phrase, or one to be used in a technical sense. The effect is similar to that of highlighting the term through italics» [17:38] ANYway [17:38] EOW for me babyy [17:39] yes, that's quoting [17:39] * Chipaca sets the room on fire and runs away [17:39] I use " for that [17:39] I don't like the assymetric ones [17:39] and I almost hate the "compressed double greater/less than" [17:54] I noticed the reactive, non-k8s Grafana charm [1] is using snap/apt to install Grafana. Is this preferred to using a container image (for non-k8s charms)? I'm sure this partly depends on the app itself but I didn't know if there are best practices for charmers. [17:54] [1] https://git.launchpad.net/charm-grafana/tree/src/reactive/grafana.py [17:56] We'd have to setup persistent storage if using the grafana docker container but that's easy enough to do. [17:56] I suppose docker would also need to be running on the unit which could be a hassle (but I don't know that for sure) [18:07] justinclark, don't know either [18:07] justinclark, there are significant versions difference between snap's and repo's? [18:18] It doesn't look like repo vs. snap have significant version differences [18:18] facubatista ^ [18:20] justinclark, which is the benefit of using a container image over "snap install grafana"? [18:23] facubatista, Since k8s requires a container image for the pod spec, I figured I'd see if using that same container image is just as easy to use in the non-k8s charm. Again, this is just me trying to find the overlap between k8s and non-k8s charms. [18:23] Snap does seem easier though [18:27] honestly, the history is that all lma/infra charms were moved to using snaps for A) dogfooding, and B) ease of iteration and installation and auto-updating nature of snaps. [18:27] it's lighter from an operational perspective [18:28] but if youre moving into a containerized world, and can build processes around managing container images like we have for managing snapcraft files in upstream projects, I don't see why a move to containers instead of snaps would be a problem. [18:30] in fact, the cdk-addons uses the grafana/influx container image [18:30] but that product lacks the persistent volume storage for upgradability and node failover management [18:35] Ah okay that makes sense drewn3ss. Whatever will make things easier people down the line is what I'll end up doing. Right now I'm experimenting so I won't make decisions that will lock anyone into a particular way of doing things. [18:54] PR operator#389 opened: minor docs fix