[00:10] <bdx> ybaumy: https://paste.ubuntu.com/26480828/
[00:11] <bdx> ybaumy: ^ super new and untested, but its working for me http://paste.ubuntu.com/26480831/
[00:12] <bdx> 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] <bdx> but you must be on juju > 2.3.1
[00:12] <bdx> >=
[10:05] <ybaumy> bdx: which versions do i have to specify for kibana top and filebeat when running the kubernetes elasticsearch charm bundle
[16:42] <kwmonroe> 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] <kwmonroe> 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] <rick_h> kwmonroe: hmm, not publicly. I mean it's just an ACL "does the user have permission to do this"
[16:52] <kwmonroe> ack
[16:56] <cory_fu> 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] <kwmonroe> cool
[16:57] <cory_fu> kwmonroe: Oh, except that charm-push is part of the go code and not charm-tools
[16:57] <kwmonroe> doh
[16:57] <kwmonroe> same with charm release?
[16:57] <cory_fu> kwmonroe: Yep
[16:58] <cory_fu> Still shouldn't be too hard to do: https://github.com/juju/charm
[16:58] <cory_fu> Just need to do it in go
[16:59] <kwmonroe> heh, thx, i was mostly lost trying to find the repo.  who in the world would have thought ./juju/charm?  bonkers.
[17:00] <rick_h> cory_fu: kwmonroe yea, https://github.com/juju/charmstore-client  I think is the cli bits
[17:00] <cory_fu> kwmonroe: I'm not certain that's the right repo
[17:00] <rick_h> cory_fu: kwmonroe charm is the definition of a "charm" in the juju model vs the cli
[17:00] <cory_fu> rick_h: Ah, that's it.  Thanks!
[17:00] <kwmonroe> oh mylanta
[17:01] <sfeole> 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] <kwmonroe> looky at rick_h!  https://github.com/juju/charmstore-client/issues/143 streets ahead my man.
[17:09] <cory_fu> kwmonroe: Sorry for the chatter on that issue.  I misunderstood what you were saying
[17:10] <kwmonroe> lol
[17:22] <admcleod> sfeole: cory_fu good question
[17:22] <admcleod> *prod*
[17:26] <sfeole> tvansteenburgh, ^^
[17:29] <tvansteenburgh> sfeole: yes we are still maintaining it
[17:29] <sfeole> tvansteenburgh, cool thx
[17:30] <admcleod> \o/
[17:30] <petevg> 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] <kwmonroe> sup petevg
[17:31] <petevg> Namely, if I am referencing a local charm, what are my options for setting the series?
[17:31] <petevg> The charm lives in /home/<user>/charms/xenial/<the charm>
[17:31] <petevg> And the default series for the bundle is set to xenial
[17:31] <petevg> And the default series for the model is set to xenial.
[17:31] <petevg> But the charm is multi-series, and deploys the trusty version.
[17:32] <petevg> Do you know of any other flags that I can set to make it be xenial/
[17:32] <petevg> ?
[17:33] <rick_h> 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] <rick_h> 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] <kwmonroe> 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 <the charm>/metadata.yaml list trusty first?
[17:34] <kwmonroe> (under the series: key in metadata.yaml)
[17:38] <petevg> 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] <rick_h> petevg: right, so the bundle selection at the application level should override
[17:38] <petevg> 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] <rick_h> petevg: I'm not 100% sure on the bundle override itself.
[17:39] <kwmonroe> yeah ^^ me neither on *local* charms
[17:39] <rick_h> 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] <petevg> kwmonroe, rich_h: cool. We'll edit the charms for now, and I'll dig into it more later. Thank you!
[17:40] <kwmonroe> yeah petevg, do whatever you need to make xenail first feel right.
[17:40] <kwmonroe> 'cause that's right
[17:40] <petevg> 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] <kwmonroe> 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] <kwmonroe> or else
[17:46] <petevg> kwmonroe: I was going to fix the charms. But I guess fixing juju would be better. One bug it is, then :-)
[17:47] <kwmonroe> 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] <kwmonroe> i'll stop jumping back-and-forth over this fence now and leave you with "do what feels right".
[17:50] <cory_fu> 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] <sfeole> cory_fu, hey,  my ? is around this bug: https://github.com/juju/python-libjuju/issues/201
[17:51] <sfeole> 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] <sfeole> cory_fu, i believe the error I get is "Model not found"
[17:52] <sfeole> i'm thinking it may have something to do with my formatting
[17:52] <sfeole> of course i ripped everything down, so i can't give you the exact error at the moment
[17:56] <cory_fu> 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] <sfeole> cory_fu, 1 sec , i'll get the code
[18:00] <sfeole> cory_fu, https://pastebin.ubuntu.com/26484964/
[18:00] <sfeole> cory_fu, code and output
[18:00] <sfeole> admcleod, ^^
[18:08] <cory_fu> sfeole: Hrm.  I think that doc string is wrong.  Let me see if I can figure out what it should be
[18:08] <sfeole> cory_fu, thanks!
[18:22] <cory_fu> 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] <sfeole> cory_fu, no worries
[18:23] <cory_fu> 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] <cory_fu> 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] <cory_fu> sfeole: ^
[18:24] <sfeole> 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] <sfeole> cory_fu, i found this: https://github.com/juju/python-libjuju/blob/master/juju/model.py#L1108
[18:25] <cory_fu> 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] <sfeole> ahh
[18:25] <sfeole> cory_fu, ok ok
[18:25] <sfeole> cory_fu, at the minimum i'll file a bug
[18:25] <sfeole> cory_fu, thanks for your help
[18:30] <cory_fu> sfeole: np
[18:30] <cory_fu> I commented on that existing issue as well