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