[09:01] moin moin moin [09:01] Mornig Chipaca [09:01] bthomas: how're you doing? [09:03] Chipaca: I am good. I am reading through Operator Framework module in an effort to understand and put doc strings where they are missing. If I figure out things left as TODOs in hook docs I will update that also. You may get a question or to when I am utterly confused :). [09:03] ok :) [10:20] Chipaca: pushed a very rough first draft for charm.py (https://github.com/balbirthomas/operator/tree/improve-docs) . Starting on framework.py after a short break. No need to review now. Just a heads up in case you want to guide and steer my efforts in any particular direction. [10:21] ack [11:18] ¡Muy buenos días a todos! [11:19] morning facubatista [11:19] hola bthomas [11:19] facubatista: 👋❗ [11:28] hola Chipaca [11:33] @niemeyer, one drawback of moving the python dependencies out of requirements.txt to a charmcraft.yaml (with the rest of the config options) is about running tests... normally people would have a requirements-dev.txt with dependencies to run the tests (which would automatically include those in requirements.txt) [11:34] facubatista: How do we run tests when the setup is all being described inside charmcraft.yaml? [11:34] niemeyer, unless we provide a way to run the tests through charmcraft itself... like `charmcraft test` [11:35] but we need `charmcraft test` to be fast, it can't create a VM for every run [11:35] facubatista: Right.. without something like that, it means the environment you use to run tests, and the environment you use to build and ship, are completely different [11:35] facubatista: Snapcraft and Multipass already have logic to make that kind of thing fast [11:36] facubatista: Ask Sergio about how machines are reused for fast iteration.. I don't know where that is today, but we discussed and something was implemented back then [11:38] it would be nice if 'test' were just another stage [11:38] (and that you could tell charmcraft to just run that one) [11:39] that plus per-stage requirements and you're there [11:40] niemeyer, Chipaca, I opened this to track the ideas https://github.com/canonical/charmcraft/issues/160 [11:42] aye [11:43] even tox is too slow for some people [11:46] how is it 12:45 [11:50] Chipaca, are you preparing a fix for the flaky test about times checking? [11:51] facubatista: i forgot! i'll do that right after lunch [11:51] facubatista: sorry [11:51] Chipaca, ack [11:51] thanks [12:43] * Chipaca runs the test suite 999 times [13:27] Hello again! [13:28] Hi justinclark [13:28] justinclark: welcome back! [13:47] hola justinclark! [14:18] Chipaca: re "harness.charm._stored.foo = 42 should dtrt?" - can this work if I want to test what's in the __init__ function of my CharmBase subclass ? [14:19] axino: sorry, i don't follow :-/ [14:20] Chipaca: I have https://pastebin.canonical.com/p/9RjtYGsCXP/ and I want to test both cases of the "if" line 19 [14:21] Chipaca: I'm not sure I can rely exclusively on harness for this [14:23] axino: unless i'm missing something harness.charm._stored.reldata will be {} after just begin, right? [14:23] Chipaca: for the first ever hook run on a unit, yes. But for subsequent hooks, it could have another value (which is the whole point of StoredState() :) ) [14:24] ah no because _init_postgresql_relation is called from by __init_ [14:24] so .relation will be at least {'pg': {}} [14:24] reldata* [14:26] axino: i agree, i think the harness doesn't help you for this [14:26] axino: if you know how we could help, let me know :) [14:26] Chipaca: alright :) I think I basically have to patch StoredState and instanciate the class and test the value of _stored [14:27] Chipaca: I'll try things on my own for a bit - thanks [14:28] axino: doing .begin twice might work? [14:29] Chipaca: "RuntimeError: cannot call the begin method on the harness more than once" [14:29] :) [14:29] 1 sec [14:35] axino: aw, a second harness does not pick up the stored state from a previous one [15:29] * facubatista -> lunch [15:55] ok, i'll bbl [15:55] going for a run while the sun shines :-D [16:39] * facubatista begs for review: https://github.com/canonical/charmcraft/pull/163 [16:40] PR charmcraft#163: Two small details before integrating help messages to main [16:40] facubatista: having a look [16:48] done [18:04] * facubatista -> tennis [18:17] * Chipaca blames facubatista for https://github.com/cloudflare/cobaul [20:53] * facubatista is back [20:54] Chipaca, what did I do? [21:27] jam, what is the proper name for the "human operator" in the Juju world? I mean, the person that executes juju commands to deploy and maintain the system... [21:29] facubatista, it used to be "operator". The best word that I've found to replace it is the Admin/Administrator [21:29] jam, administrator it is, thanks! [21:56] * facubatista eods