[08:19] <mthaddon> Chipaca: yep, have added an approving review overnight (had deliberately held off til then to avoid confusion about whether it's ready to land before you guys have had a chance to review it)
[08:19] <Chipaca> mthaddon: 👍
[09:04] <bthomas> Chipaca: could you recommend some well made operator charm, so I can check that there is nothing wrong with my juju/microk8s setup ?
[09:06] <Chipaca> hmm
[09:06] <bthomas> :)
[09:07] <Chipaca> looking for one that's public and doesn't need a whole lot of other stuff around it
[09:08] <bthomas> 👍
[09:08] <Chipaca> bthomas: https://code.launchpad.net/~mattermost-charmers/charm-k8s-mattermost/+git/charm-k8s-mattermost
[09:09] <bthomas> Thanks Chipaca : will give it a shot
[09:09] <Chipaca> bthomas: requires a custom image, instructions in the README
[09:09] <bthomas> will read
[10:11] <bthomas> The mattermost charm uses https://code.launchpad.net/~stub/interface-pgsql/+git/operator as a submodule . And the interface-pgsql uses opslib as a submodule. In the opslib/pgsql sub-directory of the interface-pgsql there is a link to ".." which creates a cyclic inode structure.
[10:12] <bthomas> Even though I am able to clone the mattermost charm using my launchpad credentials cloning it recursively fails
[10:12] <bthomas> Even submodule update fails.
[10:24] <Chipaca> bthomas: pgsql uses opslib as a submodule?
[10:24] <Chipaca> not sure i understand what that means
[10:25] <Chipaca> i guess i could check out that git repo again
[10:27] <bthomas> Chipaca: interface-pgsql has a pgsql/opslib subdirectory in that subdirectory there is a link to ".."
[10:32] <Chipaca> bthomas: I don't see that
[10:33] <Chipaca> bthomas: maybe you updated the mod beyond what the charm specifies?
[10:34] <bthomas> When I tried to build the mattermost charm, even though it built the charm it gave an error saying pgsql was not found. Upon digging further I found that it used a git submodule. There is no mention of this in the readme.
[10:34] <bthomas> So I am not sure if it is ok to use the built mattermost charm without fixing the pgsql issue.
[10:35] <Chipaca> bthomas: how did you get the submodule?
[10:35] <bthomas> Chipaca: even if I do git clone git+ssh://balbir-thomas@git.launchpad.net/~stub/interface-pgsql/+git/operator interface-pgsql I can see the link
[10:36] <Chipaca> bthomas: right, but the charm doesn't say 'grab the dev tip'
[10:38] <Chipaca> bthomas: or does it/
[10:39] <bthomas> Chipaca: Not sure. But the standard way to pull git submodules fails with mattermost charm. For example if I do "git clone --recursive git+ssh://balbir-thomas@git.launchpad.net/charm-k8s-mattermost". Tis fails to clone submodules.
[10:40] <bthomas> Building mattermost charm without submodule produces an error, even though charm gets built.
[10:40] <Chipaca> bthomas: did you try cloning with the https url?
[10:40] <Chipaca> bthomas: it's possible you're missing the git-in-launchpad recommended git config; the .gitmodules file depends on that
[10:41] <bthomas> Chipaca: Just did "git clone --recursive https://balbir-thomas@git.launchpad.net/charm-k8s-mattermost" with same result. I was not aware of git-in-launchpad.
[10:42]  * bthomas googling git-in-launchpad
[10:42] <Chipaca> bthomas: https://help.launchpad.net/Code/Git
[10:42] <bthomas> Thanks Chipaca : will read
[10:42] <Chipaca> bthomas: the 'configuring git' section
[11:07] <bthomas> Chipaca: you were right. It was the git config. Thanks.
[11:07] <Chipaca> bthomas: \o/
[11:34] <gnuoy> Is it expected that when I try and push a charmcraft built charm to the charmstore it'll fail with "ERROR open mycharm.charm/bundle.yaml: not a directory" ?
[12:03] <mthaddon> Chipaca: do you think you'll have time to review https://code.launchpad.net/~axino/charm-k8s-gunicorn/+git/charm-k8s-gunicorn/+merge/389554 soon? Junien has another MP that he's working on that depends on that but want to make sure there's not too much rebasing needed
[12:22] <Chipaca> gnuoy: pushing it using the 'charm' tool? yes that won't work (unpack to a directory and push that)
[12:23] <gnuoy> ack, thanks
[12:24] <Chipaca> gnuoy: 'charmcraft upload' pushes to staging using the new APIs, if that's what you want though
[12:24] <Chipaca> and that one does take the .charm (and not a directory)
[12:24] <gnuoy> That is not what I want, but good to know, thanks.
[12:26] <Chipaca> mthaddon: i've still got one from deej to review, and then one from justin, and then that one
[12:27] <mthaddon> Chipaca: could i ask for this one to go above deej's? It's a day older, and there's another MP that depends on it, whereas deej's doesn't have another one depending on it
[12:27] <Chipaca> mthaddon: i'll swap it with that one then
[12:27] <mthaddon> perfect, thx
[13:34] <justinclark> bthomas, did you get Mattermost running? I quickly tried deploying yesterday based on the README and it failed for me.
[13:34] <justinclark> https://git.launchpad.net/~mattermost-charmers/charm-k8s-mattermost/tree/README.md
[13:35] <bthomas> justinclark: Yes mattermost was running. It was idle because i did not provide it a database connection. But it was not my purpose to use it. I just wanted to check if it can be deployed and the container runs.
[13:37] <justinclark> Ah okay. Thanks bthomas. It was probably the database for me too but got sucked into learning about cross model relations rather than going further with mattermost.
[13:55] <Chipaca> justinclark: where was the charm you wanted reviewed?
[13:55] <justinclark> https://github.com/justinmclark/grafana-charm-base/blob/master/src/charm.py
[13:55] <justinclark> Thanks Chipaca!
[13:57] <justinclark> Just FYI, jam suggested a change yesterday in an issue I opened. That is still WIP. Here's the issue: https://github.com/canonical/operator/issues/392
[14:02] <justinclark> Pushed some other changes I made last night Chipaca. The charm deploys to microk8s just fine by itself, but it is quite uninteresting without relating a data-source for the dashboards. That still needs to be tested
[14:03] <Chipaca> :)
[14:03] <Chipaca> ok
[14:03] <Chipaca> justinclark: you're using 'charmcraft build'?
[14:03] <justinclark> Yes.
[14:03] <Chipaca> justinclark: ok. You should probably embrace it more then :)
[14:04] <Chipaca> justinclark: right now you're getting ops via a git submodule
[14:04] <Chipaca> justinclark: instead of requirements.txt i mean
[14:04] <Chipaca> justinclark: and the 'fixpath' hack is not needed
[14:08] <justinclark> Chipaca: ah yes that needs to be a more prominent TODO. I used an out of date example when first starting and just didn't bother changing it as testing was working as expected.
[14:09] <Chipaca> justinclark: the 'configured' and 'started' storedstate things were red flags but they're not used at all so that's alright (just drop them)
[14:09] <Chipaca> justinclark: you're using f-strings which don't work on python 3.5 (which you'll get in xenial) so you might want to drop those too
[14:10] <Chipaca> justinclark: and you're setting state around a pod.set_spec which _i think_ (but am waiting to hear back from juju people) doesn't make sense
[14:11] <Chipaca> because statuses are immediate but set_spec is not
[14:11] <Chipaca> IIRC at least :)
[14:11] <Chipaca> jam: if you're around already, maybe you can answer that? (haven't heard back from #juju)
[14:11] <jam> morning Chipaca. set_spec is not immediate, it doesn't happen until the hook exits
[14:11] <jam> (in 2.8)
[14:12] <Chipaca> jam: right, that one i know
[14:12] <Chipaca> jam: but setting status is immediate, right?
[14:12] <jam> Chipaca: status = Blah is immediate, yes
[14:12] <Chipaca> so, yeah, that pattern is broken
[14:12] <jam> so you can show progress during an operation
[14:12] <Chipaca> this one: https://github.com/justinmclark/grafana-charm-base/blob/master/src/charm.py#L350
[14:13] <Chipaca> jam: right but using it show progress for something you're scheduling to happen later won't dtrt
[14:13] <Chipaca> in their defense, set_spec() does _sound_ immediate
[14:13] <jam> Chipaca: correct. except that Juju filters Active status for the case of 'the pod hasn't actually started yet', and overrides it until the application pod has finished starting.
[14:13] <Chipaca> maybe we should've called it set_spec_sometime_in_the_future_at_your_leisure_please_no_rush
[14:14] <Chipaca> jam: oh that's sneaky
[14:14] <jam> Chipaca: relation-set sounds immediate, too
[14:14] <jam> Chipaca: this is a case where, Mark found out that 'leader-set' was immediate, which breaks the 'transactionality' that all other relation-get/relation-set code has.
[14:15] <jam> So we went on a hunt for other things that violated that
[14:15] <jam> and found pod-spec-set.
[14:15] <jam> So we pushed for it to be changed
[14:15] <jam> but having worked with charmers for much longer
[14:15] <jam> I don't feel like pod-spec-set is an interaction *with other charms* it is an interaction with the charm and its application
[14:16] <jam> so I no longer feel it should be transactional
[14:16] <jam> (we don't put a transaction around 'systemctl start foo'
[14:16] <jam> however, we do need to deal with how it is currently, and not how it might theoretically work
[14:16] <jam> Also, the new work gets rid of pod-spec-set for charms running as sidecars
[14:17] <Chipaca> yep
[14:19] <Chipaca> jam: does the 'pod hasn't actually started yet' override thing mean that the code i linked to would currently dtrt w/2.8?
[14:22] <jam> Chipaca: I don't think it would stay in the "maintenance with 'setting pod spec'" but otherwise yes
[14:22] <jam> (eg, it uses Juju's 'pod not started yet' message, though I don't know the exact words)
[14:22] <Chipaca> k
[14:29]  * justinclark thanks Chipaca and jam for feedback :)
[14:31]  * justinclark pushes python 3.5 under the rug and blows things up
[14:31] <Chipaca> :)
[15:00] <Chipaca> justinclark: one silly thing I'd also do in your charm is make the log.error call for missing fields mention exactly what was missing, instead of everything that's required
[15:07] <justinclark> Chipaca: will do. Can you elaborate on the 'fixpath hack'?
[15:08] <justinclark> I'm not sure what that hack is.
[15:08] <Chipaca> justinclark: your charm.py does 'import fixpath'
[15:08] <Chipaca> justinclark: fixpath.py just adds lib to sys.path
[15:08] <Chipaca> justinclark: this was needed before charmcraft took on the job of setting up the environment for the charm
[15:09] <Chipaca> justinclark: it's a hack, which is why you need to tell pyflake to ignore it
[15:13] <justinclark> I see. Thanks.
[19:13] <Chipaca> EOWing here
[19:13] <Chipaca> bye all! see you tuesday
[19:41] <jam> have a great weekend ChanServ
[19:41] <jam> dang, gone already :)