[00:50] <bradm> anyone about who can help with a problem deploying something in juju?  I'm getting an odd traceback when I try to add a service using juju deployer
[01:17] <LinStatSDR> What is the error bradm
[01:19] <bradm> LinStatSDR: http://pastebin.ubuntu.com/9276609/, using a juju deployer config
[02:19] <lamont> I say juju upgrade-charm and the bundle it delivers is the _old_ contents of the charm directory.. (juju 1.16.5)  - thoughts?
[04:14] <captine> Hi all.  Can anyone point me to a write up (if available) of using Juju and MAAS in a corporate environment.  My company currently has an IBM pureflex running Hyper-V on all nodes and VM's on them.  All is managed as if the machines were physical e.g. no automated provisioning etc.  I am just trying to see if Juju is more for dev type people or if there is a usecase for it in a corporate where vm's dont chane much.
[11:57] <mgz> gnuoy: how busy are you today?
[11:57] <gnuoy> mgz, that seems like a loaded question...
[11:57] <gnuoy> mgz, I'm working on adding a feature so I can take a pause
[11:58] <mgz> so, I was looking on the train at the 'right' way of doing devel tools with juju and simplestreams
[11:58] <mgz> I think I have all the bits down now
[11:59] <mgz> so, if you want to retry the windows workloads tools part the right way, we could have a quick bash at that
[11:59] <gnuoy> ok, I have a call in 1 min, then I was hoping to grab some lunch but it'd be great to catch up about that this afternoon if taht's ok?
[11:59] <mgz> that works for me, poke when available
[13:37] <gnuoy> mgz my world is running behind, I'm heading to lunch now
[14:05] <hazmat> bradm, do you have a pastebin for the traceback?
[14:05] <hazmat> bradm, what version of juju?
[14:06] <hazmat> bradm, do you have a service 'infra' in your deployer config?
[14:17] <gnuoy> mgz, I'm champing at the bit
[14:45] <mgz> gnuoy: okay, I'm back from lunch too
[14:47] <gnuoy> mgz, ok, hit me
[14:49] <mgz> so, rough plan
[14:49] <mgz> make tools tarballs for a trunk juju version for trusty and windows
[14:49] <mgz> generate tools streams
[14:50] <mgz> bootstrap with --metadata-source pointing at that directory
[14:52] <gnuoy> mgzAre you suggesting I bootstrap with 1.20.12 tools?
[14:55] <mgz> gnuoy: no
[14:56] <mgz> we bootstrap with the devel, we just need to give bootstrap the path to our carefully constructed simplestreams version
[14:57] <gnuoy> ok
[15:02] <mgz> gnuoy: do you want to ssh into a box I have to poke things? or some other means to pair on this?
[15:03] <gnuoy> mgz, I need to disappear for 20mins but I'll be back after that. I'd like to get you access to the lab I'm working in tbh
[15:03] <mgz> ah, I should check if I have the vlan stuff set up on here
[15:31] <gnuoy> mgz, do you have vpn access to the qalab ?
[15:32] <gnuoy> mgzare you happy with juju-1.21-beta3-trusty-amd64.tgz juju-1.21-beta4-win2012hvr2-amd64.tg being the tools?
[15:37] <mgz> gnuoy: they need to be the same beta
[15:40] <gnuoy> mgz so there's a trusty beta 3 but no windows and a windows beta 4 but no trusty, right ?
[15:42] <mgz> gnuoy: there are both, it's just a question of putting in the same versions
[15:43] <mgz> sec, I just need to restore all my sessions (X login had a bit of a fit)
[15:43] <gnuoy> mgz, Are you saying that there is trusty beta 4 out there somewhere ?
[15:43] <mgz> there is trunk 1.21 which reports as the upcoming beta4
[15:44] <gnuoy> mgz, I'm looking at https://streams.canonical.com/juju/tools/devel/ fwiw
[15:44] <mgz> gnuoy: actually, let's just use tools from this job: <http://reports.vapour.ws/releases/2121>
[15:47] <gnuoy> mgz, Build Artifacts  empty  <- on the few I've tried
[15:50] <mgz> gnuoy: `wget http://data.vapour.ws/juju-ci/products/version-2121/win-client-build-installer/build-1325/juju-1.21.0-win2012-amd64.tgz`
[15:51] <mgz> gnuoy: `wget http://data.vapour.ws/juju-ci/products/version-2121/publish-revision/build-1237/juju-core_1.21.0-0ubuntu1~14.04.1~juju1_amd64.deb`
[15:51] <mgz> then `dpkg-deb -x juju-core_1.22-alpha1-0ubuntu1~14.04.1~juju1_amd64.deb extracted-bin
[15:52] <mgz> and get the jujud binary from in there for the trusty/amd64 combo
[15:53] <mgz> gnuoy: then my instructions from earlier has `tar -cf tools/devel/juju-`~/go/bin/juju version`.tgz -C ~/go/bin jujud` - but this is going to be different for these two tools
[15:54] <mgz> then we put the two tarballs in tools/devel/ under our working dir
[15:54] <mgz> and run `juju-metadata --debug generate-tools --clean --stream devel -d .`
[15:55] <mgz> check that the streams data generated has both tools
[16:00] <gnuoy> mgz ok so far: http://paste.ubuntu.com/9284701/
[16:03] <gnuoy> let me redo with the devel dir
[16:03] <mgz> gnuoy: okay, do releases rather than devel (pretty much the same, just different environments.yaml setting fun)
[16:03] <mgz> releases is fine
[16:04] <mgz> I did devel mostly because it seemed more fun
[16:04] <gnuoy> mgz happy for me to: juju bootstrap --metadata-source /var/lib/jenkins/.juju/tools  ?
[16:05] <mgz> gnuoy: next step is bootstrap with that `juju --debug bootstrap --metadata-source . -e $ENV`
[16:05] <mgz> gnuoy: I think not with the tools, it's the dir containing the tools
[16:05] <gnuoy> ack
[16:06] <mgz> I'd use a big buffer or tee out/err somewhere
[16:06] <mgz> because you need to read a lot of simplestreams junk if something's not right
[16:07] <mgz> after that it's add-machine with da windows
[16:25] <mgz> gnuoy: how it going?
[16:25] <mgz> I'll need to reboot for standup ina sec so will be off irc briefly
[16:25] <gnuoy> mgz one explosion down to the tgz not really being z
[16:25] <gnuoy> rebootstrapping now
[16:28] <mgz> yeah, I did .tar.gz first time around... which tar did z for me, but juju metadata refused to acknowledge
[16:29] <gnuoy> mgz, bootstrap done.Happy for me to go on to the windows deploy ?
[16:32] <gnuoy> me goes for it
[16:33] <mgz> go for it
[16:33] <gnuoy> arggh, I missed a v out of the windows tools name
[16:34] <mgz> gnuoy: whoops
[16:34] <mgz> I'll be back in ~10 or so, tell me how you get on
[16:35] <mgz> (and yes, this streams assembly stuff is all very error prone... does juju-metadata validate-tools help at all?
[16:35] <mgz> )
[16:46] <gnuoy> mgz http://paste.ubuntu.com/9285206/
[17:30] <mgz> gnuoy: how goes?
[17:31] <gnuoy> mgz, do you see my pastebin?
[17:31] <gnuoy>  http://paste.ubuntu.com/9285206/
[17:48] <mgz> gnuoy: looking now
[17:50] <mgz> gnuoy: can you kill that machine, do set-env with the debug log config (we should have supplied on bootstrap really..) and look at machine-0.log
[17:51] <gnuoy> mgz debug was set in the environments.yaml
[17:52] <mgz> okay, ace, then just look at machine-0.log for the provisioner bit that says "no matching tools available"
[17:54] <gnuoy> mgz I've popped the log on chinstrap
[17:56] <mgz> you're liam on chinstrap? not gnuoy?
[17:58] <mgz> 2014-11-28 16:45:46 DEBUG juju.environs.simplestreams simplestreams.go:428 read metadata index at "https://streams.canonical.com/juju/tools/streams/v1/index2.json"
[17:58] <mgz> 2014-11-28 16:45:46 DEBUG juju.environs.simplestreams simplestreams.go:436 index file has no data for product name(s) ["com.ubuntu.juju:win2012hvr2:amd64" "com.ubuntu.juju:win2012hvr2:i386" "com.ubuntu.juju:win2012hvr2:armhf" "com.ubuntu.juju:win2012hvr2:arm64" "com.ubuntu.juju:win2012hvr2:ppc64el"]
[17:59] <mgz> graaaaa
[19:43] <themonk> lazyPower, hi
[19:43] <themonk> i am getting a strange error after updating juju
[19:44] <themonk> few hours back
[19:44] <themonk> this is the error: WARNING discarding API open error: unable to connect to "wss://172......:17070/environment/4aaa9a83............/api" ERROR Unable to connect to environment "amazon". Please check your credentials or use 'juju bootstrap' to create a new environment.
[19:44] <themonk> credentials are ok
[22:23] <lkraider> hello, we are looking into extending juju to notify charm relations when their machines restart (right now only config-changed is called when the machine boots). Any pointers?
[22:39] <lkraider> we want to call relation-changed when a machine reboots
[22:39] <lkraider> is this possible?
[22:40] <sarnold> lkraider: i'm just a spectator, but that feels like it'd introduce a huge amount of overhead when machines reboot... running scripts to take that unit out of service in all N relations that know about it might take longer than the machine rebooting will take..
[22:41] <sarnold> lkraider: I suspect providing a unit-reboot hook would let charms that care about it handle it and let other charms ignore it without the overhead..
[22:43] <lkraider> @sarnold I mainly want to update the old relations with new IP when the machine reboots
[22:44] <sarnold> lkraider: aha :)
[22:46] <lkraider> sarnold: am I right in that there's no provision in Juju right now for that?
[22:47] <lkraider> sarnold: this is my understanding of the hooks as they are now: http://stackoverflow.com/a/25980368/324731
[22:47] <sarnold> lkraider: sorry, I'm too much of a bystander for that -- I wouldn't be surprised if semi-stable IPs are assumed though, and teardown / re-provision in the case of new unit IP addresses..
[22:48] <sarnold> lkraider: nice graph :)
[22:51] <lkraider> sarnold: yep, I found the docs confusing so I made it from what I gathered
[22:51] <lkraider> sarnold: not sure if its 100% accurate tho
[22:54] <lkraider> sarnold: thanks for your help, I'll try asking sometime later to the folks here again
[22:54] <sarnold> lkraider: good luck :)