[01:35] <thumper> https://github.com/juju/juju/pull/11095 for someone
[03:15] <thumper> and another, https://github.com/juju/juju/pull/11096
[03:20] <tlm> taking a look
[03:23] <thumper> tlm: happy to answer any questions here if it helps
[03:42] <tlm> thumper, first PR lgtm, second one looks good as far as code but don't have enough context around it for logic. Happy to approve first one if you want?
[10:34] <manadart> Forward merge - only 2 patches: https://github.com/juju/juju/pull/11098
[10:35] <flxfoo> Hi all
[10:36] <flxfoo> Quick question...
[10:36] <flxfoo> about permissions
[10:37] <flxfoo> through python-juju (script) If I connect with user credential and cert pem, is there restriction for that user to run even a simple "run('uname -a')" on a remote machine?
[10:47] <manadart> flxfoo: Only admin users can execute "juju run...".
[10:57] <flxfoo> manadart: ok thanks...
[10:58] <flxfoo> manadart: If I have an admin user, that should be fine right? (I want to have a script to do backup cron based or so)
[10:59] <manadart> flxfoo: Yes, I believe so.
[11:02] <flxfoo> manadart: many thanks
=== narindergupta is now known as narinderguptamac
[14:15] <nammn_de> achilleasa: in for a quick rev? https://github.com/juju/charm/pull/302
[14:32] <achilleasa> nammn_de: sure
[14:40] <nammn_de> achilleasa: good point! What do you think about fallback to "path" in case that happens?
[14:41] <achilleasa> nammn_de: why do we need abs path in the first place?
[14:43] <nammn_de> achilleasa: Last time I introduced the "path" as  this helps debugging in case something bad happens. We had some cases where fde or customers were confused that charm had not version output. Showing the path should help
[14:43] <nammn_de> at least was discussing that with rick_h as far as i can remember :D
[14:44] <nammn_de> but now debugging it myself I realized that some paths can be relative.
[14:44] <nammn_de> and I do think using absolute ones would help in those cases at least imo
[14:57] <achilleasa> nammn_de: I believe that you should return the error if you cannot figure out an abs path. It probably means that the thing you passed into filepath.Abs is garbage
[14:58] <nammn_de> achilleasa: hmm makes sense as well, was too conserative
[15:14] <achilleasa> nammn_de: approved
[15:14] <achilleasa> are you targeting 2.7 for these changes?
[15:14] <nammn_de> achilleasa: doesnt need to be, but I planned to do so
[15:14] <nammn_de> anything I need to look out for?
[15:24] <hml> achilleasa:  quick review pls?  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/364. :-)
[15:30] <hml> achilleasa: i’m tempted to move the restore-backup tests as well, though they need improvements.
[15:30] <achilleasa> hml: looking
[17:05] <nammn_de> achilleasa want to look at the corresponding 2.7 merge? https://github.com/juju/juju/pull/11104
[17:06] <nammn_de> *pr not merge
[17:08] <achilleasa> n
[17:08] <achilleasa> nammn_de: looking
=== _thumper_ is now known as thumper
[22:58] <lucidone> Hi, is it possible to offer an application (e.g mysql) as a CMR in a way that it can be consumed by a model on a separate network?
[23:00] <lucidone> Mainly wondering if it can be done through the machines public IP address instead of using a VPN
[23:04] <babbageclunk> lucidone: I *think* so - wallyworld will know for sure?
[23:20] <babbageclunk> thumper: forwarder metrics: https://github.com/juju/juju/pull/11109
[23:20] <wallyworld> lucidone: so long as the traffic is routable between machines... any consuming app has to be able to reach the offer, and the consuming controller needs to be able to reach the offering controller
[23:24] <lucidone> Right, in this case the traffic isn't routable as mysql offers itself using the private IP of the LXC container afaik. Should it be possible to expose mysql and then offer it using that exposed interface?
[23:26] <wallyworld> you don't expose an interface - juju expose opens any ports specified by the charm to 0.0.0.0
[23:27] <wallyworld> what we need here is a way to put into relation data the offered apps "public" ip address
[23:28] <wallyworld> and i don't think that's possible currently since that public ip addtess is obtained from the host machine's address
[23:29] <wallyworld> one way would be to use a charm which has charm config to allow the user to override the advertised ip
[23:31] <wallyworld> so instead of the charm using the ingress address info from the network-get hook command, it would use whatever the user has configured it to use
[23:31] <tlm> could also setup the lxd network to use real routable addresses. That way what it reports is not a NAT address?
[23:33] <lucidone> I saw this in the mysql charm too. So looks like it explicitly builds the connection string from the private address  https://github.com/juju-solutions/charm-mysql/blob/master/hooks/db-relation-joined#L51
[23:34] <wallyworld> ueah, and unit-get private-addres is way deprecated
[23:34] <wallyworld> the mysql charm is a bi orphaned
[23:34] <wallyworld> i think percona-cluster charm is more up to date
[23:36] <lucidone> Ah right, ideally we sort out the postgres charm anyway - so the charm specific stuff isn't a huge issue. Was just thinking there would be some juju magic that would make things work, but guess the solution here is to patch networks together with VPNs?
[23:37] <wallyworld> juju can't guess network rouability etc, so needs to be suitable configured, and that falls on the charm. so yeah, whatever works
[23:38] <wallyworld> postgresql charm is being sorted, but not sure of the time frame. soon i hope
[23:41] <lucidone> Sweet, cheers for that. Also side question about juju expose <app> .. Is it possible / are there plans to support opening up to specific IP/ranges instead of 0.0.0.0/0 ?
[23:41] <wallyworld> yes :-)
[23:41] <wallyworld> this cycle i think
[23:42] <wallyworld> cmr already suports that
[23:42] <lucidone> Sweet :D
[23:42] <wallyworld> but general charms not yet
[23:43] <wallyworld> juju set-firewall-rule is used to set a CIDR list for cmr offer firewall rules