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