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