[00:08] <thumper> kenn: hey
[00:08] <thumper> kenn: ec2 isn't good at giving lxc containers their own ip address
[00:08] <thumper> it is potentially a good idea when we can get ec2 to play nice with the lxc containers
[00:08] <thumper> but this isn't there yet
[00:10] <kenn> thumper: well, theoretically I don't need the LXC containers to have a public IP, as everything currently runs through an nginx proxy anyway.
[00:11] <kenn> thumper: but, if EC2 instances are not capable of running several LXCs anyway, then I guess I'll have to figure something else out
[00:31] <thumper> kenn: they can... if the nginx proxy is on the same machine as the lxc containers, it may work
[00:31] <thumper> kenn: it is all about the networking
[01:48] <kenn> thumper: I'd like to play around with it, how do I add an LXC to an EC2 instance, or even a local LXC?
[01:48] <thumper> kenn: juju will not allow it (or it shouldn't or won't once we hook everything up)
[01:49] <thumper> you can try: juju add-machine lxc:1
[01:49] <kenn> thumper: ah ok, so currently this is not implemented?
[01:49] <thumper> I think that tries to create an lxc container on machine 1
[01:49] <kenn> ok, let me try that :)
[01:49] <thumper> kenn: it is implemented but specifically disallowed on ec2 because it doesn't talk right
[01:49] <thumper> failing that,
[01:49] <thumper> you end up using the lxc commands directly
[01:50] <thumper> sudo lxc-create -n some-name -t ubuntu-cloud
[01:50] <thumper> etc
[01:50] <kenn> haha no I will not be doing the latter :)
[01:54] <kenn> thumper: adding the LXC to a running machine seemed to work. It added something anyway. Though if it doesn't work on EC2 then I think I'll solve the problem in a different way
[01:54] <thumper> you can the go: juju deploy ubuntu --to 1/lxc/0
[01:54] <thumper> and then : juju ssh ubuntu/0
[01:54] <thumper> if that is the first one
[01:54] <kenn> I was just about to google that
[01:55] <kenn> hang on, I have to deploy ubuntu?
[01:55] <thumper> not exactly
[01:55] <thumper> but kinda
[01:55] <thumper> due to the way that addressing isn't properly hooked up yet
[01:55] <kenn> ok, so sub-lxcs are kind of sort of experimental then?
[01:56] <thumper> it is the only way to get the ip address shown in juju status
[01:56] <thumper> kenn: they work on maas, but not on other providers yet
[01:56] <thumper> as we need to hook up the networking
[01:56] <kenn> right, gotcha
[01:56] <kenn> thanks for the help though
[01:56] <thumper> np
[01:58] <kenn> thumper: as a side note, while I have the attention of a juju developer: I absolutely love the design you guys have come up with. In my previous job I did Chef on RightScale and that was such a nightmare compared to this
[01:58] <thumper> thanks
[01:58] <kenn> so, good job!
[01:58] <thumper> I've only been on it since the start of the year
[01:59] <thumper> so can't take the real credit
[01:59] <thumper> but I do like it too
[01:59] <thumper> I'll pass it on
[01:59] <thumper> glad you're enjoying it
[01:59] <kenn> please do
[04:31] <kenn> I'm having trouble working with my local environment. Starting a new machine doesn't create a log for that machine, and deploying services shows up in watch, but stays pending
[04:32] <kenn> I've tried destroying and bootstrapping my environment several times, including system restart. I've also manually killed a few LXC containers left over with lxc-destroy
[04:32] <kenn> during environment bootstrap I get the following error in the log:
[04:32] <kenn> 2013-10-04 04:29:58 ERROR juju apiclient.go:111 state/api: websocket.Dial wss://localhost:17070/: dial tcp <IP_ADDRESS>:17070: connection refused
[04:32] <kenn> any ideas?
[04:32] <kenn> juju version: 1.14.1-quantal-amd64
[04:36] <davecheney> kenn: that means bootstrapping didn't work
[04:36] <davecheney> kenn: do you have the right version of mongodb installed ?
[04:37] <kenn> db version v2.2.4, pdfile version 4.5
[04:38] <kenn> according to APT, that's the right version
[04:39] <davecheney> ok, that is ood
[04:39] <davecheney> that is the usual stumbling block
[04:39] <davecheney> kenn: can your latop talk to the internet without a proxy ?
[04:39] <davecheney> s/laptop/machine
[04:40] <kenn> yes, I don't have a proxy
[04:47] <kenn> I tried reinstalling juju and mongo via apt and also cleared all mongo's data. Still no luck, same error
[04:49] <davecheney> kenn: we don't use the mongodb that the ackage provides
[04:49] <davecheney> we start our own
[04:49] <davecheney> can you please try (not sure if this will give results)
[04:49] <davecheney> juju bootstrap --debug
[04:54] <kenn> two logs here: http://pastebin.com/ShCQVYYC (terminal output) and http://pastebin.com/QMfC16PU (machine-0.log)
[04:54] <kenn> davecheney: ^^
[04:55] <davecheney> kenn: that looks fine
[04:55] <davecheney> what is the issue you see
[04:56] <kenn> machine-0.log: 2013-10-04 04:52:00 ERROR juju apiclient.go:111 state/api: websocket.Dial wss://localhost:17070/: dial tcp <IP_ADDRESS>:17070: connection refused
[04:56] <davecheney> yeah, that happens
[04:56] <davecheney> it's just part of the startup dance
[04:59] <kenn> ok, when I to add-machine a machine is created, but no log file is created. When I then add a service (like mysql) to that machine, the service appears in juju stat as pending, no log file is created, and that's how it stays
[05:07] <kenn> ok, it finally created the log file which states the install hook has been queued. No change for a few minutes though
[05:11] <davecheney> the logs should all be in ~/.juju/local/something something/log
[05:11] <davecheney> alongside wher eyou found machine-0
[05:11] <davecheney> if they are not
[05:11] <davecheney> machine-0.log will have the details on what happened
[05:12] <kenn> they aren't there, let me check machine-0
[05:13] <kenn> no errors in machine-0.log as far as I can tell
[05:18] <davecheney> can you make machine-0.log available
[05:18] <davecheney> kenn, did you use sudo to bootstrap ?
[05:20] <kenn> davecheney: the machine-0.log is the one I posted here  http://pastebin.com/QMfC16PU, and yes I used sudo for the bootstrap
[05:21] <kenn> let me post one after starting machines and stuff
[05:22] <kenn> davecheney: this is machine-0.log after trying to deploy mysql and starting a second machine: http://pastebin.com/4Pf1DgdP
[05:22] <kenn> I should note that I downgraded juju to see if that would fix it
[05:26] <davecheney> kenn: ok, it looks lke juju asked lxc to start two machines
[05:27] <davecheney> but they never started
[05:27] <kenn> ok
[05:27] <davecheney> anything in dmesg
[05:27] <davecheney> or /var/log/syslog
[05:27] <davecheney> btw, which OS are you using ?
[05:28] <davecheney> local providers is only known to work on raring or later
[05:28] <davecheney> also, what is your net connection doing ?
[05:28] <davecheney> there could be a large lxc related download going on
[05:29] <kenn> I'm on ubuntu quantal. What am I looking for in dmesg and syslog? I'll check my connection
[05:30] <davecheney> lxc is doing a version of debootstrap for every machine you start
[05:30] <davecheney> so that could explain a delay
[05:30] <davecheney> or it could just be broken
[05:32] <kenn> hmm, I do appear to downloading quite a lot of stuff from zaurac.canonical.com
[05:33] <kenn> ok you know what, I've probably just been incredibly impatient
[05:33] <davecheney> np, that has as solution
[05:33] <davecheney> and isn't typically a bug :)
[05:33] <davecheney> i *think* once lxc has done it's dance the fist time
[05:34] <davecheney> it will cache the results
[05:34] <kenn> the mysql server has installed and started, and it would appear my local charm is now installing
[05:34] <davecheney> so this is a one time cost
[05:34] <kenn> ok, sorry about the fuss man, it's just usually so damn instant!
[05:35] <kenn> I will be more patient next time :)
[06:46] <kenn> Is there a place where I can find a list of all the juju api commands? Like open-port and config-get. I can't find it in the docs.
[06:50] <kenn> Secondary question, what the best way to get the IP of the box my service is being deployed to? Internal IP is fine.
[07:01] <davecheney> kenn: second answer first
[07:01] <davecheney> unit-get private-address
[07:01] <davecheney> unit-get public-address
[07:01] <davecheney> etc
[07:02] <davecheney> kenn: first answer
[07:02] <davecheney> https://juju.ubuntu.com/docs/authors-charm-anatomy.html
[07:02] <davecheney> grep for "Hook commands for working with relations"
[07:14] <kenn> davecheney: awesome, thanks, for both. Is there a more complete list somewhere? I'm ok with digging around source code if need be
[08:23] <gnuoy> morning I seem to have a wedged maas environment. If I try and do destroy-environment I get "error: gomaasapi: got error back from server: 409 CONFLICT" and if I try and bootstrap I get "error: environment is already bootstrapped"
[08:23] <gnuoy> any ideas ?
[08:58] <AskUbuntu> how to reproduce an existing environment in juju? | http://askubuntu.com/q/353524
[09:21] <gnuoy> Ok, I had a node that was stuck in the commissioning state which I think juju may have believed was the bootstrap node. Now, thats cleared I was able to destroy-environment
[10:14] <marcoceppi> gnuoy: interesting, I wonder if you run those commands with -v or --debug (or both) if you'd get the actual error from MAAS other than just 409 (which maas uses quite a bit)
[10:15] <gnuoy> marcoceppi, I got no additional info I don't think. Let me see if I have it in my history
[10:20] <gnuoy> no, can't find it I'm afraid
[10:51] <stub> $ sudo juju bootstrap
[10:51] <stub> error: net: no such interface
[10:52] <stub> I've busted something yesterday and no idea what.
[10:55] <marcoceppi> stub: I think it's the interface for local provider
[10:56] <stub> Yeah, I have 'lxc.network.link = lxcbr0' in lxc/default.conf, but that interface no longer exists :-/
[11:11] <marcoceppi> stub: Try re-installing lxc
[11:48] <marcoceppi> hazmat: adam_g: is there any way to tell deployer that a service should be exposed? or does that need to happen outside of deployer?
[11:56] <oatman> anyone know what I get "error: cannot create log collection" when I run `sudo juju bootstrap` ?
[11:56] <oatman> it seems to have stopped working since I rebooted
[12:38] <melmoth> hola !
[12:38] <melmoth> Whatever the service i deploy (provider openstack, grizzly), the service end up with https://pastebin.canonical.com/98533/
[12:38] <melmoth> twisted internal error.
[12:39] <melmoth> this is with juju py (there s currently a problem with juju-core on openstrack provider)
[12:39] <melmoth> any idea what i could do about this ?
[12:47] <marcoceppi> melmoth: not really sure what's going on in the log, it's hard to say
[12:47] <melmoth> indeed.
[12:47] <melmoth> but it does look like a twisted error... so i guess it s something specific to pyjuju.
[12:47] <melmoth> and it seems to occur even before the install hook is fired.
[12:47] <marcoceppi> melmoth: well it's actually getting a 500 error to whatever it seems to be trying to do
[12:48] <marcoceppi> twisted is just the API that juju < 1.0 uses for communication with various API endpoints in the providers
[12:48] <marcoceppi> it's an async framework
[12:48] <marcoceppi> oatman: you still having bootstrap problems?
[12:49] <oatman> marcoceppi, yes I am, I've restarted a few times to no avail
[12:49] <oatman> wait
[12:49] <oatman> wtf it's now working
[12:49] <oatman> does destory environment sometimes not destroy it right?
[12:50] <marcoceppi> oatman: so with the local provider, it attempts to put logs in ~/.juju/local/log (or if you've named the environment something other than local, replace "local" with that name)
[12:50] <oatman> ah
[12:50] <marcoceppi> oatman: what version of juju are you on? 1.14.1?
[12:50] <oatman> 1.14.1-raring-amd64
[12:51] <marcoceppi> destroy-environment should work as expected
[12:51] <oatman> I suspect I'll have it again, I'll be sure to come here when I do
[12:51] <oatman> I'll try and isolate it first
[12:52] <marcoceppi> oatman: when runing bootstrap and getting those errors, run bootstrap with -v and --debug flags to give us a little more insight
[12:52] <oatman> will do
[12:52] <marcoceppi> might also help you pinpoint what's going on
[12:53] <oatman> here's my script that I'm running to rebuild my env:
[12:53] <oatman> sudo juju destroy-environment -y &&
[12:53] <oatman> sudo juju bootstrap -v --debug
[12:53] <oatman> juju deploy mysql &&
[12:53] <oatman> juju expose mysql &&
[12:53] <marcoceppi> yeah, that looks fine
[12:53] <oatman> cool
[12:54] <oatman> I'll keep on going
[12:54] <oatman> I'm very impressed with juju otherwise, honest!
[12:54] <marcoceppi> you might want to sleep a few seconds between destroy and bootstrap, just for good measure
[12:54] <oatman> ah, ok
[12:54] <marcoceppi> otherwise that should work
[12:54] <oatman> I'll add that just to be safe
[12:54] <marcoceppi> on "other" providers, that's not a problem, but local it might be trying to bootstrap too soon after a destroy
[12:56] <oatman> I see
[12:56] <oatman> that makes sense
[13:19] <kentb> so if we are discouraging the use of "deploy --to X" in favor of containerization, how soon will the containerization support be available?  I certainly like the idea rather than using "--to"
[13:37]  * kentb errand then dell lab
[15:01] <Makyo> jamespage, I received a question about deploying openstack, is there a bundle I can point them to?
[16:34] <jcastro> marcoceppi: 20 minute warning!
[16:34] <marcoceppi> jcastro: ack!
[16:40] <jamespage> Makyo, not yet
[16:41] <marcoceppi> jcastro: you going to fire it up?
[16:43] <Makyo> jamespage, alright, thanks.
[16:44] <jamespage> Makyo, I will get to it honest - we have a juju-deployer configuration we are using for testing charm work but it points to all our inflight branches
[16:44] <jcastro> marcoceppi: yeah in ~6 minutes
[16:44] <marcoceppi> jcastro: ack
[16:48] <Makyo> jamespage, no problem, sounds good.  Just had someone asking if I could prove that the openstack deployment from the vid worked, figured that'd be easiest.
[16:53] <jcastro> marcoceppi: https://plus.google.com/hangouts/_/67513881e518abb07e2d4cc3d79041dac96648b9?authuser=0&hl=en
[16:57] <jcastro> . /usr/bin/byobu-reconnect-sockets
[16:59] <jcastro> Ok we're having a charm school on Amulet starting nowish!
[16:59] <jcastro> http://ubuntuonair.com if you wanna follow along.
[17:16] <FilipeCifali> Oh nice
[17:17] <FilipeCifali> my client is trolling me
[17:17] <FilipeCifali> brb
[17:46] <marcoceppi> jcastro: 1.0.1 uploaded to ppa
[17:47] <marcoceppi> jamespage: got a second? I'm trying to patch a huge glaring flaw in the charm-tools package, I can get the source from the ppa, but I noticed in Saucy you made a few fixes. If I bzr branch lp:ubuntu/saucy/charm-tools I get 0.3 source. What should I do to get 1.0.0 so I can patch the packaging?
[17:50] <jamespage> marcoceppi, pull-lp-source charm-tools
[17:50] <marcoceppi> jamespage: i'm on raring, anything else to get the saucy version?
[17:50] <jamespage> marcoceppi, no
[17:51] <marcoceppi> jamespage: awesome, thanks. On a slightly related note, I need to submit a new version of the packaging for charm-tools in saucy
[17:53] <jcastro> marcoceppi: don't forget to respond to the list wrt. the autogenerating interface docs stuff
[17:53] <marcoceppi> jcastro: ack
[17:55] <jamespage> marcoceppi, whats the bug?
[17:55] <jamespage> if you want to fix it in saucy please raise a task for ubuntu as well
[17:56] <marcoceppi> jamespage: https://bugs.launchpad.net/charm-tools/+bug/1231441
[17:56] <_mup_> Bug #1231441: python-markdown missing in the deb packacge's dependencies <Juju Charm Tools:In Progress by marcoceppi> <https://launchpad.net/bugs/1231441>
[17:56] <marcoceppi> jamespage: so I fixed it in the source, added a new incremental update, and built the source (and just built the package and installed in a clean lxc container), I'm about to push to the PPA
[17:56]  * marcoceppi needs to read on raising task for ubuntu
[17:57] <jamespage> marcoceppi, I've been trying to push to the distro first - could you push it to a personal PPA
[17:57] <jamespage> then I can pull from there and update the distro + backport
[17:57] <marcoceppi> jamespage: can do
[17:57] <jamespage> marcoceppi, I raised the task for Ubuntu - remember to reference it in the changelog
[17:58] <marcoceppi> jamespage: reference the bug?
[17:58] <jamespage> (LP: #1231441) - that was the bug will be closed once it gets accepted into distro
[17:58] <_mup_> Bug #1231441: python-markdown missing in the deb packacge's dependencies <Juju Charm Tools:In Progress by marcoceppi> <charm-tools (Ubuntu):New> <charm-tools (Ubuntu Saucy):New> <https://launchpad.net/bugs/1231441>
[17:59] <jamespage> fwiw I'd probably have just fixed that in packaging now that we are so close to releae
[18:00] <marcoceppi> jamespage: when I set the release to saucy in the changelog, and go to build source it says release not found?
[18:00] <marcoceppi> E: charm-tools changes: bad-distribution-in-changes-file saucy
[18:00] <marcoceppi> safe to ignore?
[18:03] <jamespage> yep
[18:03] <marcoceppi> jamespage: uploaded to ppa:juju/stable
[18:04] <jamespage> marcoceppi, urgh - how are you managing to put the same version in for all releases
[18:04] <jamespage> thats generally a bad idea
[18:04] <marcoceppi> jamespage: uhh, I don't know
[18:04] <marcoceppi> rather, I'm really not sure what I just broke
[18:06] <marcoceppi> Sadly, I've just been following the internet as best I can
[18:06] <jamespage> marcoceppi, best to ask
[18:07] <jamespage> marcoceppi, the problem is that the version you just uploaded to PPA is exactly the same version I have to upload to saucy
[18:07] <jamespage> note the use of ~ version on the other packages in the PPA
[18:07] <marcoceppi> jamespage: oh, I didn't realize that would cause an issue
[18:08] <marcoceppi> jamespage: is there a guide that describes how to best manage packages in ppas?
[18:09] <jamespage> marcoceppi, not really
[18:09] <jamespage> marcoceppi, I normally prepare my distro upload then use backportpackage to prepare uploads for PPA
[18:09] <jamespage> that way the distro is always the preference over PPA
[18:10] <jamespage> marcoceppi, I uploaded that to saucy
[18:10] <marcoceppi> jamespage: okay, I think I grasp that. So it'd be do everything I've done up to this point, then run backportpackage to create a backport for each release and put those in ppa?
[18:10] <jamespage> yep
[18:10] <marcoceppi> jamespage: thanks, hope that didn't create too much of a kerfuffle
[18:10] <marcoceppi> jamespage: I'll prepare my releases for tools using that method going forward!
[18:11] <jamespage> marcoceppi, http://paste.ubuntu.com/6193324/
[18:11] <jamespage> thats what I run once I've uploaded a juju-core stable release to distro
[18:11] <marcoceppi> jamespage: awesome, thank you sir!
[18:11] <jamespage> the script can either pull a package
[18:11] <jamespage> or use the dsc locally
[18:12] <marcoceppi> jamespage: if I do that right now for charm-tools am I going to hurt anything?
[18:13] <marcoceppi> jamespage: I've been using the copy package link to create releases in other versions of ubuntu for the ppa, to answer your "how are  you managing" question
[18:43] <rektide> is there any media outpost that links stuff such as people's juju blog posts and projects? looking for a kind of street view, hack-a-day coverage of the wider world?
[18:45] <marcoceppi> rektide: we have this: https://juju.ubuntu.com/community/blog/ which agregates a few juju charmers blogs
[18:49] <rektide> i'm familiar with the planet schema. it's great hearing from direct authors, for sure.
[18:50] <rektide> i like being able to venture out to the slightly further removed too, which is harder
[18:51] <rektide> that's a more critical evaluation than i'm comfortable making, please lend me your support in venturing there
[18:52] <rektide> (i'm remarkably happy with that phrasing asking forebearance. so much better than an apology.)
[19:22] <marcoceppi> rektide: Outside of that, I suppose Google would be best, Google for juju and ubuntu and see what people are doing. If you're intersted in see changes to charms being made we have http://manage.jujucharms.com/recently-changed
[19:34] <rektide> haven't been attending my blogroll as much these past couple weeks- i'd missed the GUI inspector. super awesome! http://www.jorgecastro.org/2013/09/19/here-comes-the-juju-gui-inspector/
[19:52] <marcoceppi> rektide: yeah, the GUI is really turning in to this awesome piece of Juju UX
[19:52] <marcoceppi> I mean, it was already pretty awesome, they set the bar pretty high IMO
[19:52] <rektide> ++
[20:03] <Nik_> Hi. I'm not able to get anyone on #maas channel to hep with the issue I'm having. Is anyone experienced with maas available?
[20:03] <marcoceppi> Nik_: we an certainly try to help you. Are you using juju with maas?
[20:04] <Nik_> yes. though it's a maas tags related issue
[20:04] <Nik_> I'm trying to tag nodes that have 4 or more disks
[20:04] <Nik_> the rule is
[20:04] <Nik_> "definition": "count(//node[starts-with(@id,\"disk\") and @class=\"disk\"]) >= 4",
[20:05] <Nik_> so some machines get tagged
[20:05] <Nik_> but some don't
[20:05] <Nik_> and I verify againt lshw output on one of the machines that don't get tagged
[20:05] <Nik_> xmlstarlet sel -T -t -v 'count(//node[starts-with(@id,"disk") and @class="disk"]) >= 4' /tmp/lshw.xml
[20:05] <Nik_> that outputs "true"
[20:05] <Nik_> so all seems in order, but I'm not sure what approach to take to debug it
[20:06] <marcoceppi> oh boy, this is way above my head sadly
[20:06] <Nik_> well thanks for trying. maybe someone comes around and has an answer :)
[20:08] <marcoceppi> Nik_: you can try asking on http://askubuntu.com with the MAAS tag, it'll at least show up in the MAAS channel and the question will persist
[20:09] <Nik_> thanks maroceppi. I'll try that if I don't get anything
[20:10] <marcoceppi> Nik_: cheers and good luck!