[00:10] ybaumy: https://paste.ubuntu.com/26480828/ [00:11] ybaumy: ^ super new and untested, but its working for me http://paste.ubuntu.com/26480831/ [00:12] ybaumy: you can modify the install_sources config for both of the elasticsearch and kibana charms to get them on 6.x if needed too [00:12] but you must be on juju > 2.3.1 [00:12] >= === frankban|afk is now known as frankban [10:05] bdx: which versions do i have to specify for kibana top and filebeat when running the kubernetes elasticsearch charm bundle === Spads_ is now known as Spads === Spads_ is now known as Spads [16:42] rick_h: do you know if the charmstore tracks who pushed a specific charm rev? for things like telegraf, owned by ~telegraf-charmers, is there any data that could point to the actual user? [16:46] cory_fu: did we ever hatch a plan for preventing 'charm push' from pushing a layer to the store? like, if -f ./layer.yaml && ! -f ./copyright.layer-basic; exit 1? [16:51] kwmonroe: hmm, not publicly. I mean it's just an ACL "does the user have permission to do this" [16:52] ack [16:56] kwmonroe: There's not a specific plan, but the thing you would want to check for is .build.manifest. It should be easy enough to add a warning and require --force or something if that file isn't present [16:57] cool [16:57] kwmonroe: Oh, except that charm-push is part of the go code and not charm-tools [16:57] doh [16:57] same with charm release? [16:57] kwmonroe: Yep [16:58] Still shouldn't be too hard to do: https://github.com/juju/charm [16:58] Just need to do it in go [16:59] heh, thx, i was mostly lost trying to find the repo. who in the world would have thought ./juju/charm? bonkers. [17:00] cory_fu: kwmonroe yea, https://github.com/juju/charmstore-client I think is the cli bits [17:00] kwmonroe: I'm not certain that's the right repo [17:00] cory_fu: kwmonroe charm is the definition of a "charm" in the juju model vs the cli [17:00] rick_h: Ah, that's it. Thanks! [17:00] oh mylanta [17:01] cory_fu, ping, hey I noticed there is not many recent commits to libjuju, is that being worked on? had some questions on it if so [17:01] looky at rick_h! https://github.com/juju/charmstore-client/issues/143 streets ahead my man. [17:09] kwmonroe: Sorry for the chatter on that issue. I misunderstood what you were saying [17:10] lol [17:22] sfeole: cory_fu good question [17:22] *prod* [17:26] tvansteenburgh, ^^ [17:29] sfeole: yes we are still maintaining it [17:29] tvansteenburgh, cool thx [17:30] \o/ [17:30] Hey, kwmonroe, I remember you teaching me things about setting the series of a charm in a bundle. I've got a question for you, when you have a moment: [17:30] sup petevg [17:31] Namely, if I am referencing a local charm, what are my options for setting the series? [17:31] The charm lives in /home//charms/xenial/ [17:31] And the default series for the bundle is set to xenial [17:31] And the default series for the model is set to xenial. [17:31] But the charm is multi-series, and deploys the trusty version. [17:32] Do you know of any other flags that I can set to make it be xenial/ [17:32] ? [17:33] petevg: what's the preferred series in the charm metadata.yaml? Juju respects the preference there using order. The first in the list is preferred, then the next, etc. [17:33] petevg: the other thing is what cloud is it, as if there's no xenial image available (maas, etc) it might fallback to trusty? [17:33] ha! i was just having a convo about local charms in bundles recently... petevg, what rick_h said is the first easy place to start... does /metadata.yaml list trusty first? [17:34] (under the series: key in metadata.yaml) [17:38] rich_h: trusty is listed first in the charms. We were going to try editing the charm to list xenial first, but that felt wrong :-) [17:38] petevg: right, so the bundle selection at the application level should override [17:38] rich_h, kwmonroe: this is an openstack deploy on MaaS, but I think that the charms all have xenial versions for that environment. [17:39] petevg: I'm not 100% sure on the bundle override itself. [17:39] yeah ^^ me neither on *local* charms [17:39] I guess since it's a local charm...hmmm...maybe there's some bug in how that's getting pulled. Honestly though they should have xenial first imo :) [17:39] kwmonroe, rich_h: cool. We'll edit the charms for now, and I'll dig into it more later. Thank you! [17:40] yeah petevg, do whatever you need to make xenail first feel right. [17:40] 'cause that's right [17:40] I guess I can file lots of bugs against the charms in question, and then contribute a fix. ... which will be outdated as soon as bionic launches :-) [17:41] whoa whoa whoa there chief. what's all this "lots of bugs" talk? if a local charm isn't honoring the overall bundle series, that's one bug. do not open more than one. [17:41] or else [17:46] kwmonroe: I was going to fix the charms. But I guess fixing juju would be better. One bug it is, then :-) [17:47] heh, right on petevg. the issue then would become whether or not a bundle.yaml series should override the charm metadata series. and i'm not so sure it should, so now that you're all-in on one bug, maybe you should open lots of bugs to make your charms xenial first. [17:48] i'll stop jumping back-and-forth over this fence now and leave you with "do what feels right". [17:50] sfeole: Sorry, I missed your ping somehow. It's still being maintained, though there hasn't been as much need for changes to it recently. What was your question about it? [17:51] cory_fu, hey, my ? is around this bug: https://github.com/juju/python-libjuju/issues/201 [17:51] cory_fu, i can't seem to get that to work, if i try the example in my comment: add_machine(spec="ssh:user@10.10.0.3") [17:52] cory_fu, i believe the error I get is "Model not found" [17:52] i'm thinking it may have something to do with my formatting [17:52] of course i ripped everything down, so i can't give you the exact error at the moment [17:56] sfeole: Hrm. I'm not sure. I haven't done much with manual provisioning personally. "Model not found" doesn't sound like it being an issue with the spec format, though [17:57] cory_fu, 1 sec , i'll get the code [18:00] cory_fu, https://pastebin.ubuntu.com/26484964/ [18:00] cory_fu, code and output [18:00] admcleod, ^^ === frankban is now known as frankban|afk [18:08] sfeole: Hrm. I think that doc string is wrong. Let me see if I can figure out what it should be [18:08] cory_fu, thanks! [18:22] sfeole: Bad news, I'm afraid. It looks like much of the heavy lifting for adding a manually provisioned machine is done in the Juju client but is not reimplemented in libjuju. [18:23] cory_fu, no worries [18:23] sfeole: The logic that would need to be added can be found here: https://github.com/juju/juju/blob/develop/environs/manual/sshprovisioner/provisioner.go#L20-L70 [18:24] Essentially, ensure an ubuntu user, add all of the local ssh keys to that user's authorized_keys, and then fetch and execute a provisioning script provided by the controller [18:24] sfeole: ^ [18:24] cory_fu, what about situations where I want to deploy a bundle in libjuju and the machines already exist? I know that when using the command line, you need to add a paramter --use-existing=True , or something along those lines.. I believe that's relatively new.. I'm assuming libjuju doesn't handle that yet though? [18:25] cory_fu, i found this: https://github.com/juju/python-libjuju/blob/master/juju/model.py#L1108 [18:25] sfeole: Correct. Re-using existing machines from a bundle is a new feature that isn't supported yet. That one, at least, should be an easy change. [18:25] ahh [18:25] cory_fu, ok ok [18:25] cory_fu, at the minimum i'll file a bug [18:25] cory_fu, thanks for your help [18:30] sfeole: np [18:30] I commented on that existing issue as well === Spads__ is now known as Spads