[01:25] stokachu - i know its late, i discovered this and submit a patch https://github.com/conjure-up/spells/pull/23 LMK if i broke the spell or anything... I'm not super familiar with what the ExposeResult method does. [02:06] lazyPower: o/ [02:06] \o [02:06] lazyPower: trying to work through deis and helm [02:06] looking at your pr now [02:06] ahhhhhhh :D [02:07] that makes me excite [02:07] i volunteer to pilot your spells [02:07] :D [02:07] lazyPower: i need a good name for it though [02:08] ive got 2 spells named Canonical Kubernetes and Kubernetes Core [02:08] stokachu - why not just use the software name? conjure-up deis [02:08] ah i like that too [02:08] sold [02:08] * lazyPower hands stokachu a nicely wrapped deis with a bow [02:08] that'll be 59.99 [02:08] lol [02:15] lazyPower: small comment on the PR [02:15] ack, taking a look [02:15] exposeResult just prints to the summary screen at the end of conjure-up [02:15] actually, is there a way i can test a spell locally? [02:15] disclaimer, in true lazy fashion, i have not read the docs [02:15] lazyPower: yea if you want to clone the spells github [02:16] and just do conjure-up -d path/to/spell [02:16] or cd into the spell dir and do conjure-up -d . [02:16] aahhh ok [02:16] thanks for the tip [02:16] np [02:16] i'l give it a run before i resub [02:16] cool man [02:18] lazyPower: so with deis we've been trying to avoid installing binaries on the users host system [02:18] it's not a hard rule, but one other option we thought of was deploy an ubuntu charm [02:18] and installing deis/helm on that [02:18] or does it really make more sense for those things to be on the users system locally? [02:18] that seems expensive [02:19] a unit in cloud $X for just 1 bin [02:19] are they just binaries? [02:19] i'll hvae to take another look [02:19] * stokachu hasn't looked to deep in them yet [02:19] but i thinkt hats the case [02:19] if they are just like go compiled binaries i think that should just be fine to put locally [02:19] like we do with the kubectl script [02:20] yeah [02:20] that ^ [02:20] its just like kubectl [02:20] cool ill do that then [02:21] i got the paas itch [02:21] hopefully it'll make a comeback [02:48] stokachu - you're in good company, and the deis stack is pretty nice. [03:13] stokachu oh hey, have you seen the new debug action on the kubernetes charm? [03:14] debugging-info ++ === med_ is now known as Guest67717 === frankban|afk is now known as frankban === tinwood is now known as tinwood_holiday [10:30] Good morning, could anyone check the following http://paste.ubuntu.com/23637511/ and let me know if their shell gets also frozen? Not sure whether it's a bug or my setup. [12:08] how can i install juju-core of 1.25.5 as 1.25.6 is having issue on trusty? [12:41] narindergupta, Try this, could work -> `apt-get install «pkg»=«version»` [12:43] deanman, no unfortunately it does not exist. I tried all combination. So i ended up download using wget and use dpkg -i but now need to upload 1.25.5 tools only. so figuring it out juju bootstrap command to upload old version of tool. [12:43] deanman, do you have that handy? [12:45] narindergupta, there is a way to explicitly state the tools you need to upload during bootstrap. [12:46] `juju bootstrap --agent-version` https://jujucharms.com/docs/1.25/commands#sync-tools. Is that what you want ? [12:47] or maybe this `--upload-tools (= false)` is more pertinent? [12:48] deanman, thanks i think thats what i was looking for [12:53] narindergupta: you probably don't need --upload-tools, jsut give the --no-auto-upgrade on bootstrap with the 1.25.5 client [12:54] mgz, ok will try that thanks [12:55] also, what's your issue with .6? tls version? [12:59] mgz, correct thats the issue [12:59] mgz, i wrote this issue but status is not won't fix [13:00] mgz, also with maas 2.1 and juju 2.x i am finding it uses lxdbr0 which is private network for lxd so somehow all of my deployments with current codes are failing. [13:01] i have stable with juju 1.25.6 and maas 1.9.x which fails due to tls issue [13:01] and maas 2.1 with juju 2.0 failed because ips used in lxd machines are from lxdbr0 [14:26] can I manually specify an LXD image to bootstrap Juju with? [14:26] *local only LXD image [14:34] or do I have to use simplestreams? === spammy is now known as Guest81153 === Guest81153 is now known as spammy === frankban is now known as frankban|afk [17:21] bootstrapping into a manual provider, what's the ideal way to setup the lxd bridge on the machines so that they'll bridge out to the physical network? [17:22] ideally there would be (and maybe already exists) a way to specify which interface on the machine I want lxdbr0 to bridge to (no NAT), and a pool of IP addresses from which new units would pick from [17:23] this was all easy to do with MAAS as the provider, but i cannot use it for this currently [18:11] Good morning everyone [21:32] tvansteenburgh: You still around to take a look at my BT PR? https://github.com/juju-solutions/bundletester/pull/80 [21:53] I need a help on this one [21:53] Is there a way to get the num-units deployed/added in my charms code? [21:54] Either juju deploy --n or juju add-unit -n [21:54] I want to dynamically fetch the number of units added in my charm code [21:54] How can I get that info? [21:57] sf: Your charm will have a peer relation to itself, and you can count the number of units on the peer relation with relation-list [22:05] @cory_fu, thanks. How do I go it programmatically in python. charm/hooksenv.py does not have relation-list function [22:05] @cory_fu, thanks. How do I get it programmatically in python. charm/hooksenv.py does not have relation-list function [22:07] sf: hookenv.related_units(rel_id) [22:09] @cory_fu. Thanks [22:09] sf: np! [23:28] @cory_fu. it works but it doesn't include itself. say you have 3 units, the peer relation returns only 2 [23:29] sf: That's true. It only counts the number of peers, so if you want the total, you have to add 1 for yourself [23:34] cory_fu: still around? [23:34] tvansteenburgh: Yep [23:38] cory_fu: do you need a release of this bundletester patch? [23:39] tvansteenburgh: It would help with my debugging, yes. [23:40] cory_fu: done [23:40] Thanks! [23:41] cory_fu: np, going afk, text me if you need another one [23:41] tvansteenburgh: Much obliged!