[07:52] <Chipaca> ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄ  ｍｏｒｎｉｎｇ！
[08:10] <bthomas> Morning Chipaca : Hope you had a good break
[08:10] <mup> PR operator#383 closed: ops/lib: use repr less with paths, and os.path.join more <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/383>
[08:11] <Chipaca> bthomas: I did!
[08:11] <Chipaca> I could've had another day's worth of it :-D
[08:11] <bthomas> Yep. Never enough. :)
[08:12] <Chipaca> dunno, another two days would've had me programming something
[08:12] <Chipaca> one would've gotten me to finish putting up a bit of ikea furniture that's in my backlog
[08:13] <Chipaca> bthomas: how was your weekend?
[08:14] <bthomas> Chipaca: Cleaning the house (not so much fun), Cooking (more fun), doing math (most fun) :-)
[08:14] <Chipaca> :) nice
[08:14] <Chipaca> bthomas: if you're in the mood for little bit of code review, #381 could use that
[08:14] <mup> PR #381: we should call harness.cleanup in unit tests now that we use resources there :-) <Created by chipaca> <https://github.com/canonical/operator/pull/381>
[08:15] <bthomas> Chipaca: will have a look now
[08:15] <Chipaca> and #382 …
[08:15] <mup> PR #382: not all operating systems let you rename over an existing file <Created by chipaca> <https://github.com/canonical/operator/pull/382>
[08:16] <Chipaca> … and #389
[08:16] <mup> PR #389: minor docs fix <Created by justinmclark> <https://github.com/canonical/operator/pull/389>
[08:24] <bthomas> Done.
[08:25] <mup> PR operator#384 closed: make test_infra pass on windows <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/384>
[08:27] <bthomas> Odd. Kubectl config set-context microk8s is not working this morning.
[08:27] <bthomas> oops it is use-context
[08:28] <bthomas> Awesome choice of two command names.
[08:29] <Chipaca> you know more k stuff than i do
[08:29] <Chipaca> what's use-context? (what even is a context)
[08:30] <Chipaca> kubectl needs its version of https://git-man-page-generator.lokaltog.net/
[08:30] <bthomas> Chipaca: I use kubectl to work with both microk8s and minikube. I have a single config file with two contexts, one for each. I can switch which of the two clusters I am working with using use-context.
[08:31] <bthomas> I don't think I know more kube than you. Knowing some silly fact about the ginormous gargutan framework does not count.
[08:31] <Chipaca> isn't that begging for you to forget you're in the wrong context and do unspeakable things to production when you meant to tear down staging?
[08:32] <bthomas> Not if you are an obsessive cumpulsive neat freak and methodical checker :-). But yes you are right there is that risk. But it is quite convienent too. Besides I only run one cluster at a time to reduce power drain on my laptop.
[08:38] <mup> PR operator#385 closed: do not assume / is path separator for resource paths <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/385>
[08:43] <Chipaca> ok travis is already backed up
[08:43] <Chipaca> time for a break
[09:14] <bthomas> My prometheus pod deployed using the charm, seems to be stuck in "PodInitializing" state. describe-pod shows one warning "pod has unbound immediate PersistentVolumeClaims". The charm metadata.yaml has a "storage" section that points to "filesystem". So I am not sure why pod can't get its storage volume.
[09:15] <bthomas> looks like I am in for some hardcore k8s debugging since that is the only way to debug charms on k8s.
[10:07] <mup> Issue operator#378 closed: Docstyle for `ops` is Google doc style but parsed with Sphinx <Created by justinmclark> <Closed by chipaca> <https://github.com/canonical/operator/issues/378>
[10:07] <mup> PR operator#389 closed: minor docs fix <Created by justinmclark> <Merged by chipaca> <https://github.com/canonical/operator/pull/389>
[10:08] <Chipaca> bthomas: if in need of break from hardcore k8s debugging, break glass^W^W click link: https://i.redd.it/qpdsiofjrsi51.jpg
[10:09] <Chipaca> (allegedly taken over the weekend in Richmond Park here in London)
[10:10] <bthomas> Chipaca: that is a very crisp image. I like photography too. Are you an avid photographer ?
[10:10] <bthomas> my camera is a bit old though Nikon D90
[10:11] <bthomas> I can see you have good composition skils -- keeping subject off center
[10:11] <Chipaca> i am not an avid photographer
[10:11] <Chipaca> i am an avid collecter of background images :-p
[10:11] <bthomas> ha ha
[10:12] <Chipaca> bthomas: that one in particular is by u/ageitgey via https://www.reddit.com/r/london/comments/if8luz/richmond_park_tonight/
[10:12] <Chipaca> again, allegedly
[10:14] <bthomas> That thread has a few other good ones too.
[10:15] <Chipaca> ayup
[10:15] <Chipaca> bthomas: the first time i knew i wanted a big 4k monitor was probably a year ago, due to a very similar image
[10:16] <bthomas> Chipaca: you may want to wait a bit. Transparent OLED TVs just came out.
[10:16] <Chipaca> it's still on my wishlist, because there's a list
[10:17] <bthomas> Oh yeah. The wishlist. hmmm
[10:17]  * bthomas goes to national-lottery.co.uk
[10:18] <Chipaca> bthomas: there's always something that just came out :)
[10:19] <bthomas> I think there is a capitalist conspiracy to bankrupt hard working middle class folk
[10:29] <Chipaca> <shocked pikachu/>
[10:33] <bthomas> Chipaca: juju storage in my model reports "No storage to display". Any idea if this could be a reason why a k8s persistentVolumeClaim is not being satisfied ?
[10:33] <Chipaca> bthomas: i'm afraid i don't know
[10:34] <bthomas> no problems. will give it a shot anyway.
[10:34] <Chipaca> bthomas: the only thing i know that might by even remotely connected is that if you specify a min-juju-version of 2.8 juju won't default to giving you persistent storage
[10:35] <bthomas> thanks. my juju version is indeed 2.8.1
[10:35] <Chipaca> bthomas: right but does your metadata.yaml say min-juju-version
[10:35] <bthomas> Chipaca: metadata.yaml does not mention min-juju-version
[10:36] <Chipaca> ah, then you should still have one
[10:36] <Chipaca> aiui at least
[10:36] <Chipaca> but that's the operator pod, dunno about the application pod
[10:37] <bthomas> I can't think of any other reason, so will try and see if allocating storage to app/model fixes the issue
[10:37]  * bthomas heads of to mine morsels of wisdom from juju doc mountain
[10:46] <axino> hello
[10:46] <axino> "charmcraft build" does't include my "lib" directory (which only has one subdirectory, and inside this subdir, a symlink). Is this expected ?
[10:47] <axino> if I add a empty file to lib/interface/, that file is included
[10:47] <Chipaca> axino: hello
[10:48] <Chipaca> axino: this is not expected, if you're running a new enough charmcraft
[10:48] <Chipaca> axino: what charmcraft are you running? (what's "charmcraft version")
[10:48] <axino> Chipaca: Version: 0.3.1+58.g0ccec67
[10:48] <axino> Chipaca: FYI I just filed https://github.com/canonical/charmcraft/issues/136 :)
[10:49] <axino> Chipaca: https://pastebin.canonical.com/p/c7SSCBjbXp/ is the "tree" for the lib directory
[10:49] <axino> the "a" file is in the zip, the symlink is not. Do zipfiles even support symlinks ?
[10:50] <Chipaca> axino: zipfiles do kinda support symlinks using a de-facto-standard extension to the spec
[10:50] <Chipaca> axino: we have not implemented it, so we flatten symlinks in charms for now (it's on the TODO)
[10:51] <axino> hmm
[10:52] <Chipaca> axino: i'm sure facundo will be all over that when he gets here :)
[10:52] <axino> I'm surprised no one has run into that
[10:52] <axino> I must be doing something wrong
[10:53] <Chipaca> axino: we've recently rewritten how we build the zip, so it's possible people depending on this behaviour aren't running edge yet
[10:53] <Chipaca> axino: so thank you for being our guinea pig :-)
[10:53] <axino> "for dirpath, dirnames, filenames in os.walk(buildpath_str, followlinks=True):"
[10:53] <axino> followlinks may be the issue
[10:56] <axino> Chipaca: Version: 0.3.1 fails in another way : charmcraft internal error! OSError: [Errno 40] Too many levels of symbolic links:
[10:56] <axino> '/home/ubuntu/charm-k8s-gunicorn/build/mod/interface-pgsql/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql
[10:56] <axino> /opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql/opslib/pgsql' (full execution logs in /home/ubuntu/snap/charmcraft/common/charmcraft-log-jo0o807z)
[10:56] <Chipaca> mmm, delicious
[10:56] <axino> mod/interface-pgsql/pgsql/opslib/pgsql is a symlink to ..
[10:57] <Chipaca> axino: if you build (using edge) with --verbose, it might shine some light on it
[10:58] <axino> I just filed a bug because there was no --verbose :)
[10:58] <axino> charmcraft (edge) 0.3.1+58.g0ccec67 from John Lenton (chipaca) refreshed
[10:58] <axino> charmcraft: error: unrecognized arguments: --verbose
[11:00] <Chipaca> axino: try charmcraft --verbose build
[11:01] <Chipaca> axino: there is a verbose, but argparse is weird
[11:01] <Chipaca> that's being fixed in #135
[11:01] <mup> PR #135: Operator Framework charm writing guide <Created by VariableDeclared> <Closed by niemeyer> <https://github.com/canonical/operator/pull/135>
[11:01] <Chipaca> charmcraft#135
[11:01] <mup> PR charmcraft#135: Support the global options also after the command is given <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/135>
[11:01] <axino> ah
[11:02] <axino> well OK
[11:02] <axino> doesn't really help as to why the file is missing
[11:03] <axino> https://pastebin.canonical.com/p/YZMYwRWyPr/
[11:03] <axino> gotta lunch :)
[11:16] <facubatista> ¡Muy buenos días a todos!
[11:20] <bthomas> morning facubatista
[11:20] <Chipaca> facubatista: heyy
[11:20] <facubatista> hola bthomas, Chipaca
[11:20] <Chipaca> facubatista: charmcraft#136 might be worth your attention
[11:21] <mup> Issue charmcraft#136: charmcraft build needs a --verbose option <Created by axinojolais> <https://github.com/canonical/charmcraft/issues/136>
[11:21] <Chipaca> wait no not taht one
[11:21] <Chipaca> facubatista: heh, i thought axino had filed a bug for their symlink woes
[11:22] <Chipaca> facubatista: let me summarise
[11:22] <Chipaca> facubatista: they have this: https://pastebin.canonical.com/p/c7SSCBjbXp/
[11:23] <Chipaca> facubatista: if they remove the 'a' file, the whole 'lib' is not included by "charmcraft build"
[11:23] <Chipaca> facubatista: (using edge)
[11:24] <facubatista> Chipaca, no lib and no interface are included?
[11:41] <facubatista> Chipaca, axino, it works here, https://paste.ubuntu.com/p/vXG3PYZP2G/ , let's try to find the difference with that
[11:41] <facubatista> (it looks I'm not replicating that ok)
[11:41] <facubatista> axino, can I get the build logs? thanks!
[11:45] <axino> facubatista: what's "unzip -l test.charm | grep lib" ?
[11:46] <facubatista>         0  2020-08-24 08:30   lib/interface/pgsql
[11:46] <facubatista> (my interface-pgsql is empty)
[11:47] <facubatista> Chipaca, I have an unplanned kids' school meeting, do you need me in the Postgresql meeting? I can be there if you do
[11:57] <Chipaca> facubatista: nah, go
[11:57] <facubatista> Chipaca, thanks
[11:57] <Chipaca> sorry for the delay replying, my shopping arrived
[12:00] <mup> Issue operator#371 closed: Use controller storage if no local storage exists <Created by stub42> <Closed by chipaca> <https://github.com/canonical/operator/issues/371>
[12:00] <mup> PR operator#374 closed: use controller-side storage automatically in some cases <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/374>
[12:02] <facubatista> Chipaca, no worries! the school meeting is virtual, I'm already there :)
[12:14] <axino> facubatista: interesting
[12:14] <axino> facubatista: my "build" dir has lib/interface/pgsql as a directory
[12:15] <facubatista> axino, ah
[12:15] <axino> but it's not in the zip
[12:15] <facubatista> axino, we know about that bug, I'm waiting for review to land the fix :) https://github.com/canonical/charmcraft/pull/131
[12:16] <mup> PR charmcraft#131: Respect the symlink even if it's a directory when building <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/131>
[12:16] <axino> OK
[12:16] <axino> facubatista: I'm just surprised that it works for you
[12:16] <facubatista> axino, for me it's a file
[12:17] <facubatista> not a dir
[12:17] <axino> ok
[12:18] <axino> facubatista: what's mod/interface-pgsql for you ?
[12:18] <axino> a file or a dir ?
[12:19] <Chipaca> bthomas: can i pester you for a review of #382? super easy one :)
[12:19] <mup> PR #382: not all operating systems let you rename over an existing file <Created by chipaca> <https://github.com/canonical/operator/pull/382>
[12:19] <facubatista> axino, a file
[12:19] <bthomas> Chipaca: will have a look now
[12:19] <mup> PR operator#381 closed: we should call harness.cleanup in unit tests now that we use resources there :-) <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/381>
[12:19] <axino> facubatista: ah well it's a dir for me
[12:19] <Chipaca> bthomas: thanks
[12:20] <facubatista> axino, right, that's the difference
[12:20] <axino> facubatista: also my .jujuignore has "*__pycache__*" and "*.py[cod]", yet files like venv/yaml/__pycache__/events.cpython-38.pyc are included in the zipfile
[12:21] <facubatista> axino, can I see your build logs?
[12:21] <axino> facubatista: https://pastebin.canonical.com/p/YZMYwRWyPr/ ?
[12:23] <facubatista> axino, what you specify in .jujuignore is not considered for the venv directory; that venv directory is a obscure thing that may change in the future (or not) and has all Python dependencies
[12:23] <facubatista> axino, we can not ignore stuff from there, we may break those dependencies
[12:24] <axino> facubatista: isn't __pycache__ always safely ignorable ?
[12:26] <Chipaca> i mean, we could call pip with --no-compile
[12:35] <bthomas> Chipaca: I do not quite understand why backup version_path to version_backup. Then write to version_path and run setup(). And then copy version_backup back to version_path.
[12:35] <Chipaca> bthomas: version.py in the repo gets the version by calling git
[12:35] <bthomas> Ah Ok. I see now.
[12:35] <Chipaca> bthomas: version.py in a packaged and released version gets the version from just setting a constant
[12:36] <Chipaca> :)
[12:36] <bthomas> got it.
[12:36] <bthomas> Although IMHO this needs a small comment :-)
[12:37] <bthomas> done
[12:38] <Chipaca> whee
[12:39] <Chipaca> I do have one question though
[12:39] <Chipaca> LUNCH?
[12:40]  * Chipaca searches for an answer
[12:40] <bthomas> just had and now back to k8s. Looks like microk8s ingress controller is crashing.
[12:40] <bthomas> thinking about mentioning it on microk8s channel
[12:41] <bthomas> Seems like it is crashing because port 80 is already in use
[12:48] <mup> PR operator#382 closed: not all operating systems let you rename over an existing file <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/382>
[12:55] <Chipaca> augh
[12:55] <Chipaca> of COURSE the default encoding on windows is not utf8
[12:59] <axino> <+Chipaca> facubatista: heh, i thought axino had filed a bug for their symlink woes
[12:59] <axino> should I ?
[13:00] <Chipaca> axino: i just misunderstood what bug you filed; you found several
[13:00] <Chipaca> axino: I think facubatista has a handle on the other issue now though; I'll defer to him
[13:01] <axino> I just "mv gunicorn.charm gunicorn.charm.zip ; zip -yru gunicorn.charm.zip lib ; mv gunicorn.charm.zip gunicorn.charm" for now
[13:03] <Chipaca> axino: is the moving needed?
[13:03] <Chipaca> (i know it won't tab complete)
[13:06]  * facubatista is back
[13:06] <axino> Chipaca: zip appears to ignore non-.zip file, and I didn't find a way to change this via cmdline option
[13:10] <Chipaca> facubatista: the change to universal newlines broke something :-( booo
[13:10] <Chipaca> facubatista: i did test, just not the right thing :)
[13:11] <facubatista> Chipaca, you're talking about the "ops in window" journey?
[13:11] <Chipaca> facubatista: 3.5 doesn't let you say what encoding to use to bytes->str, and defaults to the wrong thing
[13:11] <Chipaca> facubatista: yes :)
[13:11] <Chipaca> facubatista: just complaining, here
[13:12] <facubatista> :)
[13:18] <mup> PR operator#391 opened: turns out universal_newlines is the wrong answer, on 3.5 <Created by chipaca> <https://github.com/canonical/operator/pull/391>
[13:37] <Chipaca> i could use reviews of the above ^ plz (it's easy!)
[14:07] <justinclark> Taking a look, Chipaca
[14:40] <bthomas> Chipaca: I was wondering why the replace call is not replacing os.linesep. I mean why is it safe to assume linesep will not be "\r" for instance ?
[14:45] <Chipaca> bthomas: nobody's been that evil :-D
[14:46] <bthomas> old MacOS is :-)
[14:46] <Chipaca> nah, old macos was \n\r
[14:46] <bthomas> wait, I though ...
[14:46] <bthomas> but still \n\r will leak through then.
[14:47] <Chipaca> yep
[14:47] <Chipaca> bthomas: i might be wrong about old macos tho
[14:48] <Chipaca> python's linesep had it as \r it seems
[14:48] <bthomas> interesting
[14:48]  * bthomas loves WikiPedia https://en.wikipedia.org/wiki/Newline
[14:49] <Chipaca> bthomas: otoh the pythons we support only know of \n and \r\n
[14:49] <Chipaca> still, it's a good idea to use it
[14:50] <bthomas> no worries. i will leave that choice upto you. approving now.
[14:56] <Chipaca> bthomas: wikipedia agrees with you about linesep on old macs, and emacs' C-X RET F utf-8-mac agrees with that also
[14:56] <Chipaca> so i was completely wrong, and left wondering what was going on with Perl and newlines when I learned that factoid
[14:57] <Chipaca> unfortunately this means I will _never_ forget this :-/
[14:57]  * Chipaca wastes neurons on silly things
[14:57] <bthomas> Interesting Chipaca : have not used emacs to convert line endings in ages.
[14:58]  * bthomas thinks Chipaca will become a walking encyclopedia of arcane and inconcequential facts
[14:58] <bthomas> :-)
[14:59] <Chipaca> yeap, that's me
[15:00] <Chipaca> bthomas: going back a little bit, os.linesep is a str not a bytes, so i needed to do it differently than the trivial change, but i think it's better for it
[15:02] <bthomas> ah did not notice that
[15:09] <mup> PR operator#391 closed: turns out universal_newlines is the wrong answer, on 3.5 <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/391>
[15:14] <crodriguez> Is there an easy way to retrieve the kubernetes namespace name in a charm, with the framework?   I was trying to use the env var "JUJU_OPERATOR_NAMESPACE" but I hit this issue https://bugs.launchpad.net/juju/+bug/1892255/comments/5
[16:08] <facubatista> bthomas, justinclark, I'd appreciate a review of https://github.com/canonical/charmcraft/pull/131 , thanks!
[16:08] <mup> PR charmcraft#131: Respect the symlink even if it's a directory when building <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/131>
[16:28] <justinclark> facubatista, looks good to me
[16:52] <facubatista> justinclark, thanks!
[16:56] <crodriguez> I have an issue with a charm I recently coded with the operator framework. It is a subordinate charm and it should do the same operations on all units to which it is deployed. However, it looks like it install packages (https://git.launchpad.net/~camille.rodriguez/charm-iscsi-connector/tree/src/charm.py?h=initial#n74) only on the leader unit, even if I did not specify anywhere "is_leader"
[16:56] <bthomas> kubectl pv and kubectl pvc show me that status of all persistent volumes and persistent volume claims is "Bound" . Does this mean that the Warning message I see when I do kubectl describe pod prometheus-0 was only temporary . Anybody ?
[16:57] <crodriguez> I do not understand why it is doing so. Every other aspect of the charm is correctly installed on all units  (it is mostly configuring  config files)
[17:07] <justinclark> I'm still learning, so I may not be much help crodriguez.. But I do have a question - can you tell if the "on_install" hook fires at all for the subordinate charm?
[17:10] <crodriguez> justinclark, yeah I should check that.... maybe it's just because that install hook is by default ran only on leaders. I'll test it and let you know, thanks!
[17:10] <crodriguez> But I might file a bug .. it should be "installed" on all units
[18:31] <justinclark> Any luck crodriguez?
[18:53] <crodriguez_> I'm digging justinclark . A test on my local openstack was successful and it installed the packages on both leader/non-leader units. So I'm trying to figure out what happened different in the customer's environment
[18:53] <crodriguez_> it's probable that it's an issue with my charm code and not the framework
[19:07] <crodriguez_> hmm... Idk. In both environments, the install event is triggered, but in one, the apt.cache update and install does not happen
[19:37] <justinclark> Interesting. My initial guesses would be Python versions / apt.cache versions ¯\_(ツ)_/¯
[19:38] <justinclark> Sorry for not being much help here!
[20:38] <justinclark> I am trying to defer a "peer_joined" event until an database relation is available [1]. But in my test case, the deferred event isn't being reemitted when I add a new relation/unit [2]. My understanding is that a deferred event handler will be run when the very next event is triggered. Can anyone point me in the correct direction here?
[20:38] <justinclark> [1] https://github.com/justinmclark/grafana-charm-base/blob/20cc8461a746a880227829228699eb4a5b0da1a0/src/charm.py#L144
[20:38] <justinclark> [2] https://github.com/justinmclark/grafana-charm-base/blob/20cc8461a746a880227829228699eb4a5b0da1a0/test/unit/test_charm.py#L86