[00:01] babbageclunk: happy new year. skip standup today? it'll just be us [00:01] last week I did bugs, this week I do bugs [00:01] axw: happy new year to you too! [00:01] ha [00:01] yeah, I'm fine to skip - last week I did tramping [00:02] nice :) [00:02] today I'm doing upgrade testing [00:29] axw: wondering if you could comment on https://bugs.launchpad.net/juju/+bug/1738993 [00:29] Bug #1738993: ERROR creating hosted model: model already exists [00:29] I'm not sure where to start [00:29] it is vmware I think [00:29] okey dokey [00:29] thanks [00:29] babbageclunk: hey [00:30] babbageclunk: do you have some time to talk about audit logging? [00:50] thumper: oops, just saw this now. yes, I do if you're still free! [00:50] in 1:1? [00:56] babbageclunk: I'm about to chat to anastasiamac, after that? [00:57] thumper: yup yup [01:32] axw: good find on the region name dots [01:33] thanks [01:36] * thumper looks for babbageclunk [01:36] thumper: [01:36] oops hi [01:36] babbageclunk: 1:1 HO? [01:37] yup === frankban|afk is now known as frankban === tinwood_ is now known as tinwood [11:12] Hi Juju devs. I had to prune orphaned transactions of a subordinate charm. That seems to fixed the mongo db issues but now the charm is unresponsive with https://pastebin.ubuntu.com/26346175/ on its logs [11:12] the agent is in failing state [11:13] ani ideas how to get out of this situation [11:13] I do not mind redeploying the subordinate, but I do not wand to kill the principal charm === salmankhan1 is now known as salmankhan === frankban is now known as frankban|afk === rogpeppe1 is now known as rogpeppe [19:25] kjackal: you could try 'juju resolved --no-retry' [19:25] to get the unit out of the error state [19:26] thumper: the unit is not in error state, it is blocked and the agent failing [19:26] let me tryit [19:26] hmm.. [19:27] how did it get into this state? [19:27] https://pastebin.ubuntu.com/26348573/ [19:28] There was a corruption in mongodb. At that point all operations were failing, so I tried to pruneorhaned transactions [19:29] and this is where we are now [19:29] Do not want to redeploy the prometheus-gateway since it hosts all these other subordinates [19:30] If I could get rid of the failing subordinate it would have been great [19:34] thumper: could I go in the node and stop some of the running services so as to disable the failing agent? [20:03] kjackal: sorry, had a call [20:05] kjackal: I *think* we could fix it by editing a file on disk on that agent [20:05] effectively it seems that it is stuck in a loop, retrying, but not able to make progress due to the database not being in a state that matches the unit [20:05] the uniter on the machine has a FSM for working out what to do [20:06] I think we might be able to nudge that === agprado is now known as agprado|lunch === agprado|lunch is now known as agprado === rogpeppe2 is now known as rogpeppe === mwhudson_ is now known as mwhudson