[01:47] this is really odd, I have deploy 3 ubuntu units and 2 agents are in a failed state cause they aren't leader? === frankban|afk is now known as frankban [15:19] does anyone know why the default series for beats core is trusty? is it known not to work in xenial? https://api.jujucharms.com/charmstore/v5/beats-core/archive/bundle.yaml [15:32] probably because the charm is old, and hasn't been updated since [15:32] its still on rev #1 [15:33] neat [15:33] there is a bug here [15:34] xarses_: ok, thanks, so there is no reason that it "shouldn't" work on xenial, since all of the specific charms support xenial [15:34] there are two beats-core modules from containers [15:34] ah yes [15:34] I've notices that [15:34] and different individual charms reference different beats-core [15:35] I seems to include packetbeat and the other does not [15:35] @rick_h: because I don't know who else to ping, there "beats core" and the second cant be opened, it goes to the first [15:35] https://jujucharms.com/u/containers/ [15:36] from https://jujucharms.com/filebeat/7 juju deploy ~containers/bundle/beats-core [15:36] from https://jujucharms.com/u/containers/packetbeat/5 juju deploy cs:bundle/beats-core [15:37] tychicus: as to 'should work with xenial' you should inspect each subordinate charm in the bundle, if they have xenial releases then you can likely do all xenial, in some cases one might be old still so you might just deploy with the one old one [15:38] xarses_: /me is confused. Is this in a search on jujucharms.com? [15:39] I'm looking at the listing of the containers user [15:39] there are two results for "beats core" [15:39] ok, /me looks at that [15:39] and one result points to the other [15:40] xarses_: oooh, hah [15:40] xarses_: there's a bunch of doubles in there [15:41] oh, I didn't even notice [15:41] yea, fishy [15:41] o/ [15:44] xarses_: k, filed a bug will see what's up. [15:44] aight, thanks [15:45] one more question on bundles, I don't completely understand the syntax for relations, but I am working on getting elastic stack set up to do some monitoring [15:45] https://gist.github.com/roll4life/3017292adec8098a256cf37b645d9212 [15:46] neat, the openstack-dashboard ones? [15:47] I want to do log monitoring for all of my openstack hosts, i figured I would start with dashboard because it is easy [15:47] tychicus: the best thing to do is to be explicit and do something like this: https://pastebin.canonical.com/198904/ [15:47] tychicus: which is "add a relation, from application:endpoint to application:endpoint [15:49] rick_h, my ubuntu one account does not have access to that pastebin [15:49] tychicus: doh sorry [15:49] http://paste.ubuntu.com/25580465/ [15:52] rick_h: I am not entirely sure that I understand [15:53] the example given in the packetbeat charm is as follows [15:53] juju deploy cs:bundle/beats-core [15:53] juju deploy ubuntu [15:53] juju add-relation filebeat:beats-host ubuntu [15:53] juju add-relation topbeat:beats-host ubuntu [15:53] juju add-relation packetbeat:beats-host ubuntu [15:54] morning, are there any hacks to change the controllers detected IP address? [15:55] cause I need to put my controller on a floating IP and its currently on an internal ip in an openstack cluster [15:55] tychicus: yea, so that's a short hand for letting juju finding the right endpoint on the other end [15:55] so in the context defining these relationships in a bundle what would the second "application:endpoint" [15:56] tychicus: that could also be written juju add-relation filebeat:beats-host ubuntu:juju-info [15:56] tychicus: check out the relation info in the charm details page on the right: https://jujucharms.com/filebeat [15:57] tychicus: it's basically saying that the beats-host will wire up to anything that has juju-info and juju-info is the one generic endpoint all charms have [15:57] tychicus: so you can leave it off and juju figures it out, but I prefer to be explicit for this very reason [15:57] ah ok [15:58] magicaltrout: ... so there's all the cached controller files of users, the list of mongodb addresses for HA and such internally, the addresses of agents... [15:58] magicaltrout: I'm not sure there's a simple update this thing to do. might have to try the juju list for that tbh sorry [15:58] fair enough no probs [16:01] rick_h: so in my case the correct way to define the relationships is: [16:01] relations: [16:01] - - "kibana:rest" [16:01] - "elasticsearch:client" [16:01] - - "filebeat:elasticsearch" [16:01] - "elasticsearch:client" [16:01] - - "topbeat:elasticsearch" [16:01] - "elasticsearch:client" [16:01] - - "packetbeat:elasticsearch" [16:01] - "elasticsearch:client" [16:01] - - "filebeat:beats-host" [16:01] - "openstack-dashboard:juju-info" [16:01] - - "topbeat:beats-host" [16:01] - "openstack-dashboard:juju-info" [16:02] *updated gist* https://gist.github.com/roll4life/64fcb01ddc674d6c6dab45eb2b446300 [16:08] hey rick_h so last night I caught an odd ball in juju edge channel, just deploying 3 ubuntu instances and 2 of the complained about not being leader! [16:21] stormmore: huh...I didn't know the ubuntu charm supported any leadership ideas [16:21] stormmore: oh, I wonder if you're hitting that bug I saw someone talking about [16:22] stormmore: does it look like https://bugs.launchpad.net/juju/+bug/1706340 ? [16:22] Bug #1706340: [2.2.2] Failed unit agents: "leadership-tracker" manifold worker returned unexpected error: leadership failure: lease manager stopped

[16:22] tychicus: looks right-ish [16:28] rick_h: thanks, I'll try it and report back === frankban is now known as frankban|afk [16:32] rick_h: relation ["filebeat:beats-host" "openstack-dashboard:juju-info"] refers to application "openstack-dashboard" not defined in this bundle [16:32] sounds like you can only define relationships in a bundle for resources that are deployed by the bundle [16:37] rick_h: I don't think that is related although I am aware of that one [16:37] rick_h: this is one that talks about not being able to setup relationships due to not being leader [16:38] rick_h: first time I saw it was with swift so I put it down to that, but then I saw it happen to simple base ubuntu image that I didn't know how leader tracking either! so I dropped from edge to candidate juju and issue disappeared [16:57] tychicus: or juju won't be able to relate two services if juju isn't aware of the service. Did you deploy openstack-dashboard with Juju? [16:57] catbus: yes [16:57] It looks like the limitation is with how bundles work [16:58] agreed. Any reason why openstack services and beat-core bundle can't be combined? [16:58] since openstack-dashboard is not being deployed in the bundle I specified, I can't make the association [16:59] I guess it's the same reason that you can use the --to flag in conjunction with bundles [17:00] or specify in the bundle [17:00] to: [17:00] - lxd:2 [17:01] since machine 2 is not defined in the bundle, the bundle can't be sure that machine 2 exists, and won't spin up a new lxd container on that machine [17:02] maybe I could specify something with the machines: directive [17:15] tychicus: no, bundles can't effect what's already in a model. Otherwise the bundles would not be reusable because they'd have to have the model setup in a specific way to work [17:16] tychicus: in this way, bundles are meant to be a reusable-sharable definition and if there's specific things your need for your infra then it's best to script via cli, the juju library, etc [17:17] rick_h: got it, totally makes sense [17:44] rich_h: whats up with the maintainers of elasticsearch? [17:44] the charm is so broken [17:44] ever since that team took it over [17:44] I'm filing bugs, no response [17:44] I honestly feel that charm needs very active maintainership [17:45] I had put a lot of effort into fixing up bits and pieces to get it to work [17:45] now this team has taken over, won't accept my changes (the ones that fix the things that are broken) [17:47] ^ an honest to god piss off [17:47] bdx: sorry, I'm not sure. I've not seen anything since the email thread which seemed all good. [17:47] yeah [17:47] its cool [17:47] I just don't know how that happened [17:48] I'm maintaining my own fork [17:48] but its just a piss off that they took it over and its sitting there all broken [17:48] and no one is active enough to give my fix a look over in a weeks time [17:48] bdx: yea that's no good. /me goes to look for the bug tracker/homepage of the charm [17:48] rick_h: thx [17:50] bdx: can you reply to tom's feedback here? https://bugs.launchpad.net/elasticsearch-charm/+bug/1714393 [17:50] Bug #1714393: ERROR! lookup plugin (dns) not found [17:50] bdx: did you setup the pull request there on that one or do you mean some other PR? [17:51] rick_h: I'll find the pr omp, I'm more or less just bummed that the new maintainers aren't so active :( [17:52] bdx: understand, I just want to get ducks in a row and such looking at it [17:52] * rick_h does the whole dance of it's a bunch of folks doing a lot of different charms that are just people and might need prodding and such [17:54] the fact that they moved the code/development of the charm to launchpad git/launchpad is sad enough [17:54] yeah [17:54] I know [17:54] grrrr [17:54] bdx: well it's how that team operates. It's our internal folks [17:54] I see [17:55] bdx: at least it's git LP vs bzr LP :) [17:55] i know ... its equally as bad I feel [17:55] bdx: but yea, most of the folks on that team are internal folks at canonical with long long histories of managing all the things through LP [17:55] got it [17:55] I feel like they are isolating that charm and its development [17:56] it need the opposite [17:56] it needs more eyes, and more hands and feet [17:57] it needs a ton of work/help right now, including an entire rewrite [17:59] its just harder to get to on launchpad/git+lp [22:32] o/ [22:33] having an issue with ssh keys today [22:34] ive got the pub key of interest onto the server into the /root/.ssh directory, but its still telling me permission denied (public key) which doesnt make any sense to me. Any thoughts? I already checked config ont he distant server, and it says that publickey is set [22:35] the oddest thing is they key is already in the authorized_key file