[07:45] <axino> hi
[07:45] <axino> is it expected that my very basic charm weights ~10MB ?
[08:03] <xavpaice> crikey what did you put in there, a video instruction on installation?
[08:25] <xavpaice> just checked one or two of my operator charms, yeah they really are that big
[08:25] <xavpaice> git submodule and all that - though the charmcraft setup might change that quite a bit
[08:53] <axino> I think it was ~300k a few days ago
[08:53] <axino> and was deploying fine
[09:50] <axino> I just removed the venv and it's back to ~300k
[09:50] <axino> and it deploys fine
[09:51] <Chipaca> axino: 'sup
[09:51] <axino> Chipaca: my charm was ~10M big because it included "venv" and a full python3.6 distro
[09:52] <Chipaca> axino: ! how
[09:52] <Chipaca> axino: steps to repro plz?
[09:52] <axino> Chipaca: that's what happens if you follow README.md
[09:52] <axino> from charmcraft init
[09:52] <axino> (I'm developping on a 18.04 machine btw)
[09:53] <Chipaca> axino: with charmcraf from beta, or edge?
[09:53] <axino> Chipaca: edge
[09:54] <axino> Chipaca: I ran "charmcraft init" on Aug 17 though
[09:54] <axino> if that helps
[09:54] <Chipaca> no, yes, totally, i can see what's happening now
[09:54] <Chipaca> axino: this is more of the issue we were discussing last night
[09:54] <Chipaca> axino: two workarounds to unblock you while we address it
[09:55] <axino> Chipaca: I added "venv" to .jujuignore and it seems to work
[09:55] <Chipaca> axino: 1. add the venv to .jujuignore
[09:55] <axino> :)
[09:55] <Chipaca> yeah :-)
[09:55] <Chipaca> axino: 2. was to create the venv outside of the project
[09:55] <Chipaca> axino: 3. was to run charmcraft from beta instead of edge
[09:57] <Chipaca> 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] <axino> Chipaca: or just add venv to the jujuignore generated by charmcraft init ?
[09:58] <Chipaca> it already has /env
[09:58] <Chipaca> which might be a tyop
[09:58] <axino> Chipaca: ah
[09:58] <Chipaca> so, yeah
[09:58] <axino> Chipaca: because I saw /env and was wondering why it was there
[10:00] <Chipaca> yeah i'll push a fix that just env->venv in README.md.j2
[10:01] <Chipaca> what we were discussing last night was venv in the generated charm, which isn't a venv at all
[10:01] <Chipaca> so not really related to this
[10:02] <bthomas> Chipaca: Are you free anytime today for a 1:1 ?
[10:02] <Chipaca> bthomas: sure. in 30?
[10:03] <bthomas> thanks. will wait for you ping
[10:40] <Chipaca> bthomas: belated ping
[10:41] <Chipaca> bthomas: standup meet
[10:41] <bthomas> Chipaca: yep going there now
[10:49] <Chipaca> I HELPED!
[10:49]  * Chipaca celebrates
[10:57] <bthomas> Yep : thank you Chipaca
[10:58] <bthomas> ops-lib-k8s is not in pypi so I guess I have to add it as git repo to requirements.txt
[10:59] <facubatista> ¡Muy buenos días a todos!
[10:59] <Chipaca> bthomas: correct
[10:59] <Chipaca> facubatista: ｇｏｄ  ｍｏｒｎｉｎｇ！
[10:59] <bthomas> Morning facubatista
[10:59] <Chipaca> hah!
[11:00] <bthomas> I was faster but didn't get the font right
[11:00] <Chipaca> facubatista: you have been blessed by the gods of $RANDOM
[11:00]  * bthomas hail facubatista 
[11:00] <facubatista> Chipaca, that's me, hello
[11:00] <facubatista> hola bthomas
[11:01] <Chipaca> how 'eval printf "o%.0s" {2..$((RANDOM/512))}' can result in 'god' requires some thought
[11:02] <facubatista> Chipaca, carrot time
[11:02]  * Chipaca goes
[12:11] <bthomas> 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] <bthomas> Also "eval printf "o%.0s" {2..1}" produces oo and {2..0} produces ooo
[12:39] <mup> Issue operator#387 opened: passing k8s_resources to pod.set_spec() requires a dict with a single key "kubernetesResources" <Created by axinojolais> <https://github.com/canonical/operator/issues/387>
[13:05] <Chipaca> bthomas: update-status-hook-interval is documented as having a minimum of 1m
[13:07] <Chipaca> facubatista: i'm back fwiw
[13:08] <facubatista> Chipaca, let's do it
[13:09] <facubatista> Chipaca, same than before?
[13:10] <Chipaca> facubatista: actually, give me a minute to get a quick coffee thing
[13:10] <facubatista> Chipaca, ack, I'm there
[13:11] <bthomas> 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] <Chipaca> bthomas: are you doing a pod-set-spec and then waiting, in the same hook, for the pod to come up?
[13:13] <Chipaca> facubatista: did you drop?
[13:13] <bthomas> Chipaca: yes that looks to be the case .
[13:13] <bthomas> I have not changed this from the original charm.
[13:14] <Chipaca> bthomas: that's not going to work; pod-set-spec is done once the hook finishes successfully
[13:14] <facubatista> Chipaca, nop, https://meet.google.com/eyx-jtan-dac
[13:27]  * justinclark awake
[14:03] <justinclark> 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] <justinclark> Here's the interface_http.py file: https://github.com/justinmclark/grafana-charm-base/blob/grafana-base/src/interface_http.py
[14:04] <facubatista> 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] <justinclark> Sounds great. No rush. Thanks facubatista
[14:24] <deej> 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] <Chipaca> justinclark: was your review of charmcraft#124 a +1?
[14:30] <mup> PR charmcraft#124: cope with bionic's slightly broken pip3 command <Created by chipaca> <https://github.com/canonical/charmcraft/pull/124>
[14:31] <justinclark> Oh yes sorry about that Chipaca. Just gave it the official +1
[14:36] <deej> Chipaca: https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345
[14:47] <deej> Chipaca: https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606
[14:47] <deej> Line 285 of that diff, I was hoping for a cleaner way to do that
[14:48] <deej> 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] <deej> So I guess it's sort of a matter of best practices for how to store data structures in state
[14:51] <Chipaca> 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] <mthaddon> 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] <deej> 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] <Chipaca> 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] <Chipaca> I mean, given set_default, an update makes sense
[14:54] <Chipaca> i
[14:54] <Chipaca> i'll file a bug
[14:55] <deej> ta
[14:55] <deej> Awesome
[15:00] <Chipaca> deej: #388
[15:00] <mup> Issue #388: give BoundStoreState an update method to set multiple things <Created by chipaca> <https://github.com/canonical/operator/issues/388>
[15:00] <mup> Issue operator#388 opened: give BoundStoreState an update method to set multiple things <Created by chipaca> <https://github.com/canonical/operator/issues/388>
[15:08] <Chipaca> facubatista: did you get to see that library with super interesting progress bars i shared a while ago?
[15:09] <facubatista> Chipaca, I don't remember which one... I know about this https://pypi.org/project/progress/ and https://tqdm.github.io/
[15:11] <Chipaca> facubatista: https://github.com/willmcgugan/rich
[15:13] <Chipaca> facubatista: it's rather big, but of interest to us are the tables and the progress bar i think
[15:13] <Chipaca> but it might be too much also :)
[15:25] <facubatista> Chipaca, we can revisit it when we get the order to show help messages with markdown format
[15:26] <Chipaca> facubatista: FINE
[15:26] <Chipaca> facubatista: :-p
[15:26] <facubatista> :)
[15:29] <Chipaca> have i mentioned how weird python is in windows
[15:31] <Chipaca> the actual weirdest thing is how much stuff just works
[15:31] <Chipaca> the second thing is the stuff that doesn't :)
[15:31] <mthaddon> so basically everything is weird
[15:32] <facubatista> Chipaca, meeting
[15:32] <Chipaca> already?
[15:32] <Chipaca> mthaddon: oh yeah. and slow.
[15:54] <Chipaca> bthomas: 1 min and then we meet
[15:54] <bthomas> Thanks Chipaca
[15:55] <bthomas> Chipaca: we can't use the standup meeting url so https://meet.google.com/mhc-svks-wnx
[16:14] <Chipaca> justinclark: i'm not sure i followed what you meant in #378 but the fix addresses the issue you point out
[16:14] <mup> Issue #378: Docstyle for `ops` is Google doc style but parsed with Sphinx <Created by justinmclark> <https://github.com/canonical/operator/issues/378>
[16:15] <bthomas> 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] <Chipaca> bthomas: if you arrange it into opslib directly in your charm, we can look at pulling it out next week
[16:16] <bthomas> will do
[16:17] <Chipaca> 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] <Chipaca> bthomas: also I don't think it has any tests
[16:17] <Chipaca> so that's a problem
[16:17] <bthomas> Understood. That is a fair. I like fair :).
[16:18] <Chipaca> 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] <bthomas> Ok. It proabably is for me right now.
[16:20] <Chipaca> that's also fair :)
[16:21] <bthomas> :)
[16:32] <Chipaca> facubatista: ping
[16:32] <facubatista> Chipaca, meeting
[16:32] <Chipaca> facubatista: one I should be in?
[16:32] <facubatista> Chipaca, don't know, nvidia one
[16:33] <Chipaca> facubatista: can you run charmcraft from your commands-long-help branch? i have a question for you
[16:33] <facubatista> run it how?
[16:34] <Chipaca> facubatista: to see the help for build and for login
[16:36] <facubatista> Chipaca, https://pastebin.canonical.com/p/7WnxW75jBt/
[16:36] <Chipaca> facubatista: so, do you want the overview indented as in build, or not as in login?
[16:37] <Chipaca> i like it slightly indented as the build one but noted you use dedent elsewhere
[16:43] <justinclark> 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] <facubatista> Chipaca, ah, got it! No identation, please
[16:54] <Chipaca> facubatista: wrt version, i think we should drop "Version: " from its output
[16:59] <facubatista> Chipaca, want me to include that change in this branch:
[16:59] <facubatista> ?
[16:59] <Chipaca> facubatista: i'm editing them as you requested
[16:59] <facubatista> (in the long-commands-help, I mean)
[16:59] <Chipaca> oh wait you mean Version:?
[16:59] <Chipaca> could be:)
[17:02] <Chipaca> i'm struggling with some of these texts but we can revisit, right?
[17:18] <Chipaca> facubatista: pushed, please let me know what you think
[17:18]  * facubatista checks
[17:20] <Chipaca> and i bungled something up, pushing a fix
[17:22] <facubatista> 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] <facubatista> Chipaca, also, need to update version's test
[17:25] <Chipaca> psh
[17:25] <Chipaca> fixing
[17:25] <facubatista> Chipaca, beyond those two details, I like it
[17:25] <facubatista> so we need just a third eye on the branch
[17:27] <Chipaca> facubatista: ꙮ
[17:28] <facubatista> ja
[17:30] <Chipaca> facubatista: wrt the quotes, probably, and we should probably use the right quotes also
[17:31] <Chipaca> facubatista: in this case the “right” quotes are ‘these’
[17:35] <facubatista> Chipaca, as you wish, I'm a quote impaired person
[17:37] <Chipaca> facubatista: http://www.eng-lang.co.uk/ogs.htm
[17:37] <Chipaca> facubatista: probably
[17:38] <Chipaca> 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] <Chipaca> ANYway
[17:38] <Chipaca> EOW for me babyy
[17:39] <facubatista> yes, that's quoting
[17:39]  * Chipaca sets the room on fire and runs away
[17:39] <facubatista> I use " for that
[17:39] <facubatista> I don't like the assymetric ones
[17:39] <facubatista> and I almost hate the "compressed double greater/less than"
[17:54] <justinclark> 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] <justinclark> [1] https://git.launchpad.net/charm-grafana/tree/src/reactive/grafana.py
[17:56] <justinclark> We'd have to setup persistent storage if using the grafana docker container but that's easy enough to do.
[17:56] <justinclark> 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] <facubatista> justinclark, don't know either
[18:07] <facubatista> justinclark, there are significant versions difference between snap's and repo's?
[18:18] <justinclark> It doesn't look like repo vs. snap have significant version differences
[18:18] <justinclark> facubatista ^
[18:20] <facubatista> justinclark, which is the benefit of using a container image over "snap install grafana"?
[18:23] <justinclark> 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] <justinclark> Snap does seem easier though
[18:27] <drewn3ss> 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] <drewn3ss> it's lighter from an operational perspective
[18:28] <drewn3ss> 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] <drewn3ss> in fact, the cdk-addons uses the grafana/influx container image
[18:30] <drewn3ss> but that product lacks the persistent volume storage for upgradability and node failover management
[18:35] <justinclark> 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] <mup> PR operator#389 opened: minor docs fix <Created by justinmclark> <https://github.com/canonical/operator/pull/389>