[00:46] <thumper> I finally worked out the watch incantation to watch functions with xenial and dash
[00:46] <thumper> watch -x bash -c <func>
[00:52] <thumper> anyone... https://github.com/juju/juju/pull/9007
[01:15] <thumper> babbageclunk: ping
[01:17] <babbageclunk> thumper: pong
[01:17] <thumper> 2m, witing email
[01:17] <babbageclunk> okies
[01:17] <thumper> babbageclunk: back
[01:17] <thumper> hangout?
[01:22]  * thumper sighs while trying to find the bug
[01:24] <babbageclunk> sorry
[01:24] <babbageclunk> thumper: hangout now?
[01:24] <thumper> yeah
[01:25] <thumper> babbageclunk: I'm in our 1:1 meet
[01:26] <babbageclunk> hang on, my computer got very busy deploying things
[01:26] <thumper> :)
[01:27] <thumper> and another https://github.com/juju/juju/pull/9008
[02:30] <anastasiamac> wallyworld: any chance u could PTAL https://github.com/juju/juju/pull/9009 (maas CC changes)
[02:30] <wallyworld> ok
[03:08] <veebers> wallyworld: FYI have put this up https://github.com/juju/charmstore/pull/820 once that lands I can update charmrepo.v3 and juju with the deps and propose
[03:10] <wallyworld> veebers: lgtm, :shipit: i think you do
[03:18] <veebers> wallyworld: do you know if the shipit process runs the tests too? the test run failed do to some internet connectivity issue.
[03:18] <veebers> not sure how to trigger a rebuild yet
[03:18] <wallyworld> i think it does
[03:20] <veebers> wallyworld: It's possible my shipit message is being ignored :-)
[03:21] <wallyworld> i'llcheck
[03:22] <wallyworld> you weren't patient enough
[03:22] <wallyworld> looks like it's working
[03:23] <wallyworld> veebers: internal/charmstore/resources_test.go:661: undefined: resource.TypeDocker
[03:23] <veebers> wallyworld: crap missed one, on it
[03:23] <wallyworld> best to run the tests locally
[03:24] <veebers> ah, I commited to the wrong branch, godeps bounced me around :-)
[04:04] <veebers> wallyworld: I had some issues running tests locally, but sorted now and should be landing soon. I'll cleanup with the others (charmrepo.v3 then juju) and once landed send an email out
[04:05] <wallyworld> gr8 ty
[04:14] <veebers> wallyworld: FYI https://github.com/juju/charmrepo/pull/142 (one more step after this one :-))
[04:15] <wallyworld> lgtm ty
[04:17] <veebers> ah, failed, it needs an extra dep due to new charmstore dep /me fixes
[04:29] <veebers> wallyworld: FYI I updated the juju/testing dep on charmrepo.v3 too
[04:29] <wallyworld> sgtm. is that the one with kelvin's change?
[04:31] <veebers> it's the latest one, using the old version it had made tests fail on my machine
[05:03] <veebers> wallyworld: and finally https://github.com/juju/juju/pull/9012
[05:04] <wallyworld> veebers: lgtm ty
[05:15] <veebers> wallyworld: fyi I just pushed a oneline dep change to include the swift dep coming from charmstore. Emailing now too
[05:15] <wallyworld> ty
[05:32] <babbageclunk> wallyworld: do you know about the go vet failure in k8s.go?
[05:32] <wallyworld> no?
[05:33] <babbageclunk> I refer the gentleman to my previous statement.
[05:33] <wallyworld> babbageclunk: you mean there's one in tip of develop?
[05:34] <wallyworld> i've run go vet today without error
[05:34] <babbageclunk> yup.
[05:34] <babbageclunk> Hmm - I just rebased to see if it was fixed and got the problem again.
[05:34] <wallyworld> babbageclunk: tim had an issue like this and clearing the pkg files fixed it
[05:34] <veebers> anastasiamac: \o/
[05:34] <anastasiamac> veebers: ?
[05:35] <babbageclunk> wallyworld: ok, I'll try that
[05:35] <veebers> anastasiamac: saw your PR come through for the test fix (hopefully)
[05:35] <wallyworld> babbageclunk: the landing bot should reject such things nowadays
[05:35] <anastasiamac> veebers: oh yes :)
[05:36] <anastasiamac> veebers: if this is it, there is another place that has similar setup... i think juju/juju/mongo
[05:38] <babbageclunk> wallyworld: yeah, that fixed it.
[05:38] <wallyworld> gr8. nfi what happens there
[05:43] <babbageclunk> wallyworld: weird though - the problem it was complaining about seems legit. It's saying the format string has %d but the arg is a resource.Quantity (which is a struct).
[05:45] <babbageclunk> wallyworld: eg on line 1495 of k8s.go
[05:46] <wallyworld> babbageclunk: yeah, i see what you mean
[05:46] <wallyworld> i might fix as a driveby
[05:52] <babbageclunk> And line 1498 was the other one.
[06:47] <icey> cross-posting from #maas - I have a machine in my MAAS that Juju cannot deploy to; when it requests a machine, I can see in the maas.log that a machine was requested but Juju reports "failed to acquire node: unexpected: ServerError: 404 Not Found (Not Found)" ; I'm not sure where to look next
[07:08] <anastasiamac> icey: what version of maas? juju?
[07:09] <icey> MAAS version: 2.4.0 (6981-g011e51b7a-0ubuntu1~18.04.1) ; juju  2.4.1
[07:09] <icey> I'm currently removing and re-adding the machine to maas
[07:09] <icey> as it reliably fails on the same machine
[07:33] <icey> very weird, re-added the machine to maas and it still shows a 404 when Juju asks for it
[07:35] <icey> logs from the juju controller: https://pastebin.ubuntu.com/p/2bZycx4N7s/
[07:36] <anastasiamac> icey: and nothing else from Juju? I assume that juju is saying 404 not maas, right?
[07:36] <anastasiamac> icey: is it possible to get TRACE level logging?
[07:36] <icey> anastasiamac looks like it
[07:36] <icey> anastasiamac I can happily re-bootstrap asll day long :-D
[07:36] <icey> s/asll/all
[07:37] <anastasiamac> ha :) m almost at eod so probably cannot help much... interesting that it's just that one machine... how is it differnt to other machines?
[07:38] <icey> anastasiamac it's not; quite literally 3x supermicro boxes, identical
[07:39] <icey> anastasiamac I can probably speed it up if I can target the machine directly; can I do machine name constraints?
[07:39] <icey> I suppose I can just add a tag
[07:39] <anastasiamac> icey: if maas machine has a tag, u can use constraints to call that tag
[07:40] <anastasiamac> +1
[07:40] <icey> WAIT; apparently this machine is missing the tag I wanted on it
[07:40] <icey> I wonder if that's it...
[07:40] <anastasiamac> icey: \o/ worth a try :D
[07:40] <icey> I try adding just this machine first to see if it's resolved before I deploy my whole bundle again :-P
[07:41] <anastasiamac> k
[07:45] <icey> well anastasiamac my stupid test works to allocate it; going to try my bundle again
[07:46] <anastasiamac> icey: that's good news tho :)
[07:48] <icey> wow nope, I suppose it's a problem with my bundle or constraint though, given that it can be deployed to with specific tag constraints on the ubuntu charm
[07:49] <icey> alternately, I forgot to configure my networking
[07:49] <anastasiamac> icey: m relieved it's not juju :) and it's k to use tags in the bundles too
[07:49] <icey> anastasiamac I am using tags :-D
[07:49] <icey> I just don't want to specify each machine explicitly given that they are the same types
[07:50] <anastasiamac> :)
[07:51] <anastasiamac> i wonder if u can specify a tag as a constraint in the application section...
[07:51] <icey> anastasiamac I'm specifying the application placement on machines
[07:51] <icey> the machines have tags
[07:51] <icey> in my bundle
[07:54] <anastasiamac> icey: k...
[07:55] <icey> anastasiamac I am beginning to suspect an issue with network spaces given that it seems to be the only difference
[07:55] <icey> I'm about to go spelunking in diffing the maas machine requests
[07:56] <anastasiamac> icey: niiice :) have fun! m about to eod, eow in fact :D
[07:56] <icey> anastasiamac I'm only about 6 hours behind you ;-) anjoy!
[07:56] <anastasiamac> o/
[07:57] <icey> dang, the network space requests seem to actually be the same, although in different orders
[07:57] <icey> well, I'll keep digging
[08:19] <icey> super weird; it deployed that machine last time through; but failed to deploy containers on a different machine (container already exists); but then this time around it's failing to deploy that node again
[08:19] <icey> :-/
[09:25] <icey> I think there's a new bug with containers on maas in juju with 18.04.1: https://pastebin.ubuntu.com/p/Gf3qkQ6SzS/
[10:19] <magicaltrout> random question folks on behalf of rmcd
[10:19] <magicaltrout> can you have a subordinate.. of a subordinate?
[10:33] <rick_h_> magicaltrout: ...I mean that's just a subordinate with a relationship to another one right?
[10:33] <rick_h_> And you can define that protocol...I've related subordinates, but not in subordinate contexts I guess.
[10:34] <rick_h_> magicaltrout: what's the use case? Why doesn't need to be a subordinate relationship?
[10:39] <rmcd> So basically...
[10:39] <magicaltrout> we're create our own version of the hadoop plugin
[10:40] <magicaltrout> that utilises the hadoop plugin :P
[10:40] <rmcd> I'm writing a charm for Druid which basically passes config files onto the separate Druid services. Right now, I'm working on implementing the HDFS backend for Druid, which requires me to be able to grab some XML files from Hadoop and place them into Druid.
[10:40] <magicaltrout> but when we relate hadoop to druid config it doesn't do anything
[10:41] <rmcd> So on the config charm, I'm trying to use a reactive handler that fires off when hadoop-plugin is connected, but both the config charm and the hadoop-plugin charms are subordinates.
[10:41] <rmcd> So if I connect my config charm to my other Druid charms, that works fine. But if I relate hadoop-plugin to druid-config, it has 0 scale because, I'm guessing, you can't install a second-order subordinate charm in that way.
[10:42] <rmcd> Because it'll try to install hadoop-plugin to druid-config, which doesn't have a server because it's on a container... if that makes sense.
[10:46] <magicaltrout> certainly from a design standpoint it seems like its fine to have a subordinate of a subordinate because for example if your subordinate had a java dependency you'd want to use the java charm to install java
[10:47] <magicaltrout> so maybe its just our hooks
[10:53] <rick_h_> Yea, I mean things like telegraf are a subordinate that I believe can relate to other subordinates.
[10:54] <rick_h_> But it feels like a thing where order of deploy and such might make it a bit odd to get right
[12:28] <magicaltrout> rick_h_: kwmonroe cory_fu rmcd https://discourse.jujucharms.com/t/a-subordinate-of-a-subordinate/121
[12:28] <magicaltrout> i stuck it on there
[12:28] <magicaltrout> if anyone has any good ideas
[12:28] <rick_h_> magicaltrout: awesome ty
[12:51] <jacekn> hello. Does anybody know if I missed something obvious? I can't figure out how to list or consume CMR offer: https://bugs.launchpad.net/juju/+bug/1785223
[12:51] <mup> Bug #1785223: "juju offers" ignores -m flag <juju:New> <https://launchpad.net/bugs/1785223>
[12:55] <mthaddon> rick_h_: ^ anyone around who could help with that?
[12:56] <rick_h_> mthaddon: in standup one sec.
[12:57] <rick_h_> jacekn: this is on a single controller?
[12:59] <jacekn> rick_h_: "juju offers" is yes. I added offer and tried to list it to get URL
[12:59] <jacekn> rick_h_: but need to consume from different location (did not get that far)
[12:59] <rick_h_> jacekn: k, let me finish this standup and I'll look harder
[13:02] <jacekn> thanks
[13:25] <maaudet> Would it be considered a bad practice to install a custom daemon on a machine that runs custom hooks/tools using the "juju-run" command for a single unit?
[13:25] <rick_h_> jacekn: does juju find-endpoints work for you?
[13:26] <rick_h_> jacekn: sorry find-offers
[13:27] <jacekn> trying. It started and now it's sitting there after "13:26:33 INFO  juju.api apiclient.go:597 connection established to "wss://..."
[13:27] <jacekn> rick_h_: yep it found it: prodstack-is  admin/prod-nagios.nagios  admin   monitors:monitors
[13:28] <rick_h_> jacekn: k, adding some notes to the bug, offers are controller-wise not model specific since they're made to users on the controller and those users don't need/have model level access
[13:28] <rick_h_> jacekn: but I honestly can't recall the difference in list-offers vs find-endpoints...
[13:28] <rick_h_> jacekn: maybe list-offers are YOUR offers you've made
[13:28] <rick_h_> jacekn: and this user hasn't made them as the offer came from the admin? I'm not sure
[13:28] <jacekn> well yes, that's what I wanted to see. I made an offer and I wanted to show it
[13:29] <rick_h_> jacekn: ok, will have to check with folks on what I'm missing on that but updated the bug and hopefully that helped unblock you for the moment.
[13:29] <jacekn> I run both "juju offer" and "juju offers" from the same user
[13:30] <jacekn> rick_h_: so honestly that does not actually unblock me that much. It confirms my offer is there but I can't see from the docs how to tell my other controller where to look for it. They are in different DCs even
[13:30] <jacekn> there must be a place where I give it IP address or hostname
[13:30] <rick_h_> jacekn: yes, you can use the consume command to specify the controller and url to the offer
[13:31] <rick_h_> jacekn: but note that there must be a valid matching user on both controllers
[13:32] <jacekn> rick_h_: which IP should I use? Any of my 3 node HA controllers?
[13:32] <rick_h_> jacekn: you should have the controller in the local cache and not need to refer to IPs? /me double checks
[13:32] <rick_h_> jacekn: per the help docs on consume: juju consume anothercontroller:owner/othermodel.mysql
[13:32] <jacekn> rick_h_: sorry I don't get it. What local cache? My consumer controller knows nothing abotu the offer I made
[13:33] <rick_h_> jacekn: your local juju client. You need to be able to see both controllers when you run juju controllers
[13:33] <jacekn> ah I see....
[13:33] <rick_h_> jacekn: if you can't you need to share/register/etc to get both controllers in your local list
[13:33] <jacekn> ok that's the missing part!
[13:33] <rick_h_> jacekn: <3
[15:01] <jacekn> rick_h_: any idea where to start troubleshooting this: https://pastebin.canonical.com/p/YbNg8W5bDg/
[15:01] <jacekn> "juju consume" worked, I added relation and no hooks are firing
[15:16] <jacekn> I suspect FW problems but logs are not very clera
[15:35] <jacekn> yes it was FWs, now getting INFO juju.worker runner.go:483 stopped "nagios:monitors nrpe:monitors", err: <nil>
[16:39] <nekobasu> roadmr: Thanks for the pointer! It was the DNS server setting in the juju controller that caused the problem.
[16:40] <roadmr> nekobasu: no problem, I literally did nothing :)
[17:39] <knobby> does adding a unit to a model cause a config.changed hook call?