=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === timrc is now known as timrc-afk [05:11] jcastro: so, Nathan Williams deactivated his LP account and hasn't responded to my email, I wonder if it's good to take ownCloud maintainership by now === sputnik1_ is now known as sputnik13net === CyberJacob|Away is now known as CyberJacob === vladk|offline is now known as vladk === CyberJacob is now known as CyberJacob|Away === vladk is now known as vladk|offline === xnox is now known as NoNameYet_xnox === psivaa-afk is now known as psivaa === vladk|offline is now known as vladk [10:20] hello charmers - I have a gunicorn MP here: https://code.launchpad.net/~bloodearnest/charms/precise/gunicorn/upgrade-path/+merge/213236 [10:23] it does not appear in the review queue, I think because Michael Nelson +1'ed it, and he is a member of ~charmers (although unsure as to his official status as able to merge) [10:23] also it fixes 3 minor outstanding MPs, listed on the MP comments [10:24] so, if some one could land it, that would clear 3 MPs of the charm review queue. As well as including all the fixes [11:15] bloodearnest: yeah, so because of the way charmers is structured, people like inactive-charmers and former charmers are also in the group, so if a now defunct member of the team +1's a review but doesn't merge it - it gets lost :( [11:15] bloodearnest: we have plans to address that next week [11:20] marcoceppi: good to know [12:16] #juju-core [12:53] jose, yeah, might as well === timrc-afk is now known as timrc [13:46] mbruzek: can you review/merge this? [13:46] https://code.launchpad.net/~bloodearnest/charms/precise/gunicorn/upgrade-path/+merge/213236 [13:47] marcoceppi, Yes I can [13:52] mbruzek: thanks [13:52] mbruzek: thanks. cheat sheet for testing the upgrade path: https://pastebin.canonical.com/108935/ [13:53] marcoceppi, bloodearnest There is another gunicorn MP before this one, do either of you know if they depend on each other? [13:53] * marcoceppi heavy shrug [13:55] mbruzek: this one includes the fixes from all 3 currently in the queue (see comments on MP) [13:56] mbruzek: 2 of those are duplicate fixs of the same problem, anyway [13:56] bloodearnest, ack [13:56] mbruzek: this one is actually older than all those 3, but got lost [13:57] mbruzek: I just updated it today to include all those issues, and fix an issue michael found about not removing the old service [14:00] mbruzek: you partially reviewed this originally, IIRC, so hopefully is familiar? [14:01] yep, I just need the time to review it. [14:06] jcastro: marcoceppi: what am I doing wrong? [14:06] mhall@mhall-thinkpad:~/projects/Ubuntu/summit/charms/trusty/certification$ sudo juju bootstrap [14:06] uploading tools for series [trusty] [14:06] Bootstrap failed, destroying environment [14:06] ERROR bootstrapping a local environment must not be done as root [14:07] mbruzek: don't use sudo? [14:07] maybe he's doing local [14:07] mbruzek: as of 1.17, bootstrap on local no longer requires sudo [14:07] oh [14:07] mhall119: ^^ jose ^^ [14:07] that's news for me :P [14:07] ? [14:07] oh, must *not* be done as root [14:07] I fail at reading [14:08] I assumed it was the old message [14:08] mhall119: np, it's a depature from the previous functionality [14:08] mhall119: you may also need to do some permission fixes in you ~/.juju directory [14:08] marcoceppi, https://github.com/juju/docs/pull/79 [14:08] can you confirm the syntax on Note: pls [14:08] I fixed the other stuff [14:09] mhall119: make sure to set the default series on your environments.yaml to precise or trusty (I recommend precise) or LXC machine creation will fail [14:12] jose: it's set for trusty [14:12] it's up to you :) [14:14] well, I'm targetting trusty, so that's what I need :) [14:31] 2014-04-22 14:30:37 INFO config-changed OSError: [Errno 2] No such file or directory: '/etc/postgresql/9.1/main/postgresql.conf' [14:31] using the IS charm for postgresql on trusty, any idea why I get that error? [14:35] mhall119: postgresql is 9.3 on trusty [14:35] mhall119: the charm store charm has already compensated for this === Ursinha is now known as Ursinha-afk [14:36] fwiw, you can mix series in your deployment. IE, deploy IS postgresql from precise, your charm from trusty [14:39] ok, thanks marcoceppi [14:39] how do I do that with juju? [14:43] mhall119: just deploy with the series in the deploy command [14:43] mhall119: juju deploy cs:precise/postgresql [14:43] will give you postgresql on precise [14:43] same with local: [14:44] ok === Ursinha-afk is now known as Ursinha [14:55] marcoceppi: now I'm seeing a lot of: [14:55] machine-0: 2014-04-22 14:55:09 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: cannot start machine 1: no matching tools available [14:55] machine 1 is my precise target [14:55] mhall119: ah, local provider doesn't upload multiple tool sets :\ [14:56] so I can't mix and match trusty and precise with the local provider? [14:56] doesn't seem so, there might be a beter way === wedgwood is now known as Guest26994 === wedgwood1 is now known as wedgwood [15:05] mhall@mhall-thinkpad:~/projects/Ubuntu/summit/current_work/summit$ juju deploy cs:postgresql postgresql [15:05] ERROR charm not found: cs:trusty/postgresql [15:05] what am I doing wrong now marcoceppi ? [15:10] mhall119: There isn't a trusty version of the charm in the store. [15:11] mhall119: you can do some testing locally if you have charm-tools installed. charm-get postgresql in a trusty directory in your local c harm repository [15:11] then deploy from there. [15:12] marcoceppi said the charmstore charm was ready for trusty :( [15:14] marcoceppi: has postgres been promulgated for trusty? i dont see it... but that doesn't mean I missed it. [15:14] s/missed it/didn't miss it/ [15:14] mhall119: we're in a meeting, and i'll follow up once we're out. [15:31] lazyPower: I'm jumping on a call now myself, so whenever you're free [15:31] thanks [15:34] hey guys, I'm having some troubles with charm helpers, http://paste.ubuntu.com/7307816/ is giving me ImportError: No module named lib.charmhelpers.contrib [15:36] lazyPower: marcoceppi: one more issue, though postgresql charm didn't work, my django and gunicorn charms say they started, but I can't connect: http://paste.ubuntu.com/7307845/ [15:36] not even to get a django error message [15:39] mhall119: i'm fairly certain we haven't reached those charms in the audit. It may be experiencing silent failure on the charm. Without interfacing directly with that deployment i'm not sure. [15:58] hey stub, is postgresql ready for trusty? Should I test for compat? [16:00] juju bootstrap is timing out when using /etc/rc.local to set up a raid0 and mount it...the script is running fine but juju hangs on 'attemping to connect' when it finishes...any ideas? === jamespag` is now known as jamespage [16:40] bigtree, I read somewhere that the firewall could interfere with juju. I had to disable it `sudo ufw disable` in my trusty vagrant box. [17:14] @renier, thanks -- I added a 'sleep 60' to the beginning of the script ....that solved the problem but I'm not sure why === vladk is now known as vladk|offline === natefinch is now known as natefinch-afk [17:53] how can I force a unit to stop when I have an error ? [17:53] I ran juju destroy service myservice [17:54] as it was already in an error state it could not stop [17:54] I ran juju resolved myservice/x [17:55] I didn't want to run debug-hooks for each unit (because I just wanted to stop them) so I tried several times [17:56] now I have an error if I try debug-hooks: ERROR cannot set resolved mode for unit "shard1/1": already resolved [17:58] is there a way to force this? I would prefer not destroying the environment nor the machines [18:00] Tug: not that they are in the resolved status you can't destroy them? [18:01] they are not in resolved status, resolved brought them back in error state [18:01] (because I did not run juju debug-hooks to return 1) [18:02] alright [18:02] I just needed to be patient [18:02] they just got removed [18:02] :) === hatch__ is now known as hatch === roadmr is now known as roadmr_afk === vladk|offline is now known as vladk [18:48] Using juju bootstrap on MaaS is successful, but when trying to add units/other machines juju hangs on login and the juju agent is never started. [18:48] Anyone have any ideas? [19:06] Does juju prevent rc.local from running? === CyberJacob|Away is now known as CyberJacob === roadmr_afk is now known as roadmr === natefinch-afk is now known as natefinch [19:37] mbruzek cory_fu: https://github.com/marcoceppi/amulet/pull/28#issuecomment-41081228 [19:39] marcoceppi, we both commented on this. The changes are safe to make [20:08] when i terminate a unit in a peer relationship, is it possible to determine in the relation-departed hook which of the two peers is going away? [20:31] hey, I just installed a 14.04 server and put juju-quickstart on it but when I try to run it, I only get this traceback https://dpaste.de/CEh4 [20:33] hedin: looking [20:35] rick_h_: thanks :) [20:35] hedin: yea, that's odd and not seen that. Filing a bug and will try to replicate. [20:36] hedin: ever do much python development? [20:36] hedin: I wonder if getting quickstart from another source has the same issue. [20:36] hedin: https://bugs.launchpad.net/juju-quickstart/+bug/1311321 at the moment [20:36] <_mup_> Bug #1311321: ascii can't decode error in 14.04 server install [20:38] is it possible to run a hook again, even when the status is `started` ? [20:39] rick_h_: no, just a bit of scripting... [20:42] hedin: ok, I've filed the bug and will work on seeing if I can replicate in a VM [20:46] hedin: curious what the output of `echo $LANG` is on your juju-quickstart machine? [20:54] $ echo $LANG [20:54] en_GB.UTF-8 [20:57] I have installed ubuntu-14.04 LTS server on top of proxmox... After ubuntu installation, with only openssh-server selected, I ran: [20:57] sudo apt-get update && sudo apt-get upgrade [20:57] rebooted and sudo apt-get install juju-quickstart [20:57] and then juju-quickstart, as you saw in the dpaste [20:58] hmm... locale might give an answer... https://dpaste.de/qCeb [20:59] try this: [20:59] $ python -c "import locale; locale.setlocale(locale.LC_ALL, ''); print locale.getlocale()[1]" [21:01] tvansteenburgh: output: https://dpaste.de/oO2v [21:02] there is no locale.gen file in /etc/ on 12.04 and debian, I just uncomment the fo_FO.UTF-8 line and run locale-gen [21:08] hedin: i don't follow...you fixed it? [21:10] hedin: this is 12.04? I thought you were on 14.04? [21:11] it is 14.04 [21:11] Linux ubuntu 3.13.0-24-generic [21:11] i would try: [21:11] sudo locale-gen en_GB.UTF-8 fo_FO.UTF-8 [21:11] dpkg-reconfigure locales [21:12] tvansteenburgh: that fixed it, now juju-quickstart runs [21:12] \o/ [21:13] thanks for the help :) [21:13] maybe there should be added a check if locale's are configured ? [21:15] hedin: you're welcome, of course [21:16] thanks tvansteenburgh, notes added to the bug. We'll look into a good way to watch for that [21:16] rick_h_: sure thing [21:16] * tvansteenburgh goes back to minding his own business === vladk is now known as vladk|offline === hatch___ is now known as hatch [21:54] hi, I have an environment using lxc on trusty, and machine 1 doesn't seem to be starting. Where would I find the logs for that machine? [21:55] ~/.juju//log only has machine-0.log [21:55] (and a couple of other files) [21:56] james_w: any clues in the all-machines.log ? [21:56] ERROR juju runner.go:220 worker: exited "environ-provisioner": no state server machines with addresses found [21:56] that's the only error-looking thing [21:57] to my eye at least [21:59] james_w: using local provider? [21:59] yeah [21:59] https://bugs.launchpad.net/juju-core/+bug/1248800 has that message [21:59] <_mup_> Bug #1248800: worker/provisioner missed signal to start new machine

[21:59] and says "restarting the provisioner fixed the problem" [21:59] how would I try that? [22:00] i would just destroy the environment and start over [22:00] tried that [22:00] I can try again [22:00] :( [22:02] james_w: do you have juju-mongodb installed? [22:02] yeag [22:02] yeah [22:03] re-bootstrapped and the same message trying to deploy cs:ubuntu [22:03] james_w: do you have default-series: specified in your env config? [22:04] no [22:04] only type and admin-secrey [22:04] secret [22:06] james_w: when you bootstrap, does it say "uploading tools [trusty, precise]" or similar? [22:06] [trusty[ [22:07] so, not sure it this is the issue here, but it will be an issue with some charms, but you need default-series: precise to get juju to upload precise tools [22:08] http://paste.ubuntu.com/7310317/ is the all-machines.log [22:09] jcastro: hey, the 'Please remove jenkins from trusty' bug, would adding the source specified on that page you mentioned and apt-getting work? [22:10] yes [22:10] the charm needs to get from their repo [22:10] since it's not in ubuntu [22:11] ok, I'll see if I can work in getting that fix into the queue [22:28] Hey so, question [22:29] with our current juju boxes not being in alignment with the tutorial that we have on the docs, we should probably temporarily remove that doc section? There's not a planned fix on the horizon for the juju vagrant boxes - pending additional work from hazmat from what i observed earlier today [22:29] s/work/assessment [22:29] jcastro: ^ [22:37] lazyPower, I agree [22:37] ok just so i'm on the right path, i need to make that fix in the MD docs in the /EN branch? [22:38] yes [22:38] the instructions are up to date [22:38] check contributing.html [22:38] thanks! i'll mmake that PR before i EOD for the morning. [22:38] on the live website [22:38] wow that came out all janky. I'll make a PR for first thing in the morning. [22:39] how should I specify that a charm can relate to *all* interfaces? [22:39] (in the metadata.yaml) [22:46] jose: what do you mean? [22:47] lazyPower: I have the pagekite charm and I want it to be able to relate to literally any other charm [22:47] jose: well, thats tricky. there's no catch-all. [22:47] oh [22:48] my suggestion would be to either define an interface for pagekite, or impelement the interfaces that pagekite should work with, eg: http, reverseproxy, et al. [22:48] and go from there. breaking off the expected workload in chunks after its been verified to work. If you do that you'll take care of most of the charms you're concerned with supporting, and users that want something specific can open a feature request [23:08] jose: juju-info I think is the name of the minimum interface supported by every charm [23:08] hmm, ok [23:09] I'll work in that one tomorrow I think, apparently I have to do some homework today :) === sputnik1_ is now known as sputnik13net [23:29] james_w: while that works, it only exposes the remote IP address. I'm not sure how pagekite works but i assume it requires more than just the ip?