| bdx | ybaumy: https://paste.ubuntu.com/26480828/ | 00:10 |
|---|---|---|
| bdx | ybaumy: ^ super new and untested, but its working for me http://paste.ubuntu.com/26480831/ | 00:11 |
| 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 | >= | 00:12 |
| === frankban|afk is now known as frankban | ||
| ybaumy | bdx: which versions do i have to specify for kibana top and filebeat when running the kubernetes elasticsearch charm bundle | 10:05 |
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| 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:42 |
| 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:46 |
| rick_h | kwmonroe: hmm, not publicly. I mean it's just an ACL "does the user have permission to do this" | 16:51 |
| kwmonroe | ack | 16:52 |
| 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:56 |
| 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:57 |
| 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:58 |
| kwmonroe | heh, thx, i was mostly lost trying to find the repo. who in the world would have thought ./juju/charm? bonkers. | 16:59 |
| 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:00 |
| 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:01 |
| cory_fu | kwmonroe: Sorry for the chatter on that issue. I misunderstood what you were saying | 17:09 |
| kwmonroe | lol | 17:10 |
| admcleod | sfeole: cory_fu good question | 17:22 |
| admcleod | *prod* | 17:22 |
| sfeole | tvansteenburgh, ^^ | 17:26 |
| tvansteenburgh | sfeole: yes we are still maintaining it | 17:29 |
| sfeole | tvansteenburgh, cool thx | 17:29 |
| 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:30 |
| 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:31 |
| petevg | Do you know of any other flags that I can set to make it be xenial/ | 17:32 |
| petevg | ? | 17:32 |
| 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:33 |
| kwmonroe | (under the series: key in metadata.yaml) | 17:34 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| petevg | kwmonroe: I was going to fix the charms. But I guess fixing juju would be better. One bug it is, then :-) | 17:46 |
| 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:47 |
| kwmonroe | i'll stop jumping back-and-forth over this fence now and leave you with "do what feels right". | 17:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:56 |
| sfeole | cory_fu, 1 sec , i'll get the code | 17:57 |
| sfeole | cory_fu, https://pastebin.ubuntu.com/26484964/ | 18:00 |
| sfeole | cory_fu, code and output | 18:00 |
| sfeole | admcleod, ^^ | 18:00 |
| === frankban is now known as frankban|afk | ||
| 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:08 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| cory_fu | sfeole: np | 18:30 |
| cory_fu | I commented on that existing issue as well | 18:30 |
| === Spads__ is now known as Spads | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!