#smooth-operator 2020-08-24
<Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<bthomas> Morning Chipaca : Hope you had a good break
<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>
<Chipaca> bthomas: I did!
<Chipaca> I could've had another day's worth of it :-D
<bthomas> Yep. Never enough. :)
<Chipaca> dunno, another two days would've had me programming something
<Chipaca> one would've gotten me to finish putting up a bit of ikea furniture that's in my backlog
<Chipaca> bthomas: how was your weekend?
<bthomas> Chipaca: Cleaning the house (not so much fun), Cooking (more fun), doing math (most fun) :-)
<Chipaca> :) nice
<Chipaca> bthomas: if you're in the mood for little bit of code review, #381 could use that
<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>
<bthomas> Chipaca: will have a look now
<Chipaca> and #382 â¦
<mup> PR #382: not all operating systems let you rename over an existing file <Created by chipaca> <https://github.com/canonical/operator/pull/382>
<Chipaca> â¦ and #389
<mup> PR #389: minor docs fix <Created by justinmclark> <https://github.com/canonical/operator/pull/389>
<bthomas> Done.
<mup> PR operator#384 closed: make test_infra pass on windows <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/384>
<bthomas> Odd. Kubectl config set-context microk8s is not working this morning.
<bthomas> oops it is use-context
<bthomas> Awesome choice of two command names.
<Chipaca> you know more k stuff than i do
<Chipaca> what's use-context? (what even is a context)
<Chipaca> kubectl needs its version of https://git-man-page-generator.lokaltog.net/
<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.
<bthomas> I don't think I know more kube than you. Knowing some silly fact about the ginormous gargutan framework does not count.
<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?
<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.
<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>
<Chipaca> ok travis is already backed up
<Chipaca> time for a break
<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.
<bthomas> looks like I am in for some hardcore k8s debugging since that is the only way to debug charms on k8s.
<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>
<mup> PR operator#389 closed: minor docs fix <Created by justinmclark> <Merged by chipaca> <https://github.com/canonical/operator/pull/389>
<Chipaca> bthomas: if in need of break from hardcore k8s debugging, break glass^W^W click link: https://i.redd.it/qpdsiofjrsi51.jpg
<Chipaca> (allegedly taken over the weekend in Richmond Park here in London)
<bthomas> Chipaca: that is a very crisp image. I like photography too. Are you an avid photographer ?
<bthomas> my camera is a bit old though Nikon D90
<bthomas> I can see you have good composition skils -- keeping subject off center
<Chipaca> i am not an avid photographer
<Chipaca> i am an avid collecter of background images :-p
<bthomas> ha ha
<Chipaca> bthomas: that one in particular is by u/ageitgey via https://www.reddit.com/r/london/comments/if8luz/richmond_park_tonight/
<Chipaca> again, allegedly
<bthomas> That thread has a few other good ones too.
<Chipaca> ayup
<Chipaca> bthomas: the first time i knew i wanted a big 4k monitor was probably a year ago, due to a very similar image
<bthomas> Chipaca: you may want to wait a bit. Transparent OLED TVs just came out.
<Chipaca> it's still on my wishlist, because there's a list
<bthomas> Oh yeah. The wishlist. hmmm
 * bthomas goes to national-lottery.co.uk
<Chipaca> bthomas: there's always something that just came out :)
<bthomas> I think there is a capitalist conspiracy to bankrupt hard working middle class folk
<Chipaca> <shocked pikachu/>
<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 ?
<Chipaca> bthomas: i'm afraid i don't know
<bthomas> no problems. will give it a shot anyway.
<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
<bthomas> thanks. my juju version is indeed 2.8.1
<Chipaca> bthomas: right but does your metadata.yaml say min-juju-version
<bthomas> Chipaca: metadata.yaml does not mention min-juju-version
<Chipaca> ah, then you should still have one
<Chipaca> aiui at least
<Chipaca> but that's the operator pod, dunno about the application pod
<bthomas> I can't think of any other reason, so will try and see if allocating storage to app/model fixes the issue
 * bthomas heads of to mine morsels of wisdom from juju doc mountain
<axino> hello
<axino> "charmcraft build" does't include my "lib" directory (which only has one subdirectory, and inside this subdir, a symlink). Is this expected ?
<axino> if I add a empty file to lib/interface/, that file is included
<Chipaca> axino: hello
<Chipaca> axino: this is not expected, if you're running a new enough charmcraft
<Chipaca> axino: what charmcraft are you running? (what's "charmcraft version")
<axino> Chipaca: Version: 0.3.1+58.g0ccec67
<axino> Chipaca: FYI I just filed https://github.com/canonical/charmcraft/issues/136 :)
<axino> Chipaca: https://pastebin.canonical.com/p/c7SSCBjbXp/ is the "tree" for the lib directory
<axino> the "a" file is in the zip, the symlink is not. Do zipfiles even support symlinks ?
<Chipaca> axino: zipfiles do kinda support symlinks using a de-facto-standard extension to the spec
<Chipaca> axino: we have not implemented it, so we flatten symlinks in charms for now (it's on the TODO)
<axino> hmm
<Chipaca> axino: i'm sure facundo will be all over that when he gets here :)
<axino> I'm surprised no one has run into that
<axino> I must be doing something wrong
<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
<Chipaca> axino: so thank you for being our guinea pig :-)
<axino> "for dirpath, dirnames, filenames in os.walk(buildpath_str, followlinks=True):"
<axino> followlinks may be the issue
<axino> Chipaca: Version: 0.3.1 fails in another way : charmcraft internal error! OSError: [Errno 40] Too many levels of symbolic links:
<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
<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)
<Chipaca> mmm, delicious
<axino> mod/interface-pgsql/pgsql/opslib/pgsql is a symlink to ..
<Chipaca> axino: if you build (using edge) with --verbose, it might shine some light on it
<axino> I just filed a bug because there was no --verbose :)
<axino> charmcraft (edge) 0.3.1+58.g0ccec67 from John Lenton (chipaca) refreshed
<axino> charmcraft: error: unrecognized arguments: --verbose
<Chipaca> axino: try charmcraft --verbose build
<Chipaca> axino: there is a verbose, but argparse is weird
<Chipaca> that's being fixed in #135
<mup> PR #135: Operator Framework charm writing guide <Created by VariableDeclared> <Closed by niemeyer> <https://github.com/canonical/operator/pull/135>
<Chipaca> charmcraft#135
<mup> PR charmcraft#135: Support the global options also after the command is given <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/135>
<axino> ah
<axino> well OK
<axino> doesn't really help as to why the file is missing
<axino> https://pastebin.canonical.com/p/YZMYwRWyPr/
<axino> gotta lunch :)
<facubatista> Â¡Muy buenos dÃ­as a todos!
<bthomas> morning facubatista
<Chipaca> facubatista: heyy
<facubatista> hola bthomas, Chipaca
<Chipaca> facubatista: charmcraft#136 might be worth your attention
<mup> Issue charmcraft#136: charmcraft build needs a --verbose option <Created by axinojolais> <https://github.com/canonical/charmcraft/issues/136>
<Chipaca> wait no not taht one
<Chipaca> facubatista: heh, i thought axino had filed a bug for their symlink woes
<Chipaca> facubatista: let me summarise
<Chipaca> facubatista: they have this: https://pastebin.canonical.com/p/c7SSCBjbXp/
<Chipaca> facubatista: if they remove the 'a' file, the whole 'lib' is not included by "charmcraft build"
<Chipaca> facubatista: (using edge)
<facubatista> Chipaca, no lib and no interface are included?
<facubatista> Chipaca, axino, it works here, https://paste.ubuntu.com/p/vXG3PYZP2G/ , let's try to find the difference with that
<facubatista> (it looks I'm not replicating that ok)
<facubatista> axino, can I get the build logs? thanks!
<axino> facubatista: what's "unzip -l test.charm | grep lib" ?
<facubatista>         0  2020-08-24 08:30   lib/interface/pgsql
<facubatista> (my interface-pgsql is empty)
<facubatista> Chipaca, I have an unplanned kids' school meeting, do you need me in the Postgresql meeting? I can be there if you do
<Chipaca> facubatista: nah, go
<facubatista> Chipaca, thanks
<Chipaca> sorry for the delay replying, my shopping arrived
<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>
<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>
<facubatista> Chipaca, no worries! the school meeting is virtual, I'm already there :)
<axino> facubatista: interesting
<axino> facubatista: my "build" dir has lib/interface/pgsql as a directory
<facubatista> axino, ah
<axino> but it's not in the zip
<facubatista> axino, we know about that bug, I'm waiting for review to land the fix :) https://github.com/canonical/charmcraft/pull/131
<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>
<axino> OK
<axino> facubatista: I'm just surprised that it works for you
<facubatista> axino, for me it's a file
<facubatista> not a dir
<axino> ok
<axino> facubatista: what's mod/interface-pgsql for you ?
<axino> a file or a dir ?
<Chipaca> bthomas: can i pester you for a review of #382? super easy one :)
<mup> PR #382: not all operating systems let you rename over an existing file <Created by chipaca> <https://github.com/canonical/operator/pull/382>
<facubatista> axino, a file
<bthomas> Chipaca: will have a look now
<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>
<axino> facubatista: ah well it's a dir for me
<Chipaca> bthomas: thanks
<facubatista> axino, right, that's the difference
<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
<facubatista> axino, can I see your build logs?
<axino> facubatista: https://pastebin.canonical.com/p/YZMYwRWyPr/ ?
<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
<facubatista> axino, we can not ignore stuff from there, we may break those dependencies
<axino> facubatista: isn't __pycache__ always safely ignorable ?
<Chipaca> i mean, we could call pip with --no-compile
<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.
<Chipaca> bthomas: version.py in the repo gets the version by calling git
<bthomas> Ah Ok. I see now.
<Chipaca> bthomas: version.py in a packaged and released version gets the version from just setting a constant
<Chipaca> :)
<bthomas> got it.
<bthomas> Although IMHO this needs a small comment :-)
<bthomas> done
<Chipaca> whee
<Chipaca> I do have one question though
<Chipaca> LUNCH?
 * Chipaca searches for an answer
<bthomas> just had and now back to k8s. Looks like microk8s ingress controller is crashing.
<bthomas> thinking about mentioning it on microk8s channel
<bthomas> Seems like it is crashing because port 80 is already in use
<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>
<Chipaca> augh
<Chipaca> of COURSE the default encoding on windows is not utf8
<axino> <+Chipaca> facubatista: heh, i thought axino had filed a bug for their symlink woes
<axino> should I ?
<Chipaca> axino: i just misunderstood what bug you filed; you found several
<Chipaca> axino: I think facubatista has a handle on the other issue now though; I'll defer to him
<axino> I just "mv gunicorn.charm gunicorn.charm.zip ; zip -yru gunicorn.charm.zip lib ; mv gunicorn.charm.zip gunicorn.charm" for now
<Chipaca> axino: is the moving needed?
<Chipaca> (i know it won't tab complete)
 * facubatista is back
<axino> Chipaca: zip appears to ignore non-.zip file, and I didn't find a way to change this via cmdline option
<Chipaca> facubatista: the change to universal newlines broke something :-( booo
<Chipaca> facubatista: i did test, just not the right thing :)
<facubatista> Chipaca, you're talking about the "ops in window" journey?
<Chipaca> facubatista: 3.5 doesn't let you say what encoding to use to bytes->str, and defaults to the wrong thing
<Chipaca> facubatista: yes :)
<Chipaca> facubatista: just complaining, here
<facubatista> :)
<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>
<Chipaca> i could use reviews of the above ^ plz (it's easy!)
<justinclark> Taking a look, Chipaca
<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 ?
<Chipaca> bthomas: nobody's been that evil :-D
<bthomas> old MacOS is :-)
<Chipaca> nah, old macos was \n\r
<bthomas> wait, I though ...
<bthomas> but still \n\r will leak through then.
<Chipaca> yep
<Chipaca> bthomas: i might be wrong about old macos tho
<Chipaca> python's linesep had it as \r it seems
<bthomas> interesting
 * bthomas loves WikiPedia https://en.wikipedia.org/wiki/Newline
<Chipaca> bthomas: otoh the pythons we support only know of \n and \r\n
<Chipaca> still, it's a good idea to use it
<bthomas> no worries. i will leave that choice upto you. approving now.
<Chipaca> bthomas: wikipedia agrees with you about linesep on old macs, and emacs' C-X RET F utf-8-mac agrees with that also
<Chipaca> so i was completely wrong, and left wondering what was going on with Perl and newlines when I learned that factoid
<Chipaca> unfortunately this means I will _never_ forget this :-/
 * Chipaca wastes neurons on silly things
<bthomas> Interesting Chipaca : have not used emacs to convert line endings in ages.
 * bthomas thinks Chipaca will become a walking encyclopedia of arcane and inconcequential facts
<bthomas> :-)
<Chipaca> yeap, that's me
<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
<bthomas> ah did not notice that
<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>
<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
<facubatista> bthomas, justinclark, I'd appreciate a review of https://github.com/canonical/charmcraft/pull/131 , thanks!
<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>
<justinclark> facubatista, looks good to me
<facubatista> justinclark, thanks!
<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"
<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 ?
<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)
<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?
<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!
<crodriguez> But I might file a bug .. it should be "installed" on all units
<justinclark> Any luck crodriguez?
<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
<crodriguez_> it's probable that it's an issue with my charm code and not the framework
<crodriguez_> hmm... Idk. In both environments, the install event is triggered, but in one, the apt.cache update and install does not happen
<justinclark> Interesting. My initial guesses would be Python versions / apt.cache versions Â¯\_(ã)_/Â¯
<justinclark> Sorry for not being much help here!
<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?
<justinclark> [1] https://github.com/justinmclark/grafana-charm-base/blob/20cc8461a746a880227829228699eb4a5b0da1a0/src/charm.py#L144
<justinclark> [2] https://github.com/justinmclark/grafana-charm-base/blob/20cc8461a746a880227829228699eb4a5b0da1a0/test/unit/test_charm.py#L86
#smooth-operator 2020-08-25
<justinclark> Update: I haven't been able to confirm, but I think my issue is that event.defer() might put the deferred event at the front of the event trigger queue - my code would only work if the deferred event got put at the back of the event queue. I'll find another way to do what I want to do.
 * Chipaca takes a break
<bthomas> Chipaca: I am thinking it would be useful to allow opslib k8s to be used outside charm context. For instance it would be use to me now to run the get_pod_status() method from a python console passing in my juju model, app and unit. What do you think ?
<Chipaca> bthomas: no objections
<bthomas> What I am worried about is in the future if opslib picks up functionality that can only be run in a charm context (as is the case for operator framework) this will be problematic
<bthomas> As far as I can tell all that is necessary is to allow inject of service account credentials which I can easly do
<Chipaca> bthomas: which things in k8s depend on charm context today?
<bthomas> Chipaca: I do not see anything that depends on charm context. However it does require service account CA and TOKEN.
<bthomas> A developer/client can always creat their own service account, if the have admin access to the cluster. I would think they should be able to inject such service account credentials into the APIServer class in k8s to then use it to query the juju cluster
<Chipaca> bthomas: wrt 'require service account ca and token', it's picking those up from disk, from their 'canonical' locations, isn't it?
<Chipaca> ie not charm-related
<Chipaca> or is that something juju does for charms?
<bthomas> Chipaca: there is no /var/run/secrets in my host (ubuntu laptop) system. So I would expect that the service account details are coming from Juju or microk8s. Will dig a bit.
<bthomas> kubectl -n lma exec prometheus-operator-0 -- ls /var/run/secrets
<bthomas> shows that the service account details are available in the prometheus charm pods
<Chipaca> my dog, fetching individual treats and scritches for each opcode, would still run test_main.py faster than windows does
<bthomas> :)
<facubatista> Â¡Muy buenos dÃ­as a todos!
<Chipaca> that was a short day
<bthomas> Good Morning
<bthomas> Is there any method call in the Operator Framework that a charm needs to make in order to ensure that the juju init container runs to completion ?
<Chipaca> bthomas: what do you mean by the 'juju init container'?
<bthomas> Chipaca: when you deploy a charm juju creates a container called juju-pod-init. This is a kubernetes "init container". As far as I understand this must run to completion before other pods will start.
<bthomas> opps i meant other containers will start
 * bthomas breaks for lunch
<facubatista> Chipaca, what we discussed: https://github.com/canonical/charmcraft/pull/137
<mup> PR charmcraft#137: Fixed global options behaviour <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/137>
<facubatista> bthomas, reviews appreciated ^ thanks
<bthomas> facubatista: looking now
<bthomas> facubatista: args.verbose_global and args.quite_global seem to be exactly opposite things. So I do not understand why have both and use both.
<facubatista> bthomas, the user needs the option to use one or the other
<justinclark> Good morning !
<facubatista> hello justinclark
<bthomas> Morning
<bthomas> Inside my operator charm pod the pip3 installed in /usr/local/bin/pip3 gives the error "AttributeError: module 'platform' has no attribute 'linux_distribution'" . Oddly enough even though dpkg -L python3-pip shows it has installed a pip3 at /usr/bin/pip3 when trying to run /usr/bin/pip3 I get the error "No such file or directory".
 * bthomas is perplexed
<bthomas> Any idea why there are two pip3's in a charm pod ? The one in /usr/local/bin/pip3 seems to be outdated.
<Chipaca> bthomas: what put /usr/local/bin/pip3 there, and why are you even running pip3 on a charm pod
<bthomas> Chipaca: I do not know what put /usr/local/bin/pip3 there. The pod is called prometheus-opeartor-0. I am install python modules to help in remote debugging of operator hooks.
<Chipaca> bthomas: so does /usr/bin/pip3 actually exist? (or is it a dangling symlink)
<bthomas> Chipaca: /usr/bin/pip3 does not exist
<bthomas> Chipaca: Very Very odd that dpkg -l python3-pip reports that the deb is actually installed
<bthomas> I can not find any other way to debug this charm. Without being able to get pip3 working I have to thow up my hands in despair.
<Chipaca> bthomas: why not 'apt instlal --reinstall python3-pip'?
<Chipaca> or the same without typos
<bthomas> Chipaca: result = "Reinstallation of python3-pip is not possible, it cannot be downloaded.". I am going to retry after apt update
 * bthomas does cartwheels
<bthomas> updated followed by install worked
<bthomas> Chipaca: still aren't there issues here that need to be reported or a bug filed ? If so would you like me to do it and where ?
<Chipaca> bthomas: are these things in the operator pod, or the application pod?
<bthomas> Chipaca: operator pod
<Chipaca> bthomas: does sound like a bug yes
<bthomas> Chipaca: if it is a bug report for our team I can create a bug report describing what I said above. Would you like me to do it ? If it is for another team I would rather you do it knowing more about the issue, but will be happy to help.
<Chipaca> bthomas: it isn't for us, it'd be for juju probably
<bthomas> Adding a pdb set_trace() call in a hook does not do anything. I would expect that it should have halted the charm hook execution at that point. I can actually see the hook being called by watching juju status .
<bthomas> ð
<bthomas> Hmm. I tried adding my python modules to requirements.txt and find they are not installed in the operator pod. I guess this means they are only installed in the application pod.
<Chipaca> bthomas: how are you building the charm?
<bthomas> Chipaca: charmcraft build
<Chipaca> bthomas: and where are you looking for those python modules?
<bthomas> Chipaca: in prometheus-operator-0 where the charm.py file is located.
<Chipaca> bthomas: and where in there?
<bthomas> Chipaca: /var/lib/juju/agents/unit-prometheus-0/charm/src/charm.py
<Chipaca> bthomas: and where in there are you looking for the libs?
<bthomas> Chipaca: by launching python3 after kubectl exec -it -- /bin/bash
<Chipaca> bthomas: try Â« PYTHONPATH=/var/lib/juju/agents/unit-prometheus-0/charm/venv python Â»
<Chipaca> or rather python3
<Chipaca> bthomas: Â« PYTHONPATH=/var/lib/juju/agents/unit-prometheus-0/charm/venv python3 Â»
<bthomas> thanks will do
 * Chipaca gets tea
<mup> Issue operator#392 opened: Testing harness does not re-emit deferred event <Created by justinmclark> <https://github.com/canonical/operator/issues/392>
<justinclark> Here's the issue I mentioned during stand up today ^^
<Chipaca> justinclark: thank you
<Chipaca> 39 failed, 321 passed in 375.80s (0:06:15)
<Chipaca> *SIX MINUTES*
<Chipaca> grmbl
<Chipaca> but also, only 39 failed :-D
<bthomas> Chipaca: Can one expect k8s.get_pod_status() to return an empty dictionary if it is given valid model, app, and unit ?
<Chipaca> bthomas: if everything is valid, it should not return an empty dict no
<bthomas> Chipaca: Ok thinks. I am seeing an empty dictionary using pdb. But let us not get alarmed right now. I will try and dig a bit more for the rest of the day (although I really could do with a break for today :-) )
 * Chipaca â 34 failed, 326 passed
 * bthomas Chipaca exercises windows muscle ðª
<moon127> facubatista: thanks for the initial comments on https://code.launchpad.net/~moon127/charm-k8s-unifi-poller/+git/charm-k8s-unifi-poller/+merge/389643 - I added a response on the required settings code change, mainly as I'd tried it before and found juju deploying for real in microk8s behaved differently.  I could use some feedback on that.
<bthomas> ð
<facubatista> moon127, let me see...
<facubatista> moon127, ah, oh, mmm... it looks like options are *always* there, but by default in ""? So probably it's a misname to search for "missing" values, better if we call them "emtpy"?
<facubatista> moon127, are we sure that "" is never a valid value?
<moon127> never valid value for my use case indeed
<moon127> thanks for confirming I am not going mad!
<moon127> you are right though if I don't explicitly declare the config option as at least "" in the test harness it does raise a KeyError... but I guess internally for real deployment as you say juju always has the option there.
<Chipaca> while we can confirm that this particular instance is not evidence of you going mad, we do not mean to imply the more general statement
<moon127> ha yeah true dat
<Chipaca> down to 28 failures
<Chipaca> and off for evening run + evening meal + evening evening
 * Chipaca will bbl for more windows tests
<facubatista> moon127, the tests should reflect reality, so I'm ok with your "not config['foo']", but let's just rename missing to empty, so when reading the code that's more clear; extra points for a comment
<facubatista> Chipaca, and this is the other PR that I want for before release: https://github.com/canonical/charmcraft/pull/140
<mup> PR charmcraft#140: Always log the charmcraft version when indicated <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/140>
<facubatista> bthomas, justinclark, review appreciated ^ (thanks!)
<Chipaca> facubatista: but does it run on windows
 * Chipaca sets python.exe on fire and runs away
<facubatista> Chipaca, of course
<bthomas> facubatista: I had already reviewed and approved "Fixed global options behaviour". This looks like the same pull request with another commit "Always log the charmcraft version when indicated." I did a quick review of that. +1
<facubatista> yes, it depends on the other one
 * facubatista eods
<Chipaca> 360 tests passed, 8 skipped (4 of those still need work)
 * Chipaca EODs
<drewn3ss> Is there a reason relation data must be a string in operator?  https://github.com/canonical/operator/blob/master/ops/model.py#L687
<drewn3ss> I'm seeing historical code in reactive that works both with dict structures and strings.
<drewn3ss> perhaps the code we used to use was providing the serialization on the backend and operator wants it done by the operator?  I'm seeing interfaces that prefer the deserialized data.
<drewn3ss> (though handle both, thankfully)
<drewn3ss> https://git.launchpad.net/charm-grafana/tree/src/reactive/grafana.py#n1120
#smooth-operator 2020-08-26
<stub> reactive encoded data to json by default, and gave you access to the raw data if you needed. operator reverted to the basic Juju behaviour of only allowing strings.
<stub> (which I think originates from insisting that all interaction comes through a CLI, rather than say feeding JSON or YAML to a tool, because we were still trying to write charms using bash)
<axino> hello
<axino> should I be able to easily unittest leader-get calls with the current version of the ops framework ?
<axino> I can see relation-get/relation-set and is-leader, but not leader-get
<bthomas> ðð¸ð¸ð­ ðð¸ð»ð·ð²ð·ð°
<Chipaca> good morning peeps!
<bthomas> Morning Chipaca : FYI I was wrong k8s is working correctly. I made the mistake of using pod name "prometheus-0" instead of "prometheus/0". I used the former because that is what one sees when one does get pods.
<Chipaca> bthomas: fresh eyes \o/
<bthomas> Yep. Mornings are best for both coding and math.
<bthomas> Also now that I can probe the code using pdb. I realize that the prometheus application containers are stuck in ContainerNotReady status which is set by Kubernetes. My current best guess is that this is because they are failing the kubernetes liveness and readyness probes. I have not yet figured out how to confirm this since the application pod is not yet accessible. I am thinking of just deleting the probes and see what happens.
<Chipaca> more good news: https://arstechnica.com/science/2020/08/black-paint-on-wind-turbines-helps-prevent-bird-massacres/
<bthomas> indeed
<bthomas> next they need to figure out how to prevent them from being fried by flying into the part of solar beams in solar power plants
<Chipaca> bthomas: or team up with kfc
<axino> hello again
<bthomas> rol
<Chipaca> axino: ð
<axino> I'm trying to mock self.model.unit.is_leader() calls, but not succeeding so far. Would anyone have tips ? I don't want to use harness.set_leader() because it triggers a bunch of other code
<axino> which is completely unrelated to the function I want to test
<Chipaca> axino: what code does it trigger?
<Chipaca> axino: are you trying to test what happens when something becomes the leader in the middle of something?
<axino> Chipaca: nope
<Chipaca> axino: or are you trying to test what happens when something is the leader already
<axino> ^ this
<Chipaca> axino: then harness.set_leader before harness.begin should not trigger anything
<axino> I see
<axino> hmm
<axino> except we initialize the harness in setUp() currently
<Chipaca> axino: including harness.begin?
<Chipaca> hmm
<axino> indeed
<axino> is there an harness.stop equivalent ? :)
<axino> I see we call harness.cleanup() in tearDown()
<Chipaca> axino: you could harness.disable_hooks()
<Chipaca> axino: that'll stop leader_elected from being emitted
<axino> ok
<axino> Chipaca: that works indeed !
<axino> thank you
<axino> Chipaca: for context this is to test _on_database_relation_joined() as coded in https://github.com/canonical/ops-lib-pgsql
<axino> I'm still curious, for my personal knowledge, how I would mock self.model.unit.is_leader() calls btw :)
<bthomas> Information returned by kubernetes says that the juju-pod-init container has "incomplete status" and the prometheus and prometheus-nginx containers have "unready status". This is after disabling any liveness and readyness probes in the pod spec. All these containers are in the application pod of the charm.
<Chipaca> bthomas: if you take a step back, can you get k8s to do the thing you want it to do without juju?
<Chipaca> bthomas: juju's job is to automate things, but you need to be able to do those things to automate them :)
<moon127> Chipaca: I've pushed the changes we discussed on the call, https://code.launchpad.net/~moon127/charm-k8s-unifi-poller/+git/charm-k8s-unifi-poller/+merge/389643 is ready to be re-reviewed.
<Chipaca> moon127: ð
<bthomas> Chipaca: I think I shall try and learn how to deploy prometheus using just k8s. As I understand this is what you seem to be suggesting. Which sounds like a good idea to me. Thanks.
<Chipaca> axino: what's your github @?
<mthaddon> Chipaca: https://github.com/axinojolais
<Chipaca> mthaddon: thanks
<Chipaca> axino: https://github.com/canonical/operator/pull/393 :-)
<mup> PR #393: adds Harness.hooks_disabled, a context manager <Created by chipaca> <https://github.com/canonical/operator/pull/393>
<mup> PR operator#393 opened: adds Harness.hooks_disabled, a context manager <Created by chipaca> <https://github.com/canonical/operator/pull/393>
<Chipaca> d'oh and the docstring is wrong
 * Chipaca fixes
<Chipaca> facubatista, jam, this is the current state of the fixes for the tests on windows, so you get an idea of the scope of it: https://github.com/canonical/operator/compare/master...chipaca:more-win-fixes
<facubatista> Â¡Muy buenos dÃ­as a todos!
<Chipaca> there's one more thing to do, that i need to dig into, and then i need to clean it up and make it more reasonable and split it into digestible changes
<Chipaca> but those changes can result in passing unit tests on windows
<Chipaca> (granted as i say there is 1 more thing to do, and that one is skipped currently)
<Chipaca> but that's what i got to last night (or was it this morning) (it was a long hack sesh)
<Chipaca> facubatista: buen dÃ­a cabeza
 * Chipaca speaking all proper-like today
 * Chipaca needs more coffee
<Chipaca> wrt windows again, i say "can result" because it makes some assumptions about windows
<Chipaca> like, you have python and git-for-windows (inlcuding git-bash) installed
<Chipaca> and it assumes things about how juju calls charms on windows, that need verifying
<Chipaca> but seem sensible to me :)
<Chipaca> anyway. coffee! and then to meet with mthaddon
 * Chipaca looks at the time
<Chipaca> or maybe the other way around
<facubatista> Chipaca, one thing I would love to NOT see in the code are "if is_window" structures, we should hide compatibility code in a layer... for tests we'll sure have different ones in several cases, probably we could handle that with decorators, or something
<Chipaca> facubatista: yeah i'm hoping to refactor the is_windows checks into a couple of higher level functions
<Chipaca> facubatista: e.g. i can hide most of it by just wrapping subprocess.run
<facubatista> wonderful
<facubatista> Chipaca, remember your https://github.com/canonical/charmcraft/pull/116
<Chipaca> facubatista: and the _exe_path wrapper already there
<mup> PR charmcraft#116: include install info in README <Created by chipaca> <https://github.com/canonical/charmcraft/pull/116>
<facubatista> Chipaca, and please give a review in https://github.com/canonical/charmcraft/pull/137
<mup> PR charmcraft#137: Fixed global options behaviour <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/137>
 * Chipaca gets out his red byro
<axino> Chipaca: thanks that looks useful
<Chipaca> crodriguez_: WRT #1892255, do you still need a workaround for older jujus, or are you happy to work with 2.8.2?
<jam> morning all
<Chipaca> jam: ðâ
<Chipaca> jam: welcome to the other side :-D
<crodriguez_> morning!
<jam> Chipaca: indeed
<crodriguez_> let me check which bug that is
<jam> Chipaca: 2.8.2 isn't officially out yet, AIUI
<Chipaca> jam: correct, it's in candidate
<facubatista> hola jam, welcome back!
<jam> hi facubatista
<crodriguez_> oh the one with the env vars. Yeah, I'm using this in a new charm, so I could work with 2.8.2.
<drewn3ss> stub: Thank you for your response.  As I started thinking about it, I also came to the conclusion that ultimately it's calling the relation-set tool which will require strings.
<jam> Chipaca: this is the code that Juju uses for charm hook extensions: https://github.com/juju/juju/blob/develop/worker/uniter/runner/args.go
<jam> it supports .ps1, .cmd, .bat and .exe
<bthomas> Chipaca: I have a prometheus deployment running on microk8s accessible from localhost:8080
<bthomas> Now still need to figure outh getting this working with juju
<bthomas> and charms
<facubatista> mthaddon, Chipaca, gunicorn meeting?
<Chipaca> facubatista: 1'
<Chipaca> jam: would it be reasonable to add .py with a special handler for it similar to .ps1 ?
<mthaddon> facubatista: will be there in a few mins, just finishing up another call - axino are you on that one already?
<axino> mthaddon: I am
<Chipaca> *twice* :-p
<mthaddon> ack, feel free to just go ahead without me
<jam> Chipaca: .py sounds reasonable, but why wouldn't we do dispatch.ps1 /dispatch.bat that can figure the rest out. Its already a dispatch.sh
<jam> for Linux
<jam> (my concern is around things like "python isn't default installed on Windows, so you still have to get it there"
<Chipaca> jam: i guess charmcraft can drop a .bat in there just fine
 * facubatista -> live
<facubatista> err, lunch :p
<mthaddon> what am I missing here? https://pastebin.ubuntu.com/p/PNvtcKSnST/ I don't understand why I can import GunicornK8sCharm from "charm" but when I try to mock it I get an import failure :/
<narindergupta> @here I am looking for running a command line tool in k8s container deployed through framework. I can confirm that I have python in the image but not python3 do we have any examples where I can run the command through python in actions?
<bthomas> narindergupta: you can use kubectl exec to run a command in any accessible container. So in principle you can use python subprocess to excecute such a command and collect its output. This may not be the only way to do or the best way to do, just what comes to my mind immediately.
<narindergupta> bthomas, you mean use Kubectl using python? That won't be as efficient to use as charm action I guess?
<bthomas> narindergupta: I was not thinking of charm action. It was if you just wanted to run a command in a container.
<narindergupta> bthomas, but I thinking of creating actions for operations in case of Cassandra and run nodetool command to maintain and operate the cluster so that's what look for operations through action.
<bthomas> narindergupta: why are "os" or "subprocess" modules not suffecient for your purpose ?
<facubatista> mthaddon, can you show the import failure you're getting? thanks
<drewn3ss> narindergupta: would agree, subprocess.check_call or subprocess.check_output to nodetool within your on_action method should be pretty straight forward.
<narindergupta> drewn3ss, bthomas yeah that's what I am trying but wanted to make sure there is no wrapper in framework
<drewn3ss> no, best you might find is charmhelpers.core.host
<drewn3ss> er, charmhelpers.cli
<drewn3ss> narindergupta: https://charm-helpers.readthedocs.io/en/latest/api/charmhelpers.cli.html#charmhelpers.cli.CommandLine.run
<drewn3ss> you could then add charmhelpers to your requires and import and use that, if it suits your needs.  however, charmhelpers is heavy for subprocess only ;-)
<drewn3ss> *requirements.txt
<narindergupta> drewn3ss, this is operator framework so I doubt this will work though
<drewn3ss> you can certainly use charmhelpers in operator charms.
<drewn3ss> but simpler is better
<Chipaca> mthaddon: 'mock' is weird, you need to have the referred object in scope exactly as you pass it in
<Chipaca> mthaddon: that first stringy argument is the 'target' of patch(), and the docs say:
<Chipaca> target should be a string in the form 'package.module.ClassName'. The target is imported and the specified object replaced with the new object, so the target must be importable from the environment you are calling patch() from. The target is imported when the decorated function is executed, not at decoration time.
<Chipaca> mthaddon: so AIUI (without running the code, and i'm not super experienced with mock so i wouldn't be surprised if i got it a bit wrong), it won't work if you have something else called 'charm' in scope at patching time
<Chipaca> tomorrow i could actually try the code
<Chipaca> today it's already beer o'clock here so no code is happening
<Chipaca> (it's 0% beer but rules are rules)
<crodriguez> Chipaca : RE https://bugs.launchpad.net/juju/+bug/1892255 , 2.8.2 does not contain a fix that works for me, I still see the same issue
<facubatista> oh, no chipaca
<mup> Issue operator#394 opened: Create basic documentation <Created by facundobatista> <https://github.com/canonical/operator/issues/394>
<narindergupta> It seems operator framework is looking for python3. Can we use just python with operator framework rather than python3?
<narindergupta> While running the action
<drewn3ss> why are you looking to run python external to the charm?  are you trying to call "python nodetool"?
<narindergupta> I am using juju run juju run-action cassandra/0 status --wait which internally call os.popen("nodetool status")
<narindergupta> Give me error /usr/bin/env: âpython3â: No such file or directory
<narindergupta> I think juju internally runs the action using python call
<narindergupta> Which is python3 in this case so unless containers have python3 I can not run any command. I can confirm my container has python
<drewn3ss> is nodetool the one stating #!/usr/bin/env python3?
<narindergupta> drewn3ss, no nodetool works fine using kubectl exec
<drewn3ss> narindergupta: can you share your code where the actions are configured?
<narindergupta> drewn3ss, ok let me check in my code in github
<narindergupta> Here it is https://paste.ubuntu.com/p/kJhtbVjBKj/
<narindergupta> It is charm.yaml
<narindergupta> This is action https://paste.ubuntu.com/p/ttPYqVKSCD/
<narindergupta> microk8s.kubectl exec -n cassandramodel -it cassandra-0 -- nodetool status
<narindergupta> Datacenter: datacenter1
<narindergupta> =======================
<narindergupta> Status=Up/Down
<narindergupta> |/ State=Normal/Leaving/Joining/Moving
<narindergupta> --  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
<narindergupta> UN  10.1.17.50  554.96 KiB  256     ?                 29057614-e28a-4331-a236-efff00a01312  rack1
<narindergupta> UN  10.1.17.49  394.43 KiB  256     ?                 6b16060c-5240-4419-a069-e2203276400a  rack1
<narindergupta> UN  10.1.17.48  417.78 KiB  256     ?                 76fdf154-7c06-4169-a01a-fbf22a42c9e6  rack1
<narindergupta> Without juju
<drewn3ss> are you making symlinks directly to charm.py?
<drewn3ss> or are you running through the dispatch script
<drewn3ss> because your code shouldn't need #!/usr/bin/env python3 at the top whatsoever
<drewn3ss> you just need to implement a CharmBase object in your module that reacts to on.status_action, and the dispatch should take care of executing python for you.
<narindergupta> No I am using charmcraft build and run charm from there
<drewn3ss> if you make symlinks like the old charms, you're working around the framework's dispatcher
<narindergupta> drewn3ss, this must be from charmcraft build
<drewn3ss> oh, nvm, I do have the shebang on my charm.py too.
<drewn3ss> and the dispatcher does use that shebang
<drewn3ss> my bad
<drewn3ss> so, do your other hooks work?
<narindergupta> drewn3ss, yes like update status
<narindergupta> Because those hooks might be running on operator
<narindergupta> config_change works
<drewn3ss> so, gonna need to see a find -ls of your build dir
<narindergupta> Find what?
<drewn3ss> "find ./build -ls" after you charmcraft build
<narindergupta> Oh ok
<narindergupta> https://pastebin.ubuntu.com/p/j6vxmwJ4W3/
<drewn3ss> running a recent juju model, I assume?
<drewn3ss> 2.7.7 or later?
<narindergupta> 2.8.1
<drewn3ss> I'll note that the 2.7.6 and earlier jujus won't work for actions without the links to dispatch.
<narindergupta> ubuntu@OrangeBox24:~/narinder/charm-k8s-cassandra$ juju controllers
<narindergupta> Use --refresh option with this command to see the latest information.
<narindergupta> Controller        Model           User   Access     Cloud/Region        Models  Nodes    HA  Version
<narindergupta> foundations-maas  default         admin  superuser  maas_cloud               1      1  none  2.8.1
<narindergupta> k8s-cloud*        cassandramodel  admin  superuser  microk8s/localhost       2      1     -  2.8.1
<drewn3ss> wild.
<narindergupta> ack
<drewn3ss> so, operator isn't doing anything fancy in the way of finding python for you, so there must be something different about the env/path when doing run-action vs juju run (some hook)
<drewn3ss> wondering if this is a juju bug in general, or you need to apt-install python3 in your container.
<drewn3ss> neither of which seems right.
<narindergupta> drewn3ss, I am using Datastax Cassandra container directly from there.
<drewn3ss> narindergupta: if you fake in a symlink from actions/status to ../dispatch, I wonder if it resolves.
<narindergupta> In build
<drewn3ss> probably going to have to unzip the .charm file
<drewn3ss> and add it in there
<drewn3ss> and deploy the unpacked directory
<drewn3ss> just to test the theory
<narindergupta> drewn3ss, I never unzip it...
<drewn3ss> well, you certainly can if you want to see under the covers.  it's not quite exactly the same as what's in the build dir.
<drewn3ss> but .charm is just a classic charm dir in zip format
 * drewn3ss wonders if this would be helpful:https://github.com/canonical/operator/issues/292
<drewn3ss> looks like the framework has access to run requests against the k8s api where you could trigger a kubectl exec-like job
<drewn3ss> but I don't think that's the problem you're having
<narindergupta> drewn3ss, reading
<drewn3ss> also, os.popen is deprecated and subprocess.check_output should be used.
<drewn3ss> it may be that os.popen could be trying to re-fork your current python environment and failing.
<narindergupta> drewn3ss, ok I can try that but by reading above issue I do not think so that will solve my problem though
<drewn3ss> yeah, wish I knew more about how the framework around k8s charms worked.
<drewn3ss> good luck
<narindergupta> drewn3ss, thanks man no worries you did try...
<narindergupta> drewn3ss, fyi same error
<Chipaca> mthaddon: so, that thing kept on kicking around my brain and bothering me
<Chipaca> mthaddon: here's what you want to do:
<Chipaca>     @unittest.mock.patch.object(Unit, 'is_leader')
<Chipaca> where Unit is ops.model.Unit
<Chipaca> that's all. Good night.
#smooth-operator 2020-08-27
<mthaddon> Chipaca (although you're not here) thx! :)
<Chipaca> morning all
<mthaddon> Chipaca: morning! thx for the mock - that definitely works, just need to figure out why mocking GunicornK8sCharm directly doesn't work
<Chipaca> mthaddon: as I read it, the first argument to patch() needs to be something you can import
<Chipaca> so it doesn't work on methods nor attributes of a class
<Chipaca> and doubly so for methods on attributes of attributes of attribtues of a class :-p
<Chipaca> (because charm.unit is charm.model.unit is charm.framework.model.unit)
<mthaddon> right, I see
<mthaddon> so the message "ModuleNotFoundError: No module named 'charm.GunicornK8sCharm'; 'charm' is not a package" is a little confusing because you can import charm (we're doing that earlier in the tests), but you can't import the specific thing I was trying to mock
<Chipaca> mthaddon: a package and a module are different things
<Chipaca> mthaddon: charm is indeed not a package
<Chipaca> it is a module
<Chipaca> mthaddon: took me a bit to notice that one :)
<Chipaca> mthaddon: packages are modules that have modules in them
<Chipaca> what it's saying is that it can't do "from charm.GunicornK8sCharm import blah"
<Chipaca> (although AIUI it's actually trying something even deeper, ie importing charm.GunicornK8sCharm.model.unit
<Chipaca> )
<Chipaca> mthaddon: and reading https://github.com/python/cpython/blob/3.8/Lib/unittest/mock.py#L1546 what it does is drop the last .foo, and then walk the other things importing them
<Chipaca> ie if you say patch('foo.bar.baz.quux') it'll import foo, foo.bar, foo.bar.baz, and then grab quux from the last one
<mthaddon> ack, thx for the info - will read up on that
<moon127> Chipaca: Do you think we could get a review of https://code.launchpad.net/~moon127/charm-k8s-unifi-poller/+git/charm-k8s-unifi-poller/+merge/389643 today now we discussed and pushed changes?  It would be nice to get that landed.
<Chipaca> moon127: yes
<moon127> ta
<Chipaca> the behaviour of subprocess.run() with shell=1 and multiline arguments on windows is less than good
<Chipaca> grmbl
 * bthomas does cart wheels
<bthomas> Fixed problem with charm not updating status. Now get hook failed "start". Some progress .
<facubatista> Â¡Muy buenos dÃ­as a todos!
<facubatista> Chipaca, "the behaviour of .* on windows is less than good"
<facubatista> Chipaca, hola! if I get to land https://github.com/canonical/charmcraft/pull/140 , I'll start the release process
<mup> PR charmcraft#140: Always log the charmcraft version when indicated <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/140>
<Chipaca> facubatista: +1
<facubatista> Chipaca, thanks
<facubatista> Chipaca, let's take a look at https://github.com/canonical/charmcraft/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.4.0 ? The three issues there are not finished, but progressed enough and we can aim those to 0.5.0 now, let's move them?
<Chipaca> facubatista: fo sho
<facubatista> ?
<Chipaca> facubatista: for sure
<facubatista> Chipaca, no meeting?
<Chipaca> facubatista: michaÅ set themselves as not going, so Â¯\_(ã)_/Â¯
<facubatista> natalia is not "no" but neither "yes" :/
<facubatista> Chipaca, improve as you will, and let me know, thanks! http://linkode.org/#AvxqcVJWEFzDCEGONFFN53
<facubatista> Chipaca, I improved the order (forgot to do that), please check linkode's node 2
<Chipaca> facubatista: specifities?
<narindergupta> Chipaca, at last I was able to run the action but I have install python3 as python2 was not sufficient enough to run the action. Is it something we can change?
<Chipaca> narindergupta: no
<Chipaca> python 2 is not supported
<narindergupta> Chipaca, so python3 is prerequisite for action
<narindergupta> Chipaca, ok so we have to install it manually in k8s for Cassandra.
<narindergupta> Chipaca, also event.set_results({"message": outputmes}) it seems it took me sometime to understand the format. Do you think it can make it easy for others in framework.
<Chipaca> facubatista: check node 3 plz
<facubatista> Chipaca, "commandline" or "command line"?
<Chipaca> facubatista: both :-D
<Chipaca> narindergupta: what exactly is the problem with set_results?
<narindergupta> Chipaca, there is no problem just to understand the how parameter passed took me sometime. I was expected just message string but I have provide "message": "string"
<Chipaca> narindergupta: i mean, it's a mapping
<Chipaca> it doesn't have to be "message"
<narindergupta> yeah
<narindergupta> event.set_results({"message": outputmes})
<narindergupta> I have to use above command to setup the action message
<Chipaca> narindergupta: because actions results are mappings
<narindergupta> Chipaca, I understand it now and it took me sometime to understand it that's what I am trying to communicated.
<narindergupta> Chipaca, this is what charmcraft provide event.set_result(
<narindergupta>                 "Probability is too important to be left to the experts."
<narindergupta>                 " -- Richard Hamming")
<narindergupta> And which does not work.
<Chipaca> d'oh, that's a bug
<narindergupta> Chipaca, just one more query do we know which even get fired if we use juju remove-unit
<Chipaca> facubatista: can we slip a fix for this into today's release
<Chipaca> it's super small but it's a bug that breaks the action
<Chipaca> anyway, heading into an interview now
<facubatista> Chipaca, yes
<facubatista> Chipaca, let's talk after your interview
<jam> morning all
<bthomas> good to have you back jam
<jam>  o/
<justinclark> hello o/
<Chipaca> justinclark: ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<deej> Chipaca: If you've got a chance to have a look back at the MPs on the openldap charm it'd be appreciated, there's a couple bits of cleanup I'd like to get landed but it'd be nice to get these out of the way first
<deej> https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345
<deej> https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606
<facubatista> hola justinclark
<facubatista> Chipaca, so, which bug we should work on urgently?
<Chipaca> deej: augh. will try to get to those right after the ones for moon127
<Chipaca> facubatista: i don't think narinder filed it :-)
<deej> Right on, ta!
<Chipaca> facubatista: i'll try to repro it now, but it's easy to see
<Chipaca> facubatista: the arg to set_result in _on_fortune_action in charm.py.j2 is wrong
<Chipaca> facubatista: because set_result doesn't exist, and set_results takes a map
 * justinclark is caffeinated
<Chipaca> so it's all wongled
<Chipaca> hmmmm
<Chipaca> or maybe i'm confused and there is no bug
<Chipaca> hmmmmmÂ³
<Chipaca> hah! mocks
<Chipaca> yeah, it's a bug
<Chipaca> the code tests that it does what it does, which is not what it should do
<Chipaca> facubatista: charmcraft#141
<mup> Issue charmcraft#141: action created with 'charmcraft init' calls nonexistent method set_result on the action event <Created by chipaca> <https://github.com/canonical/charmcraft/issues/141>
<facubatista> Chipaca, you working on it or shall I?
<drewn3ss> Am I right in that there's no way to unregister an observer in the code currently?
<Chipaca> committing the fix
<Chipaca> drewn3ss: yup
<Chipaca> drewn3ss: what would you do that for? :)
<drewn3ss> let me send the code for a better explanation.
<drewn3ss> but basically, on_relation_joined of an interface Object may need to register itself to observe config_changed
<drewn3ss> but on departed, if there are none left, it should stop responding to the hook
<drewn3ss> I mean, it'll still be there and it will be a no-op because there's no related units
<drewn3ss> the classic "scale-back" issues of charming.
<Chipaca> drewn3ss: yeah, share code, because that didn't make sense to me when reading it
<Chipaca> if you register interest in an event in an event handler, you'll never get called
<Chipaca> so... i guess it already deregisters? always? unconditionally no matter what? :-p
<drewn3ss> well, I first ran into this because I was observing config_changed from init of the object
<drewn3ss> rather than from within the event
<drewn3ss> and then it was observing config_changed before it was even attached
<drewn3ss> which was not intended
<Chipaca> drewn3ss: if your charm doesn't register to observe an event in its constructor, it will never 'get' that event
<Chipaca> drewn3ss: the charm isn't "alive" all the time, it's brought up, constructed from zero, for every event
<Chipaca> drewn3ss: so one thing you _could_ do (and I'm not saying it's a good idea) is set a flag in stored state and use that in __init__ to observe or not a certain event
<drewn3ss> https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm#n31
<Chipaca> facubatista: https://github.com/canonical/charmcraft/pull/142 alstublieft
<mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
<facubatista> ack
<drewn3ss> and where it's instantiated in the code https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/src/charm.py?h=feature/public-charm#n55
<drewn3ss> provider relations need to be able to react to config_changed
<drewn3ss> and that needs to not have to be handled by the charmer, is my gut feeling
<drewn3ss> though, hmm...now that I'm thinking about it, I need to be able to update the config of the relation on config-changed, so maybe that's the wrong place to put it.
<drewn3ss> but I'm still going to have to register it and deregister it on joined/departed
<drewn3ss> because I don't want to react to config_changed until I've got the relation available
<drewn3ss> actually, yeah, that should only be reacting to changes of it's own config...nvm, I see your point, and it's not something I need now, but I will need to de-register in the future, I feel.  or just ensure it's a no-op when I get there because there are no related units.
<drewn3ss> ok, I've put the code in the riight path now, but I think I need to figure out what event.defer() does.
<Chipaca> drewn3ss: event.defer marshals the event and plops it into a database, and it's then at the top of the queue the next time the charm comes up to handle an event
<Chipaca> drewn3ss: so i guess the exception to the '1 event per charm invocation' is deferreds, which get to run before the event that caused the charm to be built
<drewn3ss> ok
<drewn3ss> does that happen on failed hook --retry, too?
<Chipaca> yes i don't think the charm gets to know it's a "retry"
<drewn3ss> makes sense.
<drewn3ss> thanks!
<Chipaca> hth
<drewn3ss> now I just have to ask why the original coder of this charm wanted to defer some of these events.
<drewn3ss> looks like it's order of operations management
<Chipaca> drewn3ss: there is a need for something a charmer can used to say "don't bother me at all until all these things are true", which is the dependencies thing
<facubatista> narindergupta, may I have your review of https://github.com/canonical/charmcraft/pull/142 ? thanks
<mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
<drewn3ss> ah, ok.  so, a "schedule me later". rather than building a finite state machine.
<drewn3ss> thanks, Chipaca!
<facubatista> FSMs are hard
<Chipaca> blessed be its noodly appendeges
<facubatista> :)
<Chipaca> ah no, wrong FSM
<facubatista> Chipaca, also hard
<drewn3ss> lol
<Chipaca> facubatista: I remember the syncdaemon FSM
<Chipaca> facubatista: I'm going to fix the indentation of 142 by choosing a shorter fortune
<facubatista> Chipaca, oh yes
<facubatista> Chipaca, good choice
<facubatista> justinclark, bthomas, may I have a review on https://github.com/canonical/charmcraft/pull/142 ? thanks!
<mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
<bthomas> facubatista: having a look
<facubatista> Ah, narindergupta  mentioned it's ok but didn't approve
<facubatista> bthomas, thanks
<narindergupta> facubatista, I have no option to approve may be I am not part of team?
<narindergupta> facubatista, gotchu you approve now
<facubatista> thanks!
<facubatista> Chipaca, we need to wait for Travis, now
<Chipaca> facubatista: we no longer need to wait for travis
<facubatista> Chipaca, wonderful, thanks
<Chipaca> mthaddon: i think you forgot to 'accept' https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345 when you did 'looks good to me'
<Chipaca> mthaddon: er, i meant 'approve'
<Chipaca> i'll look at the following one tomorrow
<Chipaca> EOD becuase #nobrain
* ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.8.0 || charmcraft 0.4.0
<facubatista> Release done! Subproduct PR: https://github.com/canonical/charmcraft/pull/143
<mup> PR charmcraft#143: New release (and improved howto) <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/143>
<drewn3ss> \o/
<drewn3ss> facubatista: I'm working on developing a new operator interface (what would have been a layer) to be included in https://launchpad.net/interface-prometheus.  This interface layer, like many others from the reactive layer repository, does not have a setup.py to define the python package.  What does your team suggest for distribution, management, and inclusion of interface modules from upstream
<drewn3ss> projects where it may not be appropriate or possible to get them to add packaging to their interface?
<drewn3ss> I was seeing the readme suggests no need for submodules, but I'm wondering if this is the only solution, or if charmcraft might have another solution up it's sleeve?
<drewn3ss> technically, upstream is: https://github.com/tasdomas/juju-interface-prometheus
<drewn3ss> while we could suggest a setup.py PR and then include our personal branch in requirements.txt, this seems unideal.
<facubatista> drewn3ss, this interface is part of a charm?
<drewn3ss> yeah.  I'll point you at current code.  I want to move this interface into a public repo for use in all prometheus-exporter charms.
<drewn3ss> https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm
<drewn3ss> I'm still mid-dev cycle, but trying to find the apporpriate home for things like this, and it seems it'd be ideal to put it in the current interface project.
<facubatista> drewn3ss, on one side, if you put the interface under the opslib directory, then everybody having your charm could make use of it (using the operator's opslib import feature)
<drewn3ss> hmm...how's that work?
 * drewn3ss goes to see if that's in the readme
<facubatista> drewn3ss, but still leaves us to how people would get hold of your charm... currently it will need to have a setup.py to be pip-installed, being that from PyPI or directly from github
<facubatista> OTOH, charmcraft may grow the ability of downloading from charmhub in the future, but that's yet to discuss
<drewn3ss> I think we've got a transition timing issue to solve.  I like the ops.lib idea, but the owner of this interfaced should be the central consumer, which isn't getting ported to operator any time soon.
<facubatista> drewn3ss, what do you mean with "the central consumer"?
<drewn3ss> Well, thinking about distribution of this interface from a product perspective, this is an interface that is used to connect many different exporters to prometheus
<drewn3ss> so, ultimately, prometheus should be the project that owns this interface
<drewn3ss> and should live in that charm's opslib, right?
<drewn3ss> I, as the developer of one of 100 exporters shouldn't own the interface to the main/central consumer
<facubatista> drewn3ss, you *could*, and people could use yours if let's say Prometheus Inc :p doesn't provide one
<facubatista> I could provide another
<facubatista> and eventually Prometheus Inc could provide another
<drewn3ss> right, but we already have providers listed for several interfaces iin the reactive framework
<facubatista> anybody can decide which interface to use through opslib mechanism
<drewn3ss> is there anything you can point me to for opslib?
<drewn3ss> I've been sifting the discourse w/out finding quite what I'm looking for.
<drewn3ss> I did see ops-lib-pgsql is out on pypi
<drewn3ss> and so docs on how to use the libs makes sense, but how do I distribute?
<drewn3ss> and how do I make ensure namespace is clear and usable by me (ala snapstore registration of names)
<facubatista> drewn3ss, for opslib we don't have namespaces, you can push to PyPI a project 'drew-prometheus', which can have your interface under the opslib directory, and that will be enough for me to use it
<facubatista> we don't have much docs yet :(
<drewn3ss> okay, so I'd have to publish and maintain the package in pypi
<drewn3ss> but charmers have not had to do this in the past
<facubatista> drewn3ss, if it's pip-installable, you can leave it in github, but you need the setup.py
<facubatista> how was it distributed in the past?
<drewn3ss> layer.yaml interface-prometheus
<drewn3ss> https://github.com/juju/layer-index
<facubatista> drewn3ss, noted, I'll talk about this with Chipaca, thanks
<drewn3ss> much appreciated, thank you :)
<facubatista> :)
<drewn3ss> I'm just concerned that we have a lot of projects already established with owners for charm interfacing, and I don't want to reinvent all of that.
<facubatista> ack
<drewn3ss> (I also tried a lot of ways to get pip to just download a project w/out a setup.py and failed)
<drewn3ss> would be interesting if we could define a generic project that had a setup.py and took #egg as a variable to go hunt for the non-packaged module :)
<drewn3ss> but, lord... -_-
<drewn3ss> and to be clear, interface-prometheus is in our control, but elasticsearch interfaces are owned by omni-vector, for instance.
<facubatista> drewn3ss, I have to run now, but for sure I'll focus on this
<drewn3ss> thanks, m8.  have a good evening.
 * facubatista -> tennis, bbl
 * facubatista is back
 * facubatista eods and eows
<facubatista> see you all back on Monday
#smooth-operator 2020-08-28
<mthaddon> Chipaca: yep, have added an approving review overnight (had deliberately held off til then to avoid confusion about whether it's ready to land before you guys have had a chance to review it)
<Chipaca> mthaddon: ð
<bthomas> Chipaca: could you recommend some well made operator charm, so I can check that there is nothing wrong with my juju/microk8s setup ?
<Chipaca> hmm
<bthomas> :)
<Chipaca> looking for one that's public and doesn't need a whole lot of other stuff around it
<bthomas> ð
<Chipaca> bthomas: https://code.launchpad.net/~mattermost-charmers/charm-k8s-mattermost/+git/charm-k8s-mattermost
<bthomas> Thanks Chipaca : will give it a shot
<Chipaca> bthomas: requires a custom image, instructions in the README
<bthomas> will read
<bthomas> The mattermost charm uses https://code.launchpad.net/~stub/interface-pgsql/+git/operator as a submodule . And the interface-pgsql uses opslib as a submodule. In the opslib/pgsql sub-directory of the interface-pgsql there is a link to ".." which creates a cyclic inode structure.
<bthomas> Even though I am able to clone the mattermost charm using my launchpad credentials cloning it recursively fails
<bthomas> Even submodule update fails.
<Chipaca> bthomas: pgsql uses opslib as a submodule?
<Chipaca> not sure i understand what that means
<Chipaca> i guess i could check out that git repo again
<bthomas> Chipaca: interface-pgsql has a pgsql/opslib subdirectory in that subdirectory there is a link to ".."
<Chipaca> bthomas: I don't see that
<Chipaca> bthomas: maybe you updated the mod beyond what the charm specifies?
<bthomas> When I tried to build the mattermost charm, even though it built the charm it gave an error saying pgsql was not found. Upon digging further I found that it used a git submodule. There is no mention of this in the readme.
<bthomas> So I am not sure if it is ok to use the built mattermost charm without fixing the pgsql issue.
<Chipaca> bthomas: how did you get the submodule?
<bthomas> Chipaca: even if I do git clone git+ssh://balbir-thomas@git.launchpad.net/~stub/interface-pgsql/+git/operator interface-pgsql I can see the link
<Chipaca> bthomas: right, but the charm doesn't say 'grab the dev tip'
<Chipaca> bthomas: or does it/
<bthomas> Chipaca: Not sure. But the standard way to pull git submodules fails with mattermost charm. For example if I do "git clone --recursive git+ssh://balbir-thomas@git.launchpad.net/charm-k8s-mattermost". Tis fails to clone submodules.
<bthomas> Building mattermost charm without submodule produces an error, even though charm gets built.
<Chipaca> bthomas: did you try cloning with the https url?
<Chipaca> bthomas: it's possible you're missing the git-in-launchpad recommended git config; the .gitmodules file depends on that
<bthomas> Chipaca: Just did "git clone --recursive https://balbir-thomas@git.launchpad.net/charm-k8s-mattermost" with same result. I was not aware of git-in-launchpad.
 * bthomas googling git-in-launchpad
<Chipaca> bthomas: https://help.launchpad.net/Code/Git
<bthomas> Thanks Chipaca : will read
<Chipaca> bthomas: the 'configuring git' section
<bthomas> Chipaca: you were right. It was the git config. Thanks.
<Chipaca> bthomas: \o/
<gnuoy> Is it expected that when I try and push a charmcraft built charm to the charmstore it'll fail with "ERROR open mycharm.charm/bundle.yaml: not a directory" ?
<mthaddon> Chipaca: do you think you'll have time to review https://code.launchpad.net/~axino/charm-k8s-gunicorn/+git/charm-k8s-gunicorn/+merge/389554 soon? Junien has another MP that he's working on that depends on that but want to make sure there's not too much rebasing needed
<Chipaca> gnuoy: pushing it using the 'charm' tool? yes that won't work (unpack to a directory and push that)
<gnuoy> ack, thanks
<Chipaca> gnuoy: 'charmcraft upload' pushes to staging using the new APIs, if that's what you want though
<Chipaca> and that one does take the .charm (and not a directory)
<gnuoy> That is not what I want, but good to know, thanks.
<Chipaca> mthaddon: i've still got one from deej to review, and then one from justin, and then that one
<mthaddon> Chipaca: could i ask for this one to go above deej's? It's a day older, and there's another MP that depends on it, whereas deej's doesn't have another one depending on it
<Chipaca> mthaddon: i'll swap it with that one then
<mthaddon> perfect, thx
<justinclark> bthomas, did you get Mattermost running? I quickly tried deploying yesterday based on the README and it failed for me.
<justinclark> https://git.launchpad.net/~mattermost-charmers/charm-k8s-mattermost/tree/README.md
<bthomas> justinclark: Yes mattermost was running. It was idle because i did not provide it a database connection. But it was not my purpose to use it. I just wanted to check if it can be deployed and the container runs.
<justinclark> Ah okay. Thanks bthomas. It was probably the database for me too but got sucked into learning about cross model relations rather than going further with mattermost.
<Chipaca> justinclark: where was the charm you wanted reviewed?
<justinclark> https://github.com/justinmclark/grafana-charm-base/blob/master/src/charm.py
<justinclark> Thanks Chipaca!
<justinclark> Just FYI, jam suggested a change yesterday in an issue I opened. That is still WIP. Here's the issue: https://github.com/canonical/operator/issues/392
<justinclark> Pushed some other changes I made last night Chipaca. The charm deploys to microk8s just fine by itself, but it is quite uninteresting without relating a data-source for the dashboards. That still needs to be tested
<Chipaca> :)
<Chipaca> ok
<Chipaca> justinclark: you're using 'charmcraft build'?
<justinclark> Yes.
<Chipaca> justinclark: ok. You should probably embrace it more then :)
<Chipaca> justinclark: right now you're getting ops via a git submodule
<Chipaca> justinclark: instead of requirements.txt i mean
<Chipaca> justinclark: and the 'fixpath' hack is not needed
<justinclark> Chipaca: ah yes that needs to be a more prominent TODO. I used an out of date example when first starting and just didn't bother changing it as testing was working as expected.
<Chipaca> justinclark: the 'configured' and 'started' storedstate things were red flags but they're not used at all so that's alright (just drop them)
<Chipaca> justinclark: you're using f-strings which don't work on python 3.5 (which you'll get in xenial) so you might want to drop those too
<Chipaca> justinclark: and you're setting state around a pod.set_spec which _i think_ (but am waiting to hear back from juju people) doesn't make sense
<Chipaca> because statuses are immediate but set_spec is not
<Chipaca> IIRC at least :)
<Chipaca> jam: if you're around already, maybe you can answer that? (haven't heard back from #juju)
<jam> morning Chipaca. set_spec is not immediate, it doesn't happen until the hook exits
<jam> (in 2.8)
<Chipaca> jam: right, that one i know
<Chipaca> jam: but setting status is immediate, right?
<jam> Chipaca: status = Blah is immediate, yes
<Chipaca> so, yeah, that pattern is broken
<jam> so you can show progress during an operation
<Chipaca> this one: https://github.com/justinmclark/grafana-charm-base/blob/master/src/charm.py#L350
<Chipaca> jam: right but using it show progress for something you're scheduling to happen later won't dtrt
<Chipaca> in their defense, set_spec() does _sound_ immediate
<jam> Chipaca: correct. except that Juju filters Active status for the case of 'the pod hasn't actually started yet', and overrides it until the application pod has finished starting.
<Chipaca> maybe we should've called it set_spec_sometime_in_the_future_at_your_leisure_please_no_rush
<Chipaca> jam: oh that's sneaky
<jam> Chipaca: relation-set sounds immediate, too
<jam> Chipaca: this is a case where, Mark found out that 'leader-set' was immediate, which breaks the 'transactionality' that all other relation-get/relation-set code has.
<jam> So we went on a hunt for other things that violated that
<jam> and found pod-spec-set.
<jam> So we pushed for it to be changed
<jam> but having worked with charmers for much longer
<jam> I don't feel like pod-spec-set is an interaction *with other charms* it is an interaction with the charm and its application
<jam> so I no longer feel it should be transactional
<jam> (we don't put a transaction around 'systemctl start foo'
<jam> however, we do need to deal with how it is currently, and not how it might theoretically work
<jam> Also, the new work gets rid of pod-spec-set for charms running as sidecars
<Chipaca> yep
<Chipaca> jam: does the 'pod hasn't actually started yet' override thing mean that the code i linked to would currently dtrt w/2.8?
<jam> Chipaca: I don't think it would stay in the "maintenance with 'setting pod spec'" but otherwise yes
<jam> (eg, it uses Juju's 'pod not started yet' message, though I don't know the exact words)
<Chipaca> k
 * justinclark thanks Chipaca and jam for feedback :)
 * justinclark pushes python 3.5 under the rug and blows things up
<Chipaca> :)
<Chipaca> justinclark: one silly thing I'd also do in your charm is make the log.error call for missing fields mention exactly what was missing, instead of everything that's required
<justinclark> Chipaca: will do. Can you elaborate on the 'fixpath hack'?
<justinclark> I'm not sure what that hack is.
<Chipaca> justinclark: your charm.py does 'import fixpath'
<Chipaca> justinclark: fixpath.py just adds lib to sys.path
<Chipaca> justinclark: this was needed before charmcraft took on the job of setting up the environment for the charm
<Chipaca> justinclark: it's a hack, which is why you need to tell pyflake to ignore it
<justinclark> I see. Thanks.
<Chipaca> EOWing here
<Chipaca> bye all! see you tuesday
<jam> have a great weekend ChanServ
<jam> dang, gone already :)
