[04:05] <jam> morning all
[05:13] <MarkMaglana> jam: wazaaaaaaap
[05:14] <MarkMaglana> we're in the middle of the WTF part of the week! hang in there!
[05:14] <MarkMaglana> Well, technically the WThF part of the week but every keystroke counts.
[06:30] <jam> :)
[08:14] <Chipaca> moin moin
[08:19] <Chipaca> jam: any chance of a review of charmcraft#23 so we can put out a fix?
[08:19] <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23>
[08:20] <jam> Chipaca, to make sure I understand the bash magic, "JUJU_DISPATH_PATH=${{JUJU_DISPATCH_PATH:-$0}}" sets the env var to argv[0] if it isn't set, and then double {{ is because it is in a python format template, right?
[08:21] <jam> Chipaca, Approve as long as I understand that correctly
[08:21] <Chipaca> jam: yep, that's all correct
[08:35]  * Chipaca resurrecting a borked juju
[08:41] <Chipaca> jam: charmcraft#25 could use a rubber stamp
[08:41] <mup> PR charmcraft#25: bump version for 0.1.1 <Created by chipaca> <https://github.com/canonical/charmcraft/pull/25>
[08:41] <jam> stamped
[08:42] <Chipaca> thanks
[08:42] <Chipaca> i'll land that with just that +1 and release it into the wild
[08:48] <Chipaca> siiiigh
[08:48] <Chipaca> 0.1.1 bites me again
[08:53] <Chipaca> jam: same for charmcraft#26 :-(
[08:53] <mup> PR charmcraft#26: bump version for 0.1.2 <Created by chipaca> <https://github.com/canonical/charmcraft/pull/26>
[08:53] <jam> Chipaca, I refuse. too much stamping... :)
[08:53] <Chipaca> fair
[08:53] <jam> done
[08:54] <Chipaca> thanks
[10:28] <mup> PR operator#322 opened: log: set up sys.excepthook to log exceptions <Created by chipaca> <https://github.com/canonical/operator/pull/322>
[10:51] <jam> Chipaca, do you have a preference for new dates at the start/end of the doc? I actually prefer the newest to be the beginning of the doc, but I know you found it confusing w Tom
[10:51] <Chipaca> jam: I prefer if we choose one and stick to it. I don't mind which :)
[10:52] <Chipaca> inserting it from the top works for me (it's what we do in the standup doc for ex)
[10:52] <Chipaca> jam: i'm not sure why i got confused yesterday
[10:52] <Chipaca> i've got my suspicions though :)
[10:53] <jam> Chipaca, one thing that I find helps a lot is to put a Page Break between sections, as it makes it less 'run on'
[10:53] <Chipaca> sgtm
[10:56] <Facu> Muy buenos días a todos!
[10:57] <jam> morning Facu
[10:57] <jam> Chipaca, so i've run into something interesting with YAML.
[10:58] <jam> namely "yaml.dump({'a': (1,2)})" writes the document as "a: !!python/tuple [1,2]"
[10:58] <jam> which round-trips if you then call 'yaml.load'
[10:58] <jam> but *not* if you call yaml.safe_load
[10:58] <jam> and, in fact, it fails with:
[10:58] <jam> yaml.constructor.ConstructorError: could not determine a constructor for the tag 'tag:yaml.org,2002:python/tuple'
[10:58] <jam>   in "<byte string>", line 5, column 6:
[10:58] <jam>     six: !!python/tuple [a, b]
[10:59] <Chipaca> hmm
[10:59] <Facu> weird
[10:59] <Chipaca> now i wonder what 'safe' brings to the party in this context
[11:00] <Facu> Chipaca, not running any code?
[11:02] <Chipaca> 'The function yaml.safe_load limits this ability to simple Python objects like integers or lists.'
[11:02] <Chipaca> … but not tuples?
[11:17] <Chipaca> jam: so apparently the recommendation is to subclass the safe loader and add constructors for the non-standard bits we want
[11:17] <jam> Chipaca, yeah, that is what I was looking at doing
[11:17] <Chipaca> ok
[11:18] <jam> I think anything that is "!!python/" it doesn't allow by default, which is why I'll add it.
[11:18] <jam> I'm just a bit surprised that tuple isn't considered safe but "set" was
[11:18] <Chipaca> jam: apparently !!set is a standard yaml thing
[11:18] <Chipaca> which i didn't know :)
[11:18] <Chipaca> i mean, that's what https://pyyaml.org/wiki/PyYAMLDocumentation says
[11:19] <Chipaca> afaict the only thing there we need is tuple, and arguably complex
[11:19] <Chipaca> ah i guess none also
[11:19] <Chipaca> but that probable goes to null
[11:19]  * Chipaca tries
[11:19] <Chipaca> yeah
[11:21] <jam> None => null by default, yeah.
[11:25] <jam> Chipaca, where do you see the bit about inheriting? The thing I see is "your types can add a property yaml_loader to SafeLoader"
[11:25] <jam> which I don't think I can do to tuple()
[11:26] <jam> oddly, they mention using safe_dump() to ensure you don't dump classes, etc. But 'safe_dump' still puts !!python/tuple which safe_load doesn't support
[11:26] <jam> ah, it actually doesn't. nm
[11:29] <jam> Chipaca, https://stackoverflow.com/questions/9169025/how-can-i-add-a-python-tuple-to-a-yaml-file-using-pyyaml
[11:29] <jam> PrettySafeLoader
[11:29] <Chipaca> jam: or https://stackoverflow.com/questions/33048540/pyyaml-safe-load-how-to-ignore-local-tags :)
[11:30] <Chipaca> sorry was afk directing lunch prep here
[11:40] <Chipaca> hehe
[11:40] <Chipaca> yaml.CSafeLoader.yaml_constructors['tag:yaml.org,2002:python/tuple'] = yaml.Loader.yaml_constructors['tag:yaml.org,2002:python/tuple']
[11:41] <Chipaca> probably not the right thing :-D
[11:43] <Chipaca> but otoh can't see why not
[11:46] <Chipaca> also note set(yaml.Dumper.yaml_representers) - set(yaml.SafeDumper.yaml_representers)
[11:47] <Chipaca> but, yaml.SafeDumper.yaml_representers[tuple] is represent_list
[11:50] <Facu> Chipaca, jam, where are we yaml-dumping tuples?
[11:50] <Chipaca> Facu: looking at replacing base64+pickle with something more human-friendly
[11:51] <Chipaca> Facu: for the fix to #317
[11:51] <mup> Issue #317: use charm state for Juju 2.8 <Created by jetpackdanger> <https://github.com/canonical/operator/issues/317>
[11:51] <Facu> Chipaca, WAT, you can not read pickle? :p
[11:52] <Chipaca> Facu: obvs i can, but we have human users also
[11:52] <Facu> Chipaca, humans! always complicating stuff
[11:52] <Chipaca> ikr
[11:54] <jam> Chipaca, Facu also if we're happy with pickle we could just 'load()' but I'd like to be safer than raw pickle
[11:54] <Chipaca> jam: it's fine, the brine keeps things safe
[11:54] <Facu> TOML?
[11:54]  * Facu hides
[11:55]  * Chipaca writes a CHIPACAL spec
[11:55] <Chipaca> CHIPACL?
[11:55] <Chipaca> CHIPL
[11:55] <Chipaca> CHIL'
[11:55]  * Chipaca stops
[11:56] <Facu> Chipaca, jam, what is a good message for the signature deprecation?
[11:57] <Chipaca> Facu: "LOL look at you, passing in 'key'! That's *so* last release!"
[11:57]  * Chipaca suspects that would actually work
[11:57] <Facu> "CharmBase signature's second argument is deprecated, will be removed in 0.3.0, just use 'framework'"
[11:57] <jam> Facu, "key argument has been deprecated and will no longer be supplied in future versions"
[11:58] <Chipaca> 0.8
[11:58] <Chipaca> not 0.3
[11:58] <Chipaca> :)
[11:58] <Facu> I like the "future versions" and not be explicit, in case we want to delay the removal later
[11:58] <Chipaca> hm
[11:58] <Facu> jam, "key...", not "the key..."?
[11:58] <Chipaca> ok, 'after 0.7'
[11:59] <Facu> "the 'key' argument has been deprecated and will be removed after 0.7 version"?
[11:59] <jam> Facu, I like your "second argument"
[12:00] <Chipaca> might be a minute late, somebody's at the door
[12:00] <Facu> "the 'key' second argument has been deprecated and will be removed after 0.7 version"?
[12:03] <Chipaca> Facu: "the second argument, 'key', has been deprecated and will be removed after the 0.7 release"
[12:48] <jam> Chipaca, today's xkcd is pretty good: https://xkcd.com/2315/
[12:49] <jam> heat-death of the universe guarantee's my database's eventual consistency
[12:50]  * Facu brb
[12:52]  * Chipaca pokes at the network again
[13:15] <mup> PR operator#323 opened: 317 state get <Created by jameinel> <https://github.com/canonical/operator/pull/323>
[14:40]  * facubatista -> errands
[15:42]  * facubatista is back
[15:53] <Chipaca> fiuuuuuu
[15:53] <Chipaca> talking with people
[15:53] <Chipaca> why do we even
[16:00] <Chipaca> jam, facubatista, both of you have +1'ed one, but not both, of the CoC PRs :-)
[16:00] <jam> Chipaca, we like to keep you guessing
[16:01] <Chipaca> jam: ooh, ooh, is it bigger than a breadbox?
[16:02] <Chipaca> is this breadbox container-sized?
[16:02] <Chipaca> or is it a breadbox as in the thing used for playing around with electronics
[16:04] <facubatista> Chipaca, will get to it in ~20'
[16:29] <mup> Issue operator#308 closed: have a code of conduct <Created by chipaca> <Closed by facundobatista> <https://github.com/canonical/operator/issues/308>
[16:29] <mup> PR operator#321 closed: have a Code of Conduct <Created by chipaca> <Merged by facundobatista> <https://github.com/canonical/operator/pull/321>
[16:31] <Chipaca> facubatista: suddenly feeling the urge to make 'python3 -m ops src/charm.py MyCharm' work, for some reason
[16:32] <facubatista> Chipaca, what for? ops is a lib, not an utility
[16:32] <facubatista> making it "half utility" will bring a lot of little rough corners
[16:32] <Chipaca> facubatista: because if all 'if __name__ == "__main__"' bits of charms look the same, why have them?
[16:33] <Chipaca> facubatista: I'm not going to be acting on this urge FWIW :) at least not this time
[16:33] <facubatista> Chipaca, oh, which reminds me! I wanted to talk about CharmBase init, let's talk on Monday about that
[16:33] <Chipaca> facubatista: is that the same as charmcraft init
[16:33]  * Chipaca hids
[16:34]  * Chipaca hides, also
[16:34] <facubatista> no, no
[16:34]  * facubatista laves suspense grow
[16:34] <facubatista> *lets
[16:34]  * Chipaca makes 'charmcraft innit' be an alias
[17:01]  * Chipaca EODs
[17:02] <Chipaca> well, mostly
[17:45] <davigar15> https://pastebin.canonical.com/p/nzmgGT7bMS/
[17:45] <davigar15> I'm getting that error in a relation
[17:45] <davigar15> Any ideas?
[17:47] <davigar15> That's the function is falling in: https://pastebin.canonical.com/p/Q6RCDf4pcK/
[17:47] <davigar15> In the relation-set hook, I suppose
[17:48] <davigar15> app_data = self._relation.data[self.model.app]
[17:48] <davigar15> app_data['port'] = str(port)
[17:48] <davigar15> But I think that's correct ^
[17:50] <facubatista> davigar15, let me see
[17:51] <facubatista> uh, juju is crashing
[17:51] <facubatista> davigar15, please print (with repr()) the values for port, rest_port and host
[18:00] <davigar15> application-zk3: 20:00:19 INFO unit.zk3/0.juju-log zookeeper:7: IPv4Address('10.152.183.60')
[18:00] <davigar15> There you go. IPv4Address
[18:01] <davigar15> maybe str(host) right?
[18:01] <Facu> ah, you're doing a str() of it
[18:01] <davigar15> nope, not in the host
[18:01] <Facu> davigar15, that IPv4Address is "host"?
[18:01] <davigar15> only in the ports
[18:01] <davigar15> yes
[18:02] <Facu> right, that will not travel through the relation
[18:02] <davigar15> Juju was telling me that values must be strings, not integers
[18:02] <Facu> jam, Chipaca, I wonder if we should detect this ^ *before reaching Juju*
[18:02] <davigar15> so I put str in ports
[18:02] <davigar15> If I put a number it tells you exactly what's the problem
[18:36] <Facu> jam, please when you're back check if you find why juju is crashing on davigar15, thanks!
[18:47] <jam> davigar15, I don't know the immediate reason why, can you give the Juju version you're running?
[18:47] <jam> nil-pointer panic is definitely a Juju bug
[18:47] <jam> there may be other things that could go wrong, but we should never panic
[18:49] <jam> davigar15, please add details to: https://bugs.launchpad.net/juju/+bug/1882127
[18:56] <Facu> jam, I told him to run the commands by hand (after the proper `juju debug-hooks`) but it looks he can't because of k8s
[18:57] <Facu> jam, thanks for the help!
[19:05] <davigar15> 2.7.6 juju version
[19:05] <davigar15> I’ll give the details tomorrow
[19:14] <davigar15> Jam: you were fast!! I see you already updated the bug
[20:30] <Facu> jam, do we have a simple example on how to start with the Harness?
[20:30] <Facu> Chipaca, ^
[21:10] <Chipaca> Facu: in the README?