[08:01] Issue operator#455 opened: JUJU_MODEL_NAME not initialized by harness [08:20] Issue operator#455 closed: JUJU_MODEL_NAME not initialized by harness [09:39] i'm not half asleep, *you're* half asleep [09:41] * bthomas wonders if Chipaca is talking in his sleep [09:43] bthomas: too little sleep is indeed the problem [09:43] Indeed. I recently read it can contribute to build of beta-amyloid plaques in the brain too. [09:44] ooh! are they blue plaques? [09:45] Don't know their color. But I have redshift installed on all my devices so when I try to read and fall asleep the blue light of devices does not disrupt my sleep cycle. [09:46] my wifi cuts out at 11pm, but i still didn't get to sleep until past 2 :-( [09:46] Oh no. I am surprised though since you have a healthier lifestyle than me, going for runs and all that. [09:47] heh, maybe i should've gone for a run yesterday [09:47] i was still sore from running saturday though 🙂 [09:48] Also latent stress can disrupt sleep. I learn't from a BBC documentary that sleep can be induced by a drop of body temperature. So having a hot shower before going to bed one gets sleep when body temperature drops. [09:49] showers wake me up though [09:49] anyway, it's not too bad [09:49] used to be i'd be weeks on end like this [09:49] now it's only once a week or two [09:50] so the running has helped [09:50] That sounds better. [09:57] Issue operator#456 opened: Test harness relations missing Juju managed data [10:04] Issue operator#457 opened: Test harness relations cannot be initialized with data [12:01] Issue operator#458 opened: a charm with an empty actions.yaml trips up the framework [13:54] Is there a specification or standard on what data *must/will* be provided for each event type. In particular relation_departed and relation_broken. I presume for the former it is at least unit name. Though the latter could be relation name it does not seem necessary. [14:04] i don't think there is, hence my suggestion to look at what juju does IRL [14:08] tests pass! woo. time for a break. [14:30] Not related to my changes but I am seeing "KeyError: 'google'" at "operator/test/test_infra.py", line 86, in test_pep257 on my system. Could be a pydocstyle version issue but "requirements-dev.txt" does not specify which minimal version of pydocstyle is required. If I switch from "google" to "pep257" convention then the test runs but fails because it detects many violations of D200, D204, D205, D400, D401 and D413. [14:31] * bthomas goes to make some coffee [14:41] If no one has any objection I would like to switch from google to PEP257 convention, add the violations to the current ignore list, create a issue to fix all PEP257 violations, and undertake to do so myself in a future PR. [14:42] Chipaca: ^ [15:21] yay! first remove relation test passed [15:35] Looks like now one is objecting to ^ :-). Changes made. Will be part of my PR. Too late now :-). [15:44] bthomas: -1 to switching docstyle conventions [15:48] Chipaca : hmm OK. I am not hung up on it. Any ideas why I am seen the error mentioned above. [15:49] bthomas: no 🙂 what changed at your end? [15:49] nothing changed. It is not related to my changes. I can stash them and still see the error. [15:51] Also I would +1 for PEP257 official standard. They violations are all silly and easy to fix but kind of enforce formatting consistency like linkbreaks and full stops etc. If you change you mind I can fix them after this PR. [15:53] bthomas: I might be misunderstanding, but if I am not, you're suggesting changing from a convention from 2011 (google's) to one from 2001 (pep257) [15:55] Chipaca: that I am not sure about the date. I tried the switch from `.google` to `.pep257` because I was getting a KeyError `.google`. I think this may be because of pydocstyle version. I think requirements-dev needs a minimal version for pydocstyle. [15:55] Can look into it once I get all my unit tests in place. [15:56] PEP257 seems to be stricter than google though. [15:56] bthomas: what version pydocstyle do you have? [15:56] bthomas: i'm not certain about those dates either [15:56] bthomas: but, we should discuss this when facu is around [15:56] not sneak it in while he's away :-D [15:57] certainly let's discuss it [15:57] but meanwhile let's unblock you [15:57] Ok, Got it. Will discuss with facu. My docstyle is version is 2.1.1 [15:57] * bthomas promises to be good and not sneaky :-) [15:57] bthomas: how? [15:57] bthomas: i have 5.1.1 here; how do you have 2.1.1? :) [15:57] Chipaca: I am not unblocked [15:57] opps meant blocked [15:58] no big deal. [15:58] So it is indeed version, issue. I will update. I used ubuntu package. [15:58] ahhh [15:58] also, aaah [15:58] did not realize tit was that old [15:58] I am on focal fosa 20.04 [15:58] i cannot comment on the age of tits [15:58] :-) [15:58] oops [15:58] NSFW [15:59] probably pretty old, as passerines are a very large family [15:59] he he [15:59] and speciation takes time [16:00] * bthomas rofl [16:04] Chipaca: Should we remove_relation_unit(self, relation_id: int, remote_unit_name: str) OR remove_relation_unit(self, relation_name: str, remote_unit_name: str) ? [16:04] Note first argument and type [16:06] It is all a question of if we expect client to retain relation id through their workflow. [16:06] s/through/through out/ [16:08] * bthomas tries to do a quick tea before standup [16:26] Current it is implemented as relation id for first argument [16:38] bthomas: sorry was in a meeting [16:39] answered in the standup now [16:41] agreed. leaving as is for now. [16:59] PR operator#459 opened: Treat empty actions.yaml as no actions.yaml [17:00] bthomas: ^ if you have a mo' [17:02] having a look. [17:05] done [17:06] bthomas: thanks 🙂 [17:06] the meat of the change is two lines, the rest of the diff is tests 🙂 [17:06] maybe i should've lead with that [17:06] anyway, thanks [17:11] saw that. [17:20] Chipaca: forgot to mention in standup, for the remove relation tests I need to do harness.begin() because the removing implementation in harness uses self._charm to emit events. Can I presume that a client in a test (or not ?) will not try to remove a relation or unit without doing harness.begin(). I can ofcourse defend against _charm is None but will not be able to emit events, at least as implemented now. [17:21] bthomas: emiting events should be guarded for _charm being None and events being disabled [17:21] got it thanks [17:21] bthomas: as in the 'if self._charm is None or not self._hooks_enabled' guards you'll see [17:21] indeed [17:22] that's what those are about 🙂 [18:10] PR operator#460 opened: Remove relation test [18:11] Chipaca: https://github.com/canonical/operator/pull/460 Just draft for now. Will sleep over it tonight, think it over again, self review tomorrow and create PR. [18:11] PR #460: Remove relation test [18:12] However if you have a need for a catharsis and can't find a punching bag, feel free to do get youre release :-) [18:13] * bthomas is tempted to call it a day for now [18:20] * bthomas EODs but is still around for a bit