=== spammy is now known as Guest10278 === natefinch-afk is now known as natefinch === Guest10278 is now known as spammy [08:21] bdx, as far as i'm aware it works [08:21] bdx, are you having an issue with it? [09:04] Hello juju world [11:25] mornin #juju o/ [11:25] bdx: it doesn't 100% work as it doesn't get the info from the existing consul charm; I was working on a slight fork of the existing consul charm to be an agent charm, ie: local subordinate consul that doesn't run the gui but didn't get around to finishing / puyblishing it [11:26] icey - yeah, we really do need to upgrade that charm. thing is we dont have any consumers in ~containers anymore now that we've dropped the swarm work [11:26] lazyPower: I have a vault charm that is a consumer :) [11:26] and with swarms new self-contained bidniss shipping with docker. [11:26] well, would be if it related correctly :-P [11:26] heh heh [11:26] should be simple, its just ip:port [11:27] but lazyPower the consul docs suggest running a consul agent on EVERY machine and querying your local agent, rather than a remote agent... [11:27] basically no consul client has HA support where you can give it several IPs [11:27] :-/ [11:28] i mean, thats fine, it works either way [11:28] you can query remotely or query via the local proxy [11:28] it all goes to the same place [11:29] lazyPower: but querying remotely means I'm down if the node I'm talking to goes down since no HA love [11:29] thats a possibility, yes [11:29] at least querying locally means if my machine is down nothing is different ;-) [11:30] i guess? it'll buffer your writes [11:30] but not your reads [11:31] lazyPower: yeah; I decided to work towards the doc suggested version of local agent but never got to finish that work; making the vault charm I've got use a remote consul shouldn't be too bad, besides the fact that it (vault) will not let you configure multiple consuls to talk to [11:32] making a local agent should be mostly done. fork the charm, convert it into a sub and drop the UI bits, add the relation and the template logic and you're done right? [11:32] lazyPower: yeah [11:32] also i'm not 100% on it not buffing reads, it may give you a cache [11:32] OH [11:32] and add a relation [11:32] for the consul-agent [11:32] yep [11:32] otherwise, yeah it's all there [11:33] seems like that would be short sighted for them to not give you a minimal cache of the kv data [11:33] so i bet they do [11:33] but i dont recall having read that anywhere [12:18] lazyPower: the conjure up instructions for observable kubernetes doesn't seem to work for me [12:19] jcastro - ok, can you describe whats happening? [12:19] it seems like it's trying to install a package? [12:19] jorge@ivory:~$ conjure-up cs:~containers/observable-kubernetes [12:19] Reading package lists... [12:19] Building dependency tree... [12:19] Reading state information... [12:19] E: Unable to locate package cs:~containers [12:20] ah you missed bundle/ in the url [12:20] cs:~containers/bundle/observable-kubernetes [12:20] * lazyPower checks the readme [12:20] nope [12:20] same error [12:20] and I am following the readme [12:20] hmm i wonder if we missed some metadata on our last publish or something [12:20] stokachu - ping [12:22] jcastro - one thing that i know is a grey area is we dont have that path under CI, so we've lost visibility into if we break that route. it should 'just work' but we're also manually having to set metadata points so conjure knows where to look for the bundle [12:22] hmm, how do you guys feel like just all of us concentrating on a working bundle, updated revs across the board today? [12:22] and i think thats the core of the issue [12:22] jcastro - i'm eyeballs deep in this blog post, but i'm getting close to finishing. I think ~ 11/12 i'll be done. [12:22] ok [12:23] I guess I'll start my post but with the native bundle [12:34] jcastro: no cs: [12:34] just ~containers/observable-kubernetes [12:35] jcastro: oh i see a bug in the code, we check for cs: and not cs:~ [12:37] stokachu thanks for taking a look [12:37] np [12:49] lazyPower: ok so check this out, adding a # passes charm proof in the bundle [12:49] so I will document the bundle itself for constraints [12:50] and then by default not define any, so the primary use case should be pull, modidy, deploy, not deploy out of the store as-is. I'll update the readme and whatnot [12:50] and then do a PR [12:57] jcastro - ok, sounds good to me. I know that the target was intended to give machine constraints, but given the context of what we've found i think thats a better option [13:16] lazyPower: does `juju run --application kubernetes is-leader` usually take a long time? [13:16] a couple seconds at most [13:16] readme is out of date on that too, fixing [13:16] oh nm, cluster is not up yet [13:36] lazyPower: upgrade worked: Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.1", GitCommit:"fe4aa01af2e1ce3d464e11bc465237e38dbcff27", GitTreeState:"clean"} [13:36] jcastro - awesome. v1.3.3 is latest however. you did 1.3.1? [13:37] but i know we should be compliant. The only downside is what we've already discussed, the missing federation bits. [13:41] yeah I wanted to see how that worked [13:49] Pretty spiffy how it tears down and reconstructs in place right? === frankban is now known as frankban|afk === fginther` is now known as fginther === natefinch is now known as natefinch-afk