Chipaca | gooooooooooooooooooooooooooooooooooood morning! | 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 | ||
Chipaca | brb, dog's whining about something | 08:35 |
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:02 |
jam | Chipaca, I can feel the power.... | 09:03 |
Chipaca | jam: that heady feeling of being able to kickban people | 10:45 |
facubatista | ¡Muy buenos días a todos! | 11:03 |
Chipaca | facubatista: 👋! | 12:11 |
facubatista | hola Chipaca! | 12:11 |
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:15 |
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:16 |
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:17 |
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' | 12:18 |
Chipaca | bthomas: 👋 | 13:34 |
bthomas | thanks Chipaca | 13:36 |
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:01 |
Chipaca | facubatista: 'snapcraft remote' should probably be in there :-| | 14:02 |
Chipaca | remote-build* | 14:02 |
facubatista | Chipaca, let me see | 14:05 |
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:06 |
Chipaca | facubatista: although right now you could just promote edge to beta | 14:09 |
Chipaca | i've just built 0.3.0 from github master | 14:10 |
facubatista | the remote-build is currently working | 14:10 |
facubatista | Chipaca, let's HO? | 14:11 |
Chipaca | facubatista: in 5? | 14:11 |
facubatista | deal | 14:11 |
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:21 |
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:22 |
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:23 |
jam | Chipaca, but it isn't wrong to have a relation to DB and a peer relation | 16:24 |
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:25 |
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:26 |
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:27 |
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 | 16:28 | |
* facubatista is back | 17:02 | |
Chipaca | facubatista: 👋 | 17:07 |
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:08 |
mup | PR operator#364 opened: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364> | 17:10 |
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:35 |
facubatista | jam, awesome, thanks | 17:36 |
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:39 |
Chipaca | jesseleo: what version of ops are you using? | 17:40 |
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:41 |
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:43 |
Chipaca | it should give you something like 0.7.0+8.g<hex> | 17:44 |
Chipaca | to be more precise, master is 0.7.0+6g169794c right now | 17:45 |
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:48 |
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:49 |
Chipaca | jesseleo: glad we got it working! | 17:50 |
* Chipaca EODs | 17:51 | |
Chipaca | 👋 | 17:51 |
facubatista | jesseleo, as a general rule, I don't ever never do "sudo pip install", as at some point always confuse things | 17:54 |
* facubatista eods | 20:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!