[00:53] How would I log from a k8s charm using the operator framework? (So that the logs show up in the pod logs e.g kubectl -n test-k8s logs -f test-charm-operator-0) [00:55] Is that something debugf in ops/main.py will handle (function definition is currently just 'pass') [01:02] Ah scratch that, looks like print() does show up in logs - a separate issue meant that chunk of code wasn't getting hit :) [02:10] Here is a relatively boring PR for someone: https://github.com/juju/juju/pull/11124 [02:11] lucidone: oh, I don't know if we have any way to write into the pod logs [02:11] wallyworld, kelvinliu: do you know? [02:11] lucidone: we have a juju-log command that has things show up in the juju debug-log [02:11] but I don't know if there is a specific one for the pod log [02:11] you can also use kubectl log [02:11] wallyworld: from the charm? [02:11] not really [02:12] kubectl is for outside the cluster [02:12] wallyworld: do you think that we should have juju-log commands for k8s models go into the pod log? [02:12] I think just writing to stdout does the right thing. [02:12] they do go to pod log [02:13] the juju logs to go both the k8s log and the juju log [02:15] didn't find a juju-log helper method, but you can do this https://github.com/canonical/operator/blob/dd2a0d4537ff9ef2f19354a3fd7a9598e4b4c076/ops/model.py#L605 [02:30] lucidone: For debug-log you can use charmhelpers.core.hookenv.log from https://pypi.org/project/charmhelpers/, works fine with operator. [02:30] In case it hasn't been reported elsewhere, https://discourse.jujucharms.com is down from here. [02:45] seems to be back now [02:46] last job!!!! [02:47] whoot [02:48] i have run them all seperate wallyworld like we discussed to avoid the wait [02:49] tlm: i'm still seeing red dots? [02:49] yeah that was the job from this morning [02:49] if you click through you can see the latests ones [02:50] no way to re run something in jenkins and have latest result trickle up [02:50] ah, didn't realise that [02:50] but [02:50] 2.7.1 is released [02:50] I think [02:51] tlm: snap store thinks so! [02:51] i'll check simplestreams also [02:51] party time [02:51] and we should check the ppa manually too [02:51] using apt query blah [02:51] ok i'll jump on one of my ubuntu boxes [02:53] tlm: seem to be missing released simple streams http://streams.canonical.com/juju/tools/streams/v1/ [02:53] metadata is in proposed but not released [02:54] maybe there's one more job still to run [02:55] it's all green when I check [02:56] maybe it takes a few minutes to wash through [02:56] needs to have a job run on jerff [02:56] ah that guy. It passed [02:57] https://jenkins.juju.canonical.com/job/release-juju-request-streams-update/120/ === degville_ is now known as degville [16:05] manadart: so i created the initial mocking for apiserver/spaces test https://github.com/juju/juju/pull/11088/ your comment https://github.com/juju/juju/pull/11088#discussion_r367868986 I could not 100% realize. I cannot remove all of my changes from StubNetwork, because it needs to implement Backing so I just left it there. Which can be fixed [16:05] later when we move more and more tests from stubs to gomock [16:15] nammn_de: I think we could wrap the StubNetwork with with empty stubs for those methods, and remove them. They won't be called from the old tests. [16:16] Remove them from StubNetwork that is. [16:18] manadart: how would you do that? My initial idea would be to just remove all of the code I added and just add those 2 stub methods : [16:18] AllEndpointBindings AllMachines without any logic and just return [16:18] nammn_de: Yes. [16:22] manadart: the other "problem: i've encountered was: because we already have a test lying in spaces_test package I could either: put the new test based on macks in a newfolder or let it be in spaces for now, I put it in spaces for now [16:24] nammn_de: In the spaces package is OK. As long as it is suffixed with _test.go, it will only be built for tests. We do this in other places. [16:24] spaces_mock_test.go would follow the convention. [16:26] That's the mock. The tests can stay in spaces_test and import the mock. [16:30] manadart: what i found out from looking at the other packages is the following: mocks are under ../mocks/ and follow the naming of _mock.go and the test itself is under _test.go, but as we have both (stub and mock tests) I need to choose a new name. This would lead to spaces_mock_test.go, right? [16:31] and later when we have moved all from spaces_test, spaces_mock_test will be spaces_test