=== Ursinha is now known as Ursinha-afk === CyberJacob is now known as CyberJacob|Away [00:54] Is there a way to manage lxc containers on different hosts? afaik local in environments.yaml is on one machine only === Ursinha-afk is now known as Ursinha === markthomas is now known as markthomas_away === FourDollars_ is now known as FourDollars === Tribaal_ is now known as Tribaal === perrito6` is now known as perrito666 [03:02] who === timrc is now known as timrc-afk === timrc-afk is now known as timrc === timrc is now known as timrc-afk === sarnold_ is now known as sarnold === CyberJacob|Away is now known as CyberJacob === bodie_ is now known as Guest31737 === CyberJacob is now known as CyberJacob|Away [09:08] Hi, I'm new to juju, I've managed to deploy juju-gui, but I'm having trouble because I need to obtain charms via a proxy. Does anyone know now to set the proxy for juju-gui? [09:11] mwalton: what problems are you encountering? [09:14] when I try to add a charm via the gui I get a name resolution error (the proxy I've set for juju is an IP) which means it's not using the proxy to access the charm store [09:15] yet I can browse the charms [09:15] search works [09:15] The deployment errored: [Errno socket error] [Errno -3] Temporary failure in name resolution === jacekn_ is now known as jacekn === bloodearnest_ is now known as bloodearnest [11:33] fwereade: could you have another look at https://codereview.appspot.com/68000045/ ? [11:34] adeuring, sure [12:05] marcoceppi_, hey - I just pushed some commits to my percona-cluster charm branch which use a new method for distributing passwords across a cluster [12:05] all in mysql.py [12:17] jam: eg, http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/precise-updates/cloud-tools/main/binary-amd64/Packages [13:13] Hi [13:13] i am writing a client/server zabbix charm [13:13] i wrote the zabbix server charm and it works fine [13:14] now i need to add a zabbix-client charm [13:14] so when i do juju add-relation zabbix-server zabbix-client [13:14] the client can upload entries into the server [13:15] mysql is integrated in zabbix-server [13:15] so i just need a relation between the zabbix server and client [13:15] can someone tell me how to write the relation-joined hook [13:15] or relation-changed === smoser` is now known as smoser === timrc-afk is now known as timrc === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [13:47] has anyone had much success using juju in an environment that requires a proxy for internet access? [13:49] I've managed to use set-env http-proxy to configure the proxy, but found that on an install hook of keystone, it tries to access localhost, and tries to go through the proxy for that [14:23] mwalton: did you have a look at this post? http://askubuntu.com/questions/11274/setting-up-proxy-to-ignore-all-local-addresses [14:24] im not real familiar with how juju forwards the proxy information around, but i assume that you can set this type of configuration on the proxy server so it auto-configures the hosts. [14:24] and more implicitly - http://askubuntu.com/a/42271/6807 that response. [14:32] sinzui: ping about bug #1289376 [14:32] <_mup_> Bug #1289376: Cannot build r2379 on amd64+precise

[14:32] that looks like your build host suddenly changed what version of "go" it is using [14:32] the one that is in the Precise archive can't build juju-core today [14:33] you have to use the ppa:juju-core/golang one [14:34] oops, should be in the other channel [14:34] jam, I thought I was. [14:34] *I* should have been [15:07] Can we agree just not to use camelCase in bundle names? [15:08] WhatIsWrongWithCamelCaseMarco? [15:08] we hardly use camelCase at all anywhere else in juju, why it's envExport and not env-export or envexport or export is beyond me [15:08] nothing, it's just, we're tip-toeing down the path of php where we don't have a really well defined convention and it's going to make a lot of sad pandas [15:11] I am all for having a recommended convention. What do you suggest? [15:11] I +1 the notion of consistency, whether that be camelCase or _underscore usage, just be consistent. [15:11] the precendence seems to be mostly "-", with second most being _ [15:11] and I don't think I've come across a camelCase example except for what the GUI exports [15:12] i smell a bug # in marco's future [15:12] I'm composing one atm [15:13] Just to be clear the charm and bundle authors can write in camelCase right? [15:13] marcoceppi_, is just talking about the juju tools not using camelCase [15:13] Right? [15:14] right, there's no limiting you to what you can use, I just thing we should /strongly/ recommend people follow a convention [15:14] and then promote consisteny inside that charm/bundle [15:14] so if a charmer /really/ //really// wants to use camelCase in config options, they can, but all config options should be in camelCase at that point [15:14] OK. [15:15] But required fields that the juju tools read in should not be in camelCase. [15:16] mbruzek: expand [15:16] hello everyone! quick question: I have juju installed from ppa:juju/devel, and I was wondering if I can have amulet from somewhere (devel ppa does not provide it) [15:17] nessita: add the stable ppa [15:17] I don't like imposing rules on creative people. Let them write in camelCase if they want. But we can make guidelines that the required fields or words that are in the config.yaml, metadata.yaml and other things that Juju looks for are not camel case. [15:17] nessita: all tools, and stable relesases of juju are in ppa:juju/stable; dev releases of juju are in ppa:juju/devel [15:18] marcoceppi_, ok, so the 2 ppas will not "conflict"? [15:19] nessita: correct, juju stable releases are versioned as 1.EVEN and development releases are 1.ODD; so if you add the stable and devel ppa you'll always get the latest (wether it's dev or stable, depending on the release cycle) [15:19] so, current stable is 1.16.6 and devel is 1.17.4; in dpkg 1.17.4 > 1.16.6 so you'll get that. when 1.18 (next stable) lands you'll just be upgraded to that automatically [15:20] marcoceppi_, it sounds great. Thanks a lot! [15:20] lazyPower: did you confirm that d.sentry.wait is actually problematic on your deployments outside of the jenkins stuff? [15:21] marcoceppi_, I think it is fine that Juju has consistency on the keywords that it expects to see in the files (as not being camel case). But some programming language guidelines recommend camel case for variables and Juju should accept those as valid. [15:22] mbruzek: I'm not talking about in hooks, just in general, charms should be consistent within themselves. So a bundle shouldn't have a camelCase name with a bunch of options that are -/_ delimited. Same with a config.yaml file. It shouldn't have a mix of camEl/_/- delimited config keys [15:22] It should use one method and stick to it [15:22] and we should recommend X for users who don't know what to use [15:22] Yeah that looks logical. [15:22] marcoceppi_, I can agree to no camelCase. [15:23] marcoceppi_, my opinions on the entire bundle URL structure are well documented. :) [15:24] marcoceppi_, The first thing I would check is that there are no camelCase keywords in Juju or Amulet, or Charm-tools, etc so that we are consistent before recommending others do the same. [15:24] right, just saying envExport is misleading and I'm going to file a bug [15:24] mbruzek: I know for a fact that amulet and charm-tools have no camelcase options [15:24] marcoceppi_, hey, while you file [15:24] I don't know what envExport you are referring to. [15:24] and I'm like 99% that all configuraiton optoins are also not camelCase'd in juju [15:24] it's silly that the export tool exports something that is not immediately redeployable [15:24] mbruzek: export a bundle from teh gui [15:24] jcastro: basically, yes, it is [15:24] maybe have it generate something? [15:25] jcastro: as I understand it, the gui team has a task to prompt for a name [15:25] jcastro: at least, that was my impression for roadmap stuff [15:25] perfect [15:25] may want to double check that [15:25] roadmap as in handwavy roadmap from rick_h_ or have you seen a real bug report? [15:26] jcastro: hand wavy, but can't remember who waved their jedi-like hands at me [15:26] that's because they were tricking you [15:26] which is why I recommend dbl chking [15:26] * jcastro nods === Guest31737 is now known as bodie_ [15:26] I'll file my bundle UI nitnoids now too [15:28] lazyPower: what charms did you write already, papertrail and...? [15:36] marcoceppi_, when you can, would you please give me a hand with amulet usage? every command I've tried is failing, even --help as per https://pastebin.canonical.com/106147/ [15:37] marcoceppi_, even involkin $ amulet with no params fails [15:37] nessita: sorry, that's a bit of a misnomer that's being removed in the next release, amulet the command line option doesn't do anything. Currently it's only available as a python module [15:37] nessita: https://juju.ubuntu.com/docs/tools-amulet.html [15:37] marcoceppi_, thanks [15:37] the Programmable api section of the docs are forthcoming, but not currently available and a few releases ago broke what little functionality there was [15:47] marcoceppi_: just papertrail is all that's been accepted to the store. i have a WIP for Errbit, GitLab-CI, GitLab, and i'm rewriting PHPMyAdmin in ansible [15:49] marcoceppi_: d.sentry.wait() isn't misbehaving outside of the CI stuff. Its working fine when invoked via the juju test runner. [16:07] ta [16:07] lazyPower: then it's something in the CI that's being weird [16:07] sinzui: is there anyway I can get access to the instance that's running the charm testing stuff? [16:07] marcoceppi_, I think you have. [16:07] via ssh? [16:07] huh, let me try [16:07] lazyPower: is there a bug for the amulet post deployment commands not working? [16:07] there was you closed it [16:07] let me see [16:07] OH [16:08] you mean what i found on wednesday, nope. Let me file one real quick [16:15] lazyPower: thanks [16:16] lazyPower: just file bugs and how you got the bug when you see them, I tend to forget when they're just reported in IRC [16:16] lazyPower: it's easier to close a bug as not a bug than remember all the little errors I've codified into these projecs [16:19] ack. i'm running the test on jenkins now with a config change [16:19] to get you a strace [16:19] lazyPower: won't it take, like 45mins to error out because it's hitting timeout? [16:20] marcoceppi_: no because the d.configure() statement turned into chunky salsa [16:21] http://paste.ubuntu.com/7039200/ -- which is goign in the bug report [16:23] and now i'm getting the forever timeout on d.sentry.wait() - thats so strange that I wasn't hitting it yesterday [16:23] this is very inconsistent [16:23] ah, disregard, it was hung up on haproxy doing its thing. [16:24] lazyPower: we're talking about two different bugs I think [16:24] there's d.sentry.wait not working in jenkins, but elsewhere [16:24] and then there's post deployment commands failing [16:25] marcoceppi_: i'm talking about post deployment commands failing [16:25] because d.sentry.wait() works locally, but not in jenkins. [16:25] lazyPower: right, I'm investigating the jenkins thing in abit [16:26] and i don't have any information there. the only thing i can figure is its using an older release of amulet - that doesn't have that rework of d.sentry.wait() applied. Did we validate that its running 1.3.3? [16:26] lazyPower: it installs it in a fresh LXC for every run [16:26] * marcoceppi_ will investigate later [16:27] i'll spin up a precise VM and run via juju test runner to validate its not coming from that config, and isolated to being run through the substrate dispatcher in jenkins. [16:35] running now, here goes nothing [16:53] rick_h_: random question: any plans to make the gui code browsers understand symlinks to a hooks.py? I guess that's a Hard Problem. [16:53] unless they parse @hooks.hook(name) [16:53] bloodearnest: so no current plans. I thought we duped the file contents in charmworld. Which charm? [16:53] oh, no we don't do any of that [16:54] rick_h_: mongodb [16:54] rick_h_: yeah, it's tru=icky, but it makes the code browser difficult to use in such cases [16:54] true and icky - truicky [16:54] yea, don't think it's on the radar at the moment [16:55] rick_h_: fair enough === niemeyer_ is now known as niemeyer [19:14] Hi all. I am trying to get Maas and Juju working together as a test for our school network. Does anyone have any documentation about how to set up the network so we can access deployed charms when the nodes don't have any access to the school network. (maas region/cluster controller combo is gateway for nodes)? === sarnold_ is now known as sarnold [20:26] hello all. What guidelines do I need to follow for including the 'charmhelpers' in my charm that I would like to push to my launchpad account? [20:44] which one? [20:45] 1. sudo apt-get install juju-core [20:45] 2. sudo apt-get install juju juju-local charm-tools [20:45] ? [20:46] juju / juju-core? [20:53] kliieef: juju is juju-core [20:53] manjiri: you need to embed them directly from lp:charm-helpers [21:35] What would be the best solution to reach my deployed/exposed juju-gui when the node is in a private (cluster)network with MAAS? Do i need to set up some reverse proxy, or....? [21:57] zchander: either a reverse proxy, or a VPN to that network [21:58] OK, is there some how to available on the net? I tried to do a reverse proxy (using apache 2 on the MAAS controller), but somehow I don't succeed. [22:13] marcoceppi: Can you elaborate on what "embed directly" means?