=== CyberJacob is now known as CyberJacob|Away [01:00] Hi guys, I'm wondering if someone can help me figure out why my service is stuck in "agent-state: pending" [01:01] right now it is just the juju-gui [01:01] just not sure where to look [01:15] rsynnest: sure, happy to help [01:15] rsynnest: which environment is it? amazon, local, joyent, azure, etc? [01:15] cool thanks [01:15] it's onlinelabs [01:15] https://github.com/online-labs/juju-onlinelabs [01:16] not one of the big ones unfortunately [01:16] they are ARM servers which may be something to do with it [01:16] rsynnest: it's fine, I'm somewhat familar actually [01:16] oh cool [01:16] so this is using the manual provider [01:16] yeeah [01:16] can you pastebin using http://paste.ubuntu.com the output of juju status? [01:17] http://paste.ubuntu.com/9449401/ [01:18] rsynnest: ah, I think i know the issue [01:18] what command did you issue to deploy the gui? [01:19] juju deploy juju-gui [01:19] yeah, so 99% of the time, that works great [01:19] unless you're using the manual proider (so onlinelabs and digital-ocean atm) [01:19] ah ok [01:20] Typically, juju uses the cloud provider like amazon, openstack, blah blah to requisition you a machine and it then puts the service on that machine [01:20] since this is manual provider and juju doesn't know the API look ups for those two clouds [01:20] you have to use a slightly different command [01:20] what you'll want to do is juju destroy-service juju-gui [01:21] then, to save space (juju gui is actually designed to run on node 0, it's kind of special) [01:21] rsynnest: you can just type `juju deploy --to 0 juju-gui` [01:21] however, for all other services [01:21] you'll want to do the following [01:22] juju onlinelabs add-machine [01:22] ohhh that's right, I actually thought I did deploy it on the bootstrap node now that I think about it [01:22] this will provision a new machine for juju to use and enlist it in the pool of available machines [01:22] but that does appear to have done the trick [01:22] thanks! [01:23] rsynnest: no worries [01:23] you'll still need to provision more machines using `juju onlinelabs add-machine` (`-n #`, like -n 3 to add three machines) [01:23] before using gui or juju deploy [01:23] right [01:24] the onlinelabs add-machine will provision machines with onlinelabs, add the to juju's pool of machines for usage, and everything works from there [01:24] awesome, cheers rsynnest [01:52] Can I convince the local LXC provider to use my local Ubuntu archive mirror? [02:03] wgrant: you can [02:03] wgrant: what version of juju do you have? [02:04] 1.20.10 on vivid [02:04] wgrant: you should just be able to set APT_PROXY environemtn variable and on bootstrap it'll use it [02:04] wgrant: there's also an environment variable you can set [02:04] but I need to find it [02:04] marcoceppi: Ah, I can set that to a mirror rather than a proxy? [02:06] wgrant:oh, wait [02:06] wgrant: what doy ou mean by mirror? [02:06] The containers always use archive.ubuntu.com, which is very slow from here. [02:07] I have a local mirror of archive.ubuntu.com. [02:07] wgrant: right, if you serve that up on a transport [02:07] then you can use APT_PROXY [02:10] not sure how that would look exactly [02:17] marcoceppi: That didn't seem to change anything. How does archive.ubuntu.com normally get overridden on public clouds? Through cloud-init? [02:18] wgrant: I'm not 100% sure, I'd suggest emailing the list with the queries. I'll make sure to find someone who can help answer it tomorrow [02:25] marcoceppi: Thanks. === menn0_ is now known as menn0 === kadams54 is now known as kadams54-away === scuttlemonkey is now known as scuttle|afk === jam1 is now known as jam === frankban__ is now known as frankban === kadams54 is now known as kadams54-away === roadmr is now known as roadmr_afk === kadams54-away is now known as kadams54 === roadmr_afk is now known as roadmr === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [18:31] Is it possible to run a precise charm on a trusty machine? [18:32] rsynnest: yes, but you first have to fork the charm [18:36] cool, would I then need to change the config? [18:37] I'm still pretty new, I'd like to try writing a basic charm just to have a better idea about whats going on in there === sebas5384 is now known as _sEBAs_ [18:53] rsynnest: depends on the charm, but no just forking it into the trusty series in your local charm repo would be enough [18:54] rsynnest: if you want to get your hands dirty in a template, install charm-tools and charm create -h will give you an overview of whats available to you for exploration [18:58] nice === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === CyberJacob|Away is now known as CyberJacob === erkules_ is now known as erkules [20:07] are there any plans to have juju run on non-ubuntu machines? [20:08] rsynnest: which bits? [20:09] the client is available for several platforms [20:09] charms [20:09] ah [20:09] there is some support for centos and windows iirc [20:09] debian seems like it wouldnt be too far off [20:10] someone needs to just do the work [20:10] the store supports series [20:10] so doing jujucharms.com/wheezy/blah or whatever is doable [20:11] interesting [20:12] I wonder if an ubuntu docker container is too many layers [20:12] since that could theoretically run on any distro [20:16] jcastro: I've gotten juju to bootstrap once on debian [20:16] but it was super hacky === roadmr is now known as roadmr_afk === menn0_ is now known as menn0 [20:34] I guess it doesn't make a difference what distro is used now that I think about it [20:34] windows would be interesting [20:35] but also sounds like a hellish nightmare [20:40] rsynnest: well the goal of Juju is to eliminate that nightmare :) === kadams54 is now known as kadams54-away === roadmr_afk is now known as roadmr === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [21:06] marcoceppi: this is the problem that Yael was seeing when trying to run the amulet test on its own. http://pastebin.ubuntu.com/9467254/ [21:07] I recognize this as juju-deployer version on the system being old/out of sync, is that a correct assesment? [21:08] marcoceppi or tvansteenburgh or hazmat Could you tell me how to update deployer on the system to avoid this error? [21:09] apt-get install juju-deployer [21:09] tvansteenburgh: sudo apt-get install juju-deployer [21:09] juju-deployer is already the newest version. [21:10] then pip install [21:10] * marcoceppi burns hearing this [21:11] mbruzek: add ppa:juju/stable [21:11] or that [21:11] there's a more updated version of deployer and jujuclient in there [21:12] on pypi too! [21:12] we can't recommend customers just pip install stuff because it makes troubleshooting and updating near impossible [21:12] marcoceppi: juju/stable is already installed. [21:12] mbruzek: then something is wrong [21:12] 0.4.1 is latest in ppa [21:12] marcoceppi: This is ppc64le, I remember there being a dependency issue. [21:12] fuuuuuuuuuuuuuuu [21:12] there's no ppa builders for ppc64le [21:13] marcoceppi: is there a 0.4.1 for ppc64le? [21:13] marcoceppi: thus why the ISV/partner was having this problem. [21:13] oh there [21:13] is [21:13] marcoceppi: link? [21:13] mbruzek: https://launchpad.net/~juju/+archive/ubuntu/stable/+packages [21:15] When I expand juju-deployer-04.1-1 I do not see a ppc64le deb [21:16] because ppc64el and le are the same thing [21:16] bleh [21:16] sorry [21:16] I was looking at juju-core [21:17] let me see if I can get a build for ppc64le === fuzzy_ is now known as Ponyo [21:32] mbruzek: I re-uploaded juju-deployer [21:33] lets see if that builds ppc64le [21:33] OK thank you marcoceppi [21:33] I found a bug on this very topic already, so I added myself the the list: [21:33] https://bugs.launchpad.net/juju-deployer/+bug/1389755 [21:33] Bug #1389755: juju-deployer is not working on ppc64le [21:37] mbruzek: it doesn't appear that ppas have access to ppc64el [21:38] *sigh* [21:39] How does a python code care about that? Can't the builders spit out debs in any architecture? [21:39] marcoceppi: you have to request them special I'm told [21:39] marcoceppi: because they run on limited hardware and such [21:39] marcoceppi: but I'm told it can happen [21:39] rick_h_: any idea who I need to talk to? [21:39] marcoceppi: launchpad folks/webops? [21:39] mbruzek: I didn't build the package, so I cant' say why it's arch aware [21:40] typically you just get an _all arch === kadams54 is now known as kadams54-away [21:40] marcoceppi: I am happy to chase this down if you let me know who to talk with on webpos [21:41] mbruzek: start with asking vanguard or mthaddon and they should help get you pointed from there [21:41] rick_h_: in #is? [21:41] mbruzek: #webops [21:42] * mbruzek adds #webops to his channel listing [21:42] thanks rick_h_ [21:42] marcoceppi: np, hopefully kicks things off for you [21:42] * rick_h_ checks out for the day [21:43] Thanks rick_h_ have a nice day [21:44] soo, I git cloned precise/meteor and tried to deploy it as trusty/meteor, and the install hook failed [21:45] not sure how to debug, I don't see anything in juju debug-log [21:47] http://paste.ubuntu.com/9467597/ [21:48] the service is up and relations appear to be working, but the unit itself is down [21:49] rsynnest: you can do `juju debug-hooks meteor/0` then in a seperate terminal, run `juju resolved --retry meteor/0` this will allow you to re-run the install hook on the unit and watch the output [21:49] ah awesome, thanks [21:49] rsynnest: https://jujucharms.com/docs/authors-hook-debug [22:12] I'm trying to get the private IPs for units of a service. I can do this with `juju run --service myservice "hostname -i"`, which works, but I'm assuming I shoud be using unit-get private-address instead? (which gives me a private dns, which I then need to convert in python, on the unit, using socket.gethostbyname - so much simpler with hostname -i). [22:12] Any reasons not to use hostname -i? [22:13] noodles775: sorry, but I have no idea... [22:15] np, thanks. I'll just use hostname -i for now :) === menn0_ is now known as menn0