[00:50] vinodhini: what's the status of this PR? the bug associated with it has been ,arked fix committed but the PR itself is still open https://github.com/juju/juju/pull/9027 [00:51] i shd close this wallyworld [00:51] done. [00:51] ok, ty [01:29] kelvinliu_: left me know if comments make sense [01:37] babbageclunk: did you see there's a state.go conflict that's been flagged? [01:37] wallyworld: ooh, no - must be new. Fixing now [01:46] wallyworld, yup, looking now, thx [01:46] wallyworld: You where saying you weren't keen on cloudContainer storing a reference to State, is that right? [01:48] yeah [01:48] ack [01:54] wallyworld, i m thinking if it's possible that charms have only crd but no containers [01:55] kelvinliu_: oh right, that's possible [01:55] that breaks the pod->unit model [01:55] we'd need to figure out how to map that betweem k8s and juju [01:57] i guess for now we can keep the EnsureCustomResourcDefinition method in the broker interface [01:57] wallyworld, yup, [02:43] wallyworld, just renamed the method and did some cleanup, would you take a look again? [02:43] sure [02:55] kelvinliu_: lgtm with a couple of small fixes [02:56] wallyworld, thanks [02:56] wallyworld: cud u plz take a look at PR - https://github.com/juju/juju/pull/9080 [02:57] will do after i finished xtian's [02:57] sure. [03:17] wallyworld: we don't expose a global key for cloud container (we currently use unit global key when storing cloudContainer in the cc doc). Storing the status for the cloud container we'll either need to expose one or have it overwrite the unit status (i.e. use the unit global key) [03:18] we can't overwrite [03:18] we'll need a cloudContainerGlobalKey [03:18] oh true duh. Ok can do [03:18] maybe cc# prefix [03:18] inctead of u# [03:19] or [03:19] as we do with elsewhere, add a suffix to the unit global key [03:19] we append #charm for the unit global key to distingish from agent [03:20] or visa versa [03:20] so append #container or something [03:20] ack, that's doable [03:51] https://github.com/juju/testing/pull/140 anyone [03:54] * anastasiamac looking [03:57] thumper: lgtm'ed (hoping that depenedcy reving is all good too)... [03:58] babbageclunk: sorry about delay, got caught in other things, there's a few questions there. i have a meeting now, maybe discuss after if you are not EOD? [03:59] or first thing tomorrow [03:59] wallyworld: no worries, you've got lots of other stuff happening - I'll have a look at the questions anyway. ping me when you're out of the meeting. [03:59] ok [04:00] vinodhini: i have a meeting now but i see tim looked at your pr [04:03] wallyworld: the caas unit provisioner, via updateStateUnits, uses an UpdateUnitOperation to set the status info, which in turn uses statusSetOps to set the status info bits, it feels like it should just use setStatus there (to handle history); am I missing something? [04:04] wallyworld: just had lunch. i think tim reviewed it. [04:04] its ok. [04:06] veebers: i'll look after meeting [04:06] ack [04:07] veebers: but unit update op thing which currently sets status on agent etc does do history [04:08] wallyworld: ah right, in Done [04:08] yup, that's it [04:08] wallyworld: sorry, my bad for not reading properly [04:08] nw [04:09] I might need to go to that Derek Zoolander center [04:48] wallyworld: when you have a quick moment could you eyeball this, see if I'm on the right path: https://github.com/juju/juju/pull/9081 [04:58] veebers: looking [04:58] thanks! [05:02] veebers: left comment - just one main issue, hopefully it's clear [05:02] wallyworld: ack thanks, will hit it [05:03] unit status will ultimately be set from the charm via hook commands [05:03] what we get from k8s will be stored as container status [05:17] anyone... https://github.com/juju/utils/pull/303 [12:39] stickupkid: as a follow up to my patch against juju/txn, this is the one that brings it into juju 2.3: https://github.com/juju/juju/pull/9083 can you take a look at it? [12:40] sure can :) [12:43] jam: LGTM [12:45] stickupkid: I realize I needed 1 more quick change to juju/txn, the printing of PruneOptions is ugly because uint64 defaults to printing in Hex, which isn't very nice [12:45] stickupkid: http://github.com/juju/txn/pull/44 [12:46] ah, yeah, I've been bitten by that before :| [12:46] jam: done [12:46] ah. yet one more, just a moment. Forgot the printing was in juju/txn. needs a small debugging tweak [12:52] stickupkid: can you look at http://github.com/juju/txn/pull/44 again ? I changed the type and added the logging [12:54] jam: approved [17:51] magicaltrout are you still having issues as mentioned on discourse on Friday? === marosg_ is now known as marosg === Dmitrii-Sh_ is now known as Dmitrii-Sh === yo61_ is now known as yo61 === gurmble is now known as grumble [23:27] veebers: where do we store the charms themselves used for log rotation? [23:28] veebers: actually if you have a few minutes it would be helpful [23:29] thumper: that's an interesteing question coz looks like some of our test charms have no hooks diretcory [23:29] thumper: or have one which is empty [23:29] anastasiamac: some of them for sure [23:29] thumper: hence we r seeing the 'invalid charm" error that hml documented [23:30] thumper: we have restrictred our definition of what is a valid charm recently... hence, the error now [23:32] * thumper nods [23:32] thumper: k wallyworld says he will look into this [23:33] the charms are in the acceptence tests dir [23:33] found the line I need to change [23:33] I now need to relearn how to run the tests locally [23:33] thumper: not so simp[le, the python generates the charms. we have it under control [23:33] wallyworld: I'm looking at the log file rotation one [23:34] thumper: sgtm, we are covering somne too, we will mark the ones we are doing [23:37] it seems lilke the README in the tree could do with some love [23:37] it talks about environments.yaml