=== CyberJacob is now known as CyberJacob|Away [01:43] lazyPower: so much more eloquent than me === cmagina_ is now known as cmagina === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [08:52] congrats dpb1! [13:02] stokachu, morning mate, got another question for you I'm afraid [13:47] can you specify the location of the environments.yaml file ? [13:48] something else besides ~/.juju/environments.yaml ? [13:50] rharper: you can by setting JUJU_HOME [13:51] but the directory structure will need to reflect that of whats in ~/.juju [13:55] stub: pingaling [13:58] lazyPower: excellent, thanks! [13:59] thanks jamespage! good to be on the team. :) [14:04] :) We're happy to have ya dpb1 [14:04] tvansteenburgh: any chance we could get a +1/merge on https://code.launchpad.net/~evarlast/charm-tools/warn-description-newlines/+merge/230899 ? [14:05] tvansteenburgh: jrwren ran into some fun chasing that down this week ^ [14:05] rick_h__: sure, i'll take a look [14:05] ty much kind sir [14:06] tvansteenburgh: pulled, merged, ran tests [14:06] LGTM [14:06] lazyPower: oh thanks, beat him to it! [14:06] I'm letting tim run point - but i gave it a +1 review :) [14:07] somebody convince me we shouldn't allow newlines in an option description [14:08] i can't do that, because newlines keep it readable in the yaml. Occasionally in the GUI when it gets smashed together its hard to read. so i'm +1 for newlines - but the linter appears to be checking for the presence of the pipe character for newlines. [14:09] tvansteenburgh: yea, it's a yaml parsing thing I think [14:09] jrwren: ^ [14:09] no, it's just checking for \n afaict [14:10] according to the bug, "we don't want newlines b/c `juju get` formats them badly" [14:10] tvansteenburgh: https://bugs.launchpad.net/juju-core/+bug/1292116 [14:10] Bug #1292116: juju get output is ugly (broken line wrapping and escape characters)

[14:10] ah you're right, line 0 only checks for \n [14:10] its not even looking for carraige return... [14:11] O_O I STILL +1 THIS [14:11] i think it's more appropriate to fix `juju get` [14:12] Part of the issue AFAICT is that yaml Marshal/Unmarshal is not round trippable for formatting. [14:12] marcoceppi, you have any opinion on this? [14:12] If you use | or > on input, in config.yaml, and then Unmarshal to yaml as juju get does, you do not get | or >, you get quotes and ugly newlines. [14:13] otp, brb [14:13] jrwren: my thinking was that `juju get` could clean up it's formatting by stripping newlines [14:14] s/it's/its/ [14:14] tvansteenburgh: i don't know the goals around juju get output. [14:15] tvansteenburgh: I suggest that yaml Unmarshal and them manipulating that output would be very error prone, especially to maintain valid yaml, if that is a goal. [14:15] tvansteenburgh: Good data out starts with good data in. This helps keep good data on input. [14:16] jwren: that's not the goal, we don't need to go back to yaml, just display the contents in an easy-to-read fashion [14:17] tvansteenburgh: Its not easy-to-read now. This change lets proof find places that it is not easy-to-read. [14:17] jwren: it *is* good data in though, it's perfectly valid yaml. i think imposing arbitrary restrictions on which yaml contructs can be used would lead to a suprising user experience [14:17] jwren: my point is that we could make it easy to read by fixing the way the data is displayed, not by imposing restrictions on the data itself [14:18] tvansteenburgh: Maybe surprising at first, and then not surprising. [14:18] jrwren: :) [14:19] tvansteenburgh: If that is the path you choose, that is fine. I find the current state unacceptable and I may submit merge requests for everything in charmstore to fix their text which is displayed poorly today. === hatch__ is now known as hatch [14:20] jrwren: why not just submit a patch to fix juju get? [14:20] tvansteenburgh: whats the tldr? [14:21] marcoceppi: https://code.launchpad.net/~evarlast/charm-tools/warn-description-newlines/+merge/230899 [14:21] tvansteenburgh: becasue I find it the wrong solution :) [14:22] jrwren: ok, then we disagree. i'll let marcoceppi be the deciding vote [14:22] tvansteenburgh: drop your opinion in the merge [14:22] jrwren: what does juju get look like with newlines? [14:22] does it show \n or what? [14:22] marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1292116 [14:23] Bug #1292116: juju get output is ugly (broken line wrapping and escape characters)

[14:23] yeah, this is a core issue [14:23] making YAML human readable is kind of it's point [14:23] some of these options are huge, like the openstack-origin, which include code examples, etc [14:24] marcoceppi: all of those can still work, just don't use | or > [14:24] marcoceppi: just wrap normally [14:24] jrwren: but that's the point of | > and it's multiline string [14:24] otherwise you have to start escaping ' and " [14:24] juju just isn't respecting the YAML spec [14:25] fwiw, if I can find where this is in core I might be able to patch it === scuttle|afk is now known as scuttlemonkey [14:25] it's either change 200 charms which are following YAML spec [14:25] or fix core [14:25] marcoceppi: ok. fwiw, neither pyyaml or goyaml currently round trip those correctly. [14:25] * marcoceppi reads the spec [14:28] hum, I mean, thanks for trying to tackle this jrwren, but this presents a huge task for ecosystem if it's indeed merged [14:29] marcoceppi: ok. gl with that bugfix. I think it will be challenging. [14:30] jrwren: yeah, I'll take a task to investigate this later tonight [14:30] * marcoceppi fears golang no more [14:30] * jrwren never fears golang, he just isn't very good with it... yet. [14:32] oh, well we're both in the same boat then ;) [14:34] marcoceppi: in what TZ are you? What time are you thinking? If I'm available, can I pair with you? [14:36] jrwren: I'm EDT, probably going to take a stab around 20:00, but might not get to it until Monday [14:36] want to take a stab at it monday for sure? [14:36] marcoceppi: sure. I am EDT also. Sounds like a plan. [14:37] jrwren: cool, I'll ping you Monday and we can pair up on this and knock it out [14:58] bac, rick_h__ I fixed juju-reports, I think charmworld has the same problem since we created both sites, see bug 1357403 [14:58] Bug #1357403: Charmworld is a single user website [15:00] sinzui: looking [15:01] Hello jose. CakePHP landed this morning thanks to Frederico's icon. [15:01] Thanks for your feedback jose [15:01] http://manage.jujucharms.com/charms/precise/cakephp [15:02] great news! mbruzek ! [15:02] yes it is! thanks sebas5384 [15:02] :D [15:29] heya all [15:29] saw some discussion of a juju sync-charm command [15:29] I've got a plugin I use to sync charm changes down to the host here: https://github.com/bloodearnest/plugins/blob/master/juju-sync-charm [15:30] it could easily push those changes to all other units if needed, as discussed [15:48] stokachu, ping? [16:04] I have a containter creation issue... [16:05] I need to figure out what is telling networkConfigTemplate that my lxc bridge network is 'br0' instead of 'lxcbr0'... anyone who can help me with that? [16:11] lamont: what does /etc/lxc/default.conf say? [16:12] lamont: also, what does /etc/default/lxc-net say? [16:13] on the host where I'm running juju, or on the host were the lxcs are getting created? [16:15] jrwren: both of those refer to lxcbr0. but juju runs lxc-create -f /var/lib/juju/containers/juju-machine-4-lxc-5/lxc.conf ..., and that file says: lxc.network.link = br0, for the failure to create any lxcs [16:15] so I'm trying to figure out where that br0 is coming from, and (more significantly) how to override/fix that, and whether or not it's abug [16:16] brctl show [16:16] bridge name bridge id STP enabled interfaces [16:16] lxcbr0 8000.000000000000 no [16:18] and since I suck at reading go, ... [16:20] and huh. we appear to have fixed that on the prior existance by using br0... though tbf, that was deployed a long time ago. [16:23] the other "interesting" thing is that the working machine (that uses br0) has ethN interfaces, and the one that doesn't work has emN interfaces === cmagina_ is now known as cmagina [16:38] this is a maas/juju deployed machine on which I'm creating numerous lxcs [16:41] Hi All! Do exist any how-to for move the bootstrap node for a juju environment to the new machine ? [17:07] interestingly, this appears to be maas not handling the case where eth0 is not the default network iface [17:09] Hey all. I've got a quick question about beploying charms in an openstack environment. I'm using ceph as the cinder backing store, and i'd like to boot machines using cinder volumes(instead of instance storage on the hypervisors) [17:10] I don't see any way to do this at the moment, though i could see a way to do it via the openstack api(it's multiple api calls which are presented as one distinct action in the openstack gui) [17:10] Am i missing some setting, or might this be a feature request? [17:23] man, it bugs me that launchpad has human-readable URLs, but you can't actually edit the URL to navigate to logical places... like I'm at http://bazaar.launchpad.net/~charmers/charms/precise/wordpress/trunk/files and I think "oh, I wonder what other charms are under precise?" so I edit the url to "http://bazaar.launchpad.net/~charmers/charms/precise/" ... 404 === roadmr is now known as roadmr_afk [17:48] My friends, I created a local environment under ubuntu 14.04 and bootstraped it. I did a juju deploy juju-gui --to lxc:0 and then a expose. The agent-state is pending since then (4 hours). The ufw is disabled. There's some other workaround? [17:49] ayr-ton: why would you do juju deploy --to lxc:0 [17:49] just do juju deploy juju-gui [17:49] which will spawn an LXC container on your host machine [17:50] that won't work because 0 on the local provider is your actual machine [17:50] so juju will try, then fail, to set it up [17:51] hmmm... [17:51] let me try =x [18:06] marcoceppi, there's a new machine number, but the state is pending [18:07] For like 15 minutes. [18:08] ayr-ton: what is the output of 'lxc-ls --fancy' ? [18:09] jcw4, empty, just the first line: NAME STATE IPV4 IPV6 AUTOSTART and the second with: ---------------------------------- [18:10] ayr-ton: I was just checking that the template file wasn't locked... doesn't look like that was the issue.. although I *would* expect there to be at least one lxc container if you're using local juju [18:12] jcw4, Yes. It does make sense. Let me see If I can found some problem in my lxc. One sec. [18:42] jcw4, It feels to be some problem with permissions. I'm trying to figure out how to fix it. [18:43] I'm trying the last one: https://juju.ubuntu.com/docs/troubleshooting-local.html [18:44] My image is from Aug 13. [18:55] jcw4, Not worked. ;~ [18:55] ayr-ton: :( [18:55] mbruzek: awesome, good to know! thanks for giving me the heads up :) [18:55] ayr-ton: I'm afraid I'm out of ideas [18:55] I just removed the old image from cache, destroyed the environment, bootstraped it again, juju deploy juju-gui.. [18:56] jose thanks for sending out the email [18:56] http://paste.ubuntu.com/8056048/ [18:56] ayr-ton: hmm; same thing? hanging for a long time, state pending? [18:56] mbruzek: it was nice to hear what others thought about it [18:56] Yep. And lxc-ls is empty [18:57] actually: sudo lxc-ls give me ayrton-local-machine-0-lxc-0 juju-trusty-template [18:57] ayr-ton: hmm; that's promising, although now it's sounding like the template lock file issue [18:58] The debug-log shows me a error related to mongo, this time: http://paste.ubuntu.com/8056065/ [18:59] juju.mongo open.go:82 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused [19:00] ayr-ton: http://irclogs.ubuntu.com/2014/07/30/%23juju-dev.html [19:00] look for convo starting around 02:07 === roadmr_afk is now known as roadmr [19:06] jcw4, let me see.. [19:37] jcw4, Holly mother of God. It is working: http://25.media.tumblr.com/tumblr_m6td1wPntx1rrgtiio1_500.gif [19:38] jcw4, The template lock was the issue. [19:38] Thank you very much (: [19:41] ayr-ton: \o/ [19:58] marcoceppi: I'm trying to deploy a very slightly modified postgresql charm, and I kee getting 2014-08-15 19:52:11 INFO install subprocess.CalledProcessError: Command '['open-port', '5432/TCP']' returned non-zero exit status 1 during the install hook. Any idea why that would be happening? [20:12] natefinch, Theres something using the port 5432? [20:12] ayr-ton: shouldn't be, this is just a default deploy of the charm on a brand new EC2 instance [20:13] looks like it's not just my teaked charm, the standard precise postgres charm hits the same error [20:13] says there's a conflict with the port [20:17] marcoceppi: relevant to your interests: https://github.com/juju/juju/pull/528 [20:20] natefinch: can you elaborate on "the first argument" [20:20] natefinch: like, "default-hook install" or will it just be "install" [20:20] os.args[1] == hook_name [20:20] os args[0] will still be default-hook [20:20] correct [20:20] so* [20:20] marcoceppi: I can't change os.args[0] [20:20] hum, that would require some patching in charm-helpers [20:20] natefinch: wellllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll [20:21] marcoceppi: for the charm I tweaked, that's actually what i did [20:21] natefinch: you patched charm-helpers? [20:21] I can't see where it's patched [20:21] marcoceppi: https://github.com/natefinch/pgcharm/blob/master/hooks/default-hook#L2335 [20:21] marcoceppi: no, I patched os.args [20:21] oh, psh [20:21] you patched it in the python code [20:21] gotchya [20:22] We'll probably create an update to charm-helpers where when using hooks.Hook you can define if you want to do legacy support or not [20:22] actually [20:22] we can make it smart [20:22] if os.argv[0] == default-hook, use os.argv[1] [20:22] marcoceppi: yep, if arg 0 is default-hook the hook name is arg 1 [20:22] yup [20:22] nicve [20:22] nice [20:22] I'll submit a patch to charm helpers soon for that [20:22] natefinch: you da man! [20:23] marcoceppi: I figured that one would be easy.... surprised we didn't do that forever ago, when we realized most people just want to write one script, not 20 [20:24] heh