[08:28] <Chipaca> ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄ  ｍｏｒｎｉｎｇ！
[08:35] <Chipaca> brb, dog's whining about something
[09:02] <jam> morning Chipaca
[09:02] <Chipaca> jam: you should now be able to ask chanserv to change the channel topic (and other fun stuff)
[09:03] <jam> Chipaca, I can feel the power....
[10:45] <Chipaca> jam: that heady feeling of being able to kickban people
[11:03] <facubatista> ¡Muy buenos días a todos!
[12:11] <Chipaca> facubatista: 👋!
[12:11] <facubatista> hola Chipaca!
[12:15] <jam> Chipaca, question about Harness. While I'm adding support for auto triggering relations. There is a question for Peer relations.
[12:15] <jam> Currently with Harness, you have to call 'add_relation' even for peer relations that 'always exist'.
[12:15] <jam> I'd like for begin_with_hooks to do so automatically
[12:16] <jam> but should we also do so for just begin()? IMO it makes it harder to figure out when the associated hook would fire, etc.
[12:16] <Chipaca> jam: that seems in line with the difference between begin and begin_with_hooks
[12:16] <jam> Chipaca, chans-erv seems to have issues with facu :)
[12:17] <Chipaca> jam: the first two are me being lazy with flags (it's easier to +* and then deop than figure out the right invocation to do it in one pass)
[12:17] <facubatista> jam, we're setting it up
[12:17] <Chipaca> jam: i'm guessing the second is facu poking around :-)
[12:17] <jam> morning facubatista
[12:18] <Chipaca> jam: by 'in line' i mean, 'begin' should continue being barebones, so you can poke at things without everything else happening
[12:18] <jam> Chipaca, yeah, that's how I read it. SGTM
[12:18] <Chipaca> jam: and begin_with_hooks can be the 'what does it look like in the middle of an actual run'
[13:34] <Chipaca> bthomas: 👋
[13:36] <bthomas> thanks Chipaca
[14:01] <Chipaca> facubatista: there's a bug with the charmcraft release you did :-/
[14:01] <Chipaca> facubatista: and with the HOWTO i guess
[14:01] <Chipaca> facubatista: you're building locally, meaning you only build for amd64
[14:01] <Chipaca> facubatista: so charmcraft 0.3 is only out for amd64, any other arch gets 0.2
[14:02] <Chipaca> facubatista: 'snapcraft remote' should probably be in there :-|
[14:02] <Chipaca> remote-build*
[14:05] <facubatista> Chipaca, let me see
[14:06] <facubatista> Chipaca, ah, yes, there's even a FIXME in the howto: # FIXME: what about other archs
[14:06] <Chipaca> facubatista: 'snapcraft remote-build' :-)
[14:09] <Chipaca> facubatista: although right now you could just promote edge to beta
[14:10] <Chipaca> i've just built 0.3.0 from github master
[14:10] <facubatista> the remote-build is currently working
[14:11] <facubatista> Chipaca, let's HO?
[14:11] <Chipaca> facubatista: in 5?
[14:11] <facubatista> deal
[16:21] <jam> Chipaca, facubatista : for 'Harness.begin_with_initial_hooks()'. Juju doesn't guarantee the order of firing hooks if you have more than 1 relation hook (I confirmed in the code that it iterates a map, which is not a stable ordering)
[16:21] <jam> for *testing* it seems it would be easier to write assertions if you had a stable ordering
[16:21] <jam> but I don't really want code written that assumes a stable ordering
[16:21] <jam> Chipaca, thoughts?
[16:21] <jam> should Harness emit events in a stable ordering to make testing easier, or intentionally unstable to avoid code that assumes the order
[16:22] <facubatista> even firing in random order in the testing harness will not make that clear
[16:22] <facubatista> if it passes, people may assume it's ordered, even if we trigger them at random
[16:23] <Chipaca> jam: let them be ordered or however is easiest to implement in python for the harness, but if you have more than one relation hook issue a warning from _with_hooks?
[16:24] <jam> Chipaca, but it isn't wrong to have a relation to DB and a peer relation
[16:25] <jam> Juju just doesn't guarantee whether peer-relation-created or db-relation-created will be fired first
[16:25] <Chipaca> jam: the warning would just be about the order of events
[16:25] <jam> Chipaca, so it is easiest in the Harness to just iterate a map, which will also be 'unordered'
[16:26] <Chipaca> jam: in python maps aren't unordered though, since 3.6
[16:26] <Chipaca> jam: ask bthomas :-)
[16:26] <jam> Chipaca, I wonder if that introduces faults vs the old mechanism to avoid poisoned data
[16:26] <bthomas> :-) yep that bit me
[16:26] <jam> Chipaca, django used to have a security bug where the Query parameters were put into a dict
[16:27] <jam> and you could reverse engineer the dict ordering to make it collide.
[16:27] <jam> I guess if the hash index is still random at startup the iteration order can be stable but you can't force collisions on the hash table
[16:28] <facubatista> Chipaca, I did all the releases, and improved the text here: https://github.com/canonical/charmcraft/pull/101
[16:28] <mup> PR charmcraft#101: Release 0.3.0 <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/101>
[16:28]  * facubatista -> lunch
[17:02]  * facubatista is back
[17:07] <Chipaca> facubatista: 👋
[17:08] <Chipaca> facubatista: can you look at https://github.com/chipaca/ops-lib-k8s/pull/2/files and tell me if the _path thing is clear and readable, or if I should add an explanatory comment, or change the approach entirely?
[17:08] <mup> PR chipaca/ops-lib-k8s#2: lots of small tweaks and cleanup <Created by chipaca> <https://github.com/chipaca/ops-lib-k8s/pull/2>
[17:08] <facubatista> will do
[17:10] <mup> PR operator#364 opened: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364>
[17:35] <jam> facubatista, Chipaca : I'm definitely way past EOD, but ^^ is up. I'm happy to bikeshed on the name of the functiona
[17:35] <jam> and if we look at that test and say "no we really should give a stable order" then we can fix it
[17:35] <jam> but it does what I wanted.
[17:36] <facubatista> jam, awesome, thanks
[17:39] <jesseleo> Hello facubatista I'm still running into the error of adding a resource to my test harness
[17:39] <jesseleo> facubatista https://paste.ubuntu.com/p/MJd3cDKfxG/
[17:40] <Chipaca> jesseleo: what version of ops are you using?
[17:41] <Chipaca> jesseleo: because the version with add_resource was added in #359 which has not been released yet
[17:41] <mup> PR #359: ops/testing.py: Harness.add_resource <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/359>
[17:41] <Chipaca> jesseleo: so unless you're runing with master, that error is expected
[17:43] <jesseleo> yeah I have this in my requirements git+https://github.com/canonical/operator.git@master
[17:43] <Chipaca> jesseleo: to answer the 'what version' question, just add "raise Exception(ops.__version__)" to the top of yor test method
[17:44] <Chipaca> it should give you something like 0.7.0+8.g<hex>
[17:45] <Chipaca> to be more precise, master is 0.7.0+6g169794c right now
[17:48] <Chipaca> jesseleo: what I imagine might be happening is that your test environment has a different ops version and you need to update/upgrade/refresh it
[17:49] <Chipaca> thus my suggestion
[17:49] <jesseleo> oh yes I see I did have ops installed at the system level and wasn't activating my virtual env Chipaca facubatista
[17:49] <jesseleo> everything looks good now
[17:49] <jesseleo> thanks for being so responsive
[17:50] <Chipaca> jesseleo: glad we got it working!
[17:51]  * Chipaca EODs
[17:51] <Chipaca> 👋
[17:54] <facubatista> jesseleo, as a general rule, I don't ever never do "sudo pip install", as at some point always confuse things
[20:23]  * facubatista eods