[03:15] <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.
[03:16] <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)
[07:52] <axino> hello
[07:53] <axino> should I be able to easily unittest leader-get calls with the current version of the ops framework ?
[07:54] <axino> I can see relation-get/relation-set and is-leader, but not leader-get
[07:55] <bthomas> 𝓖𝓸𝓸𝓭 𝓜𝓸𝓻𝓷𝓲𝓷𝓰
[09:50] <Chipaca> good morning peeps!
[09:52] <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.
[09:55] <Chipaca> bthomas: fresh eyes \o/
[09:58] <bthomas> Yep. Mornings are best for both coding and math.
[10:00] <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.
[10:01] <Chipaca> more good news: https://arstechnica.com/science/2020/08/black-paint-on-wind-turbines-helps-prevent-bird-massacres/
[10:01] <bthomas> indeed
[10:02] <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
[10:25] <Chipaca> bthomas: or team up with kfc
[10:25] <axino> hello again
[10:26] <bthomas> rol
[10:26] <Chipaca> axino: 👋
[10:26] <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
[10:27] <axino> which is completely unrelated to the function I want to test
[10:27] <Chipaca> axino: what code does it trigger?
[10:28] <Chipaca> axino: are you trying to test what happens when something becomes the leader in the middle of something?
[10:28] <axino> Chipaca: nope
[10:28] <Chipaca> axino: or are you trying to test what happens when something is the leader already
[10:28] <axino> ^ this
[10:29] <Chipaca> axino: then harness.set_leader before harness.begin should not trigger anything
[10:29] <axino> I see
[10:29] <axino> hmm
[10:30] <axino> except we initialize the harness in setUp() currently
[10:30] <Chipaca> axino: including harness.begin?
[10:30] <Chipaca> hmm
[10:30] <axino> indeed
[10:31] <axino> is there an harness.stop equivalent ? :)
[10:31] <axino> I see we call harness.cleanup() in tearDown()
[10:32] <Chipaca> axino: you could harness.disable_hooks()
[10:32] <Chipaca> axino: that'll stop leader_elected from being emitted
[10:34] <axino> ok
[10:35] <axino> Chipaca: that works indeed !
[10:35] <axino> thank you
[10:36] <axino> Chipaca: for context this is to test _on_database_relation_joined() as coded in https://github.com/canonical/ops-lib-pgsql
[10:38] <axino> I'm still curious, for my personal knowledge, how I would mock self.model.unit.is_leader() calls btw :)
[10:42] <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.
[10:47] <Chipaca> bthomas: if you take a step back, can you get k8s to do the thing you want it to do without juju?
[10:48] <Chipaca> bthomas: juju's job is to automate things, but you need to be able to do those things to automate them :)
[10:48] <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.
[10:49] <Chipaca> moon127: 👍
[10:51] <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.
[10:52] <Chipaca> axino: what's your github @?
[10:53] <mthaddon> Chipaca: https://github.com/axinojolais
[10:54] <Chipaca> mthaddon: thanks
[10:54] <Chipaca> axino: https://github.com/canonical/operator/pull/393 :-)
[10:54] <mup> PR #393: adds Harness.hooks_disabled, a context manager <Created by chipaca> <https://github.com/canonical/operator/pull/393>
[10:54] <mup> PR operator#393 opened: adds Harness.hooks_disabled, a context manager <Created by chipaca> <https://github.com/canonical/operator/pull/393>
[10:55] <Chipaca> d'oh and the docstring is wrong
[10:55]  * Chipaca fixes
[10:57] <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
[10:57] <facubatista> ¡Muy buenos días a todos!
[10:57] <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
[10:58] <Chipaca> but those changes can result in passing unit tests on windows
[10:58] <Chipaca> (granted as i say there is 1 more thing to do, and that one is skipped currently)
[10:58] <Chipaca> but that's what i got to last night (or was it this morning) (it was a long hack sesh)
[10:59] <Chipaca> facubatista: buen día cabeza
[10:59]  * Chipaca speaking all proper-like today
[10:59]  * Chipaca needs more coffee
[11:00] <Chipaca> wrt windows again, i say "can result" because it makes some assumptions about windows
[11:00] <Chipaca> like, you have python and git-for-windows (inlcuding git-bash) installed
[11:00] <Chipaca> and it assumes things about how juju calls charms on windows, that need verifying
[11:00] <Chipaca> but seem sensible to me :)
[11:00] <Chipaca> anyway. coffee! and then to meet with mthaddon
[11:01]  * Chipaca looks at the time
[11:01] <Chipaca> or maybe the other way around
[11:16] <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
[11:17] <Chipaca> facubatista: yeah i'm hoping to refactor the is_windows checks into a couple of higher level functions
[11:17] <Chipaca> facubatista: e.g. i can hide most of it by just wrapping subprocess.run
[11:17] <facubatista> wonderful
[11:18] <facubatista> Chipaca, remember your https://github.com/canonical/charmcraft/pull/116
[11:18] <Chipaca> facubatista: and the _exe_path wrapper already there
[11:18] <mup> PR charmcraft#116: include install info in README <Created by chipaca> <https://github.com/canonical/charmcraft/pull/116>
[11:18] <facubatista> Chipaca, and please give a review in https://github.com/canonical/charmcraft/pull/137
[11:18] <mup> PR charmcraft#137: Fixed global options behaviour <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/137>
[11:18]  * Chipaca gets out his red byro
[12:03] <axino> Chipaca: thanks that looks useful
[13:10] <Chipaca> crodriguez_: WRT #1892255, do you still need a workaround for older jujus, or are you happy to work with 2.8.2?
[13:31] <jam> morning all
[13:32] <Chipaca> jam: 👋❗
[13:33] <Chipaca> jam: welcome to the other side :-D
[13:33] <crodriguez_> morning!
[13:33] <jam> Chipaca: indeed
[13:33] <crodriguez_> let me check which bug that is
[13:33] <jam> Chipaca: 2.8.2 isn't officially out yet, AIUI
[13:33] <Chipaca> jam: correct, it's in candidate
[13:35] <facubatista> hola jam, welcome back!
[13:35] <jam> hi facubatista
[13:36] <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.
[13:52] <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.
[14:00] <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
[14:00] <jam> it supports .ps1, .cmd, .bat and .exe
[14:53] <bthomas> Chipaca: I have a prometheus deployment running on microk8s accessible from localhost:8080
[14:54] <bthomas> Now still need to figure outh getting this working with juju
[14:54] <bthomas> and charms
[15:03] <facubatista> mthaddon, Chipaca, gunicorn meeting?
[15:03] <Chipaca> facubatista: 1'
[15:04] <Chipaca> jam: would it be reasonable to add .py with a special handler for it similar to .ps1 ?
[15:04] <mthaddon> facubatista: will be there in a few mins, just finishing up another call - axino are you on that one already?
[15:04] <axino> mthaddon: I am
[15:04] <Chipaca> *twice* :-p
[15:04] <mthaddon> ack, feel free to just go ahead without me
[15:15] <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
[15:15] <jam> for Linux
[15:16] <jam> (my concern is around things like "python isn't default installed on Windows, so you still have to get it there"
[15:30] <Chipaca> jam: i guess charmcraft can drop a .bat in there just fine
[15:40]  * facubatista -> live
[15:40] <facubatista> err, lunch :p
[16:09] <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 :/
[16:13] <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?
[16:17] <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.
[16:18] <narindergupta> bthomas, you mean use Kubectl using python? That won't be as efficient to use as charm action I guess?
[16:20] <bthomas> narindergupta: I was not thinking of charm action. It was if you just wanted to run a command in a container.
[16:22] <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.
[16:26] <bthomas> narindergupta: why are "os" or "subprocess" modules not suffecient for your purpose ?
[16:28] <facubatista> mthaddon, can you show the import failure you're getting? thanks
[16:39] <drewn3ss> narindergupta: would agree, subprocess.check_call or subprocess.check_output to nodetool within your on_action method should be pretty straight forward.
[16:40] <narindergupta> drewn3ss, bthomas yeah that's what I am trying but wanted to make sure there is no wrapper in framework
[16:40] <drewn3ss> no, best you might find is charmhelpers.core.host
[16:41] <drewn3ss> er, charmhelpers.cli
[16:44] <drewn3ss> narindergupta: https://charm-helpers.readthedocs.io/en/latest/api/charmhelpers.cli.html#charmhelpers.cli.CommandLine.run
[16:44] <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 ;-)
[16:44] <drewn3ss> *requirements.txt
[17:35] <narindergupta> drewn3ss, this is operator framework so I doubt this will work though
[17:41] <drewn3ss> you can certainly use charmhelpers in operator charms.
[17:42] <drewn3ss> but simpler is better
[17:51] <Chipaca> mthaddon: 'mock' is weird, you need to have the referred object in scope exactly as you pass it in
[17:51] <Chipaca> mthaddon: that first stringy argument is the 'target' of patch(), and the docs say:
[17:51] <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.
[17:53] <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
[17:54] <Chipaca> tomorrow i could actually try the code
[17:54] <Chipaca> today it's already beer o'clock here so no code is happening
[17:54] <Chipaca> (it's 0% beer but rules are rules)
[18:38] <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
[18:44] <facubatista> oh, no chipaca
[18:45] <mup> Issue operator#394 opened: Create basic documentation <Created by facundobatista> <https://github.com/canonical/operator/issues/394>
[19:48] <narindergupta> It seems operator framework is looking for python3. Can we use just python with operator framework rather than python3?
[19:48] <narindergupta> While running the action
[19:52] <drewn3ss> why are you looking to run python external to the charm?  are you trying to call "python nodetool"?
[19:54] <narindergupta> I am using juju run juju run-action cassandra/0 status --wait which internally call os.popen("nodetool status")
[19:55] <narindergupta> Give me error /usr/bin/env: ‘python3’: No such file or directory
[19:55] <narindergupta> I think juju internally runs the action using python call
[19:56] <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
[19:59] <drewn3ss> is nodetool the one stating #!/usr/bin/env python3?
[20:00] <narindergupta> drewn3ss, no nodetool works fine using kubectl exec
[20:00] <drewn3ss> narindergupta: can you share your code where the actions are configured?
[20:00] <narindergupta> drewn3ss, ok let me check in my code in github
[20:01] <narindergupta> Here it is https://paste.ubuntu.com/p/kJhtbVjBKj/
[20:01] <narindergupta> It is charm.yaml
[20:01] <narindergupta> This is action https://paste.ubuntu.com/p/ttPYqVKSCD/
[20:02] <narindergupta> microk8s.kubectl exec -n cassandramodel -it cassandra-0 -- nodetool status
[20:02] <narindergupta> Datacenter: datacenter1
[20:02] <narindergupta> [20:02] <narindergupta> Status=Up/Down
[20:02] <narindergupta> |/ State=Normal/Leaving/Joining/Moving
[20:02] <narindergupta> --  Address     Load        Tokens  Owns (effective)  Host ID                               Rack
[20:02] <narindergupta> UN  10.1.17.50  554.96 KiB  256     ?                 29057614-e28a-4331-a236-efff00a01312  rack1
[20:02] <narindergupta> UN  10.1.17.49  394.43 KiB  256     ?                 6b16060c-5240-4419-a069-e2203276400a  rack1
[20:02] <narindergupta> UN  10.1.17.48  417.78 KiB  256     ?                 76fdf154-7c06-4169-a01a-fbf22a42c9e6  rack1
[20:03] <narindergupta> Without juju
[20:03] <drewn3ss> are you making symlinks directly to charm.py?
[20:03] <drewn3ss> or are you running through the dispatch script
[20:03] <drewn3ss> because your code shouldn't need #!/usr/bin/env python3 at the top whatsoever
[20:04] <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.
[20:04] <narindergupta> No I am using charmcraft build and run charm from there
[20:04] <drewn3ss> if you make symlinks like the old charms, you're working around the framework's dispatcher
[20:04] <narindergupta> drewn3ss, this must be from charmcraft build
[20:05] <drewn3ss> oh, nvm, I do have the shebang on my charm.py too.
[20:05] <drewn3ss> and the dispatcher does use that shebang
[20:05] <drewn3ss> my bad
[20:05] <drewn3ss> so, do your other hooks work?
[20:06] <narindergupta> drewn3ss, yes like update status
[20:06] <narindergupta> Because those hooks might be running on operator
[20:06] <narindergupta> config_change works
[20:07] <drewn3ss> so, gonna need to see a find -ls of your build dir
[20:07] <narindergupta> Find what?
[20:07] <drewn3ss> "find ./build -ls" after you charmcraft build
[20:08] <narindergupta> Oh ok
[20:09] <narindergupta> https://pastebin.ubuntu.com/p/j6vxmwJ4W3/
[20:10] <drewn3ss> running a recent juju model, I assume?
[20:10] <drewn3ss> 2.7.7 or later?
[20:10] <narindergupta> 2.8.1
[20:10] <drewn3ss> I'll note that the 2.7.6 and earlier jujus won't work for actions without the links to dispatch.
[20:10] <narindergupta> ubuntu@OrangeBox24:~/narinder/charm-k8s-cassandra$ juju controllers
[20:10] <narindergupta> Use --refresh option with this command to see the latest information.
[20:10] <narindergupta> Controller        Model           User   Access     Cloud/Region        Models  Nodes    HA  Version
[20:10] <narindergupta> foundations-maas  default         admin  superuser  maas_cloud               1      1  none  2.8.1
[20:10] <narindergupta> k8s-cloud*        cassandramodel  admin  superuser  microk8s/localhost       2      1     -  2.8.1
[20:10] <drewn3ss> wild.
[20:11] <narindergupta> ack
[20:12] <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)
[20:13] <drewn3ss> wondering if this is a juju bug in general, or you need to apt-install python3 in your container.
[20:13] <drewn3ss> neither of which seems right.
[20:14] <narindergupta> drewn3ss, I am using Datastax Cassandra container directly from there.
[20:16] <drewn3ss> narindergupta: if you fake in a symlink from actions/status to ../dispatch, I wonder if it resolves.
[20:16] <narindergupta> In build
[20:17] <drewn3ss> probably going to have to unzip the .charm file
[20:17] <drewn3ss> and add it in there
[20:17] <drewn3ss> and deploy the unpacked directory
[20:17] <drewn3ss> just to test the theory
[20:17] <narindergupta> drewn3ss, I never unzip it...
[20:18] <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.
[20:18] <drewn3ss> but .charm is just a classic charm dir in zip format
[20:23]  * drewn3ss wonders if this would be helpful:https://github.com/canonical/operator/issues/292
[20:23] <drewn3ss> looks like the framework has access to run requests against the k8s api where you could trigger a kubectl exec-like job
[20:24] <drewn3ss> but I don't think that's the problem you're having
[20:24] <narindergupta> drewn3ss, reading
[20:25] <drewn3ss> also, os.popen is deprecated and subprocess.check_output should be used.
[20:25] <drewn3ss> it may be that os.popen could be trying to re-fork your current python environment and failing.
[20:27] <narindergupta> drewn3ss, ok I can try that but by reading above issue I do not think so that will solve my problem though
[20:27] <drewn3ss> yeah, wish I knew more about how the framework around k8s charms worked.
[20:27] <drewn3ss> good luck
[20:30] <narindergupta> drewn3ss, thanks man no worries you did try...
[20:43] <narindergupta> drewn3ss, fyi same error
[20:52] <Chipaca> mthaddon: so, that thing kept on kicking around my brain and bothering me
[20:52] <Chipaca> mthaddon: here's what you want to do:
[20:52] <Chipaca>     @unittest.mock.patch.object(Unit, 'is_leader')
[20:52] <Chipaca> where Unit is ops.model.Unit
[20:53] <Chipaca> that's all. Good night.