[04:21] <jrwren> oh awesome. rsync -e 'juju ssh' works.
[10:44] <jrandall_> this may be a stupid question, but if I upgrade an openstack nova-compute charm while the hypervisor is running instances, what will happen to the running instances?
[12:19] <jcastro> lazyPower, can you fix your email metadata here: https://api.jujucharms.com/charmstore/v4/trusty/shoutcast-1/archive/metadata.yaml
[13:23] <stub> Can someone with a unit on a public cloud do 'juju run --unit=foo/0 unit-get --format=json public-address' for me? I need to know if that is a dns name, ip address, or something else.
[13:25] <stub> Pretty certain it will be the ip address, which means something else is the problem (but still worth checking)
[13:40] <tvansteenburgh> > juju run --unit=ubuntu/0 'unit-get --format=json public-address'
[13:40] <tvansteenburgh> "54.198.21.204"
[13:40] <tvansteenburgh> stub ^
[13:46] <stub> ta.
[13:46] <stub> Do I need to do anything before services can use the public-address ? I've got a java app failing to bind to the public address, but other parts of it are happily binding to the private address.
[13:47] <stub> It might be before the port-open is called
[13:47] <mbruzek> stub: yeah the public clouds are all behind firewalls
[13:48] <mbruzek> stub: the public-address is not available until open-port is called
[13:48] <stub> Hmm... so my services framework charm is starting the configured service in the install hook,  before the start hook is called.
[13:50] <Spads> stub: yeah, the services framework doesn't care which hook it actually is, so long as all conditions are met
[13:51] <Spads> stub: the new charm helpers framework will be a bit more explicit and less magical about start/stop, though
[13:53] <stub> Nope, my fault. The default 'start' option in a service definition is [host.service_start, services.open_ports], and I overrode it. So my ports never got opened, and things explode the first time my public address != private address
[13:54] <stub> Although looking at that default, it should be the other way around if this is indeed the problem.
[13:56] <Spads> I am aha
[13:57] <Spads> er, aha!
[14:04] <stub> Will will eventually re-implement Ansible.
[14:33] <lazyPower> jcastro: fix released, thanks for catching that
[14:33] <jcastro> <3
[14:44] <stub> tvansteenburgh, mbruzek: Can either of you kick off the lp:~stub/charms/trusty/cassandra/spike tests again? I think I've sorted things, and local tests are ok.
[14:44] <mbruzek> stub: sure
[14:45] <mbruzek> stub kicked
[14:45] <mbruzek> stub: they are all the active processes here: http://juju-ci.vapour.ws:8080/
[14:51] <stub> ta
[14:52] <mbruzek> stub, I just kicked off tests for lazyPower but they should be queued behind your.
[15:00] <apuimedo> lazyPower: is it possible to deploy lxc services that have to talk to each other on different hosts?
[15:00] <lazyPower> apuimedo: you'll need to do some SDN
[15:00] <lazyPower> apuimedo: http://blog.dasroot.net/container-networking-with-flannel.html
[15:00] <apuimedo> SDN? What is that :P
[15:01] <apuimedo> xD
[15:01] <mbruzek> software defined network
[15:01] <apuimedo> I was joking. I work at Midokura (we provide SDN)
[15:02] <lazyPower> apuimedo: baseline answer without sdn: Nope - host only communication :)
[15:02] <mbruzek> I was just reminding myself.
[15:02] <apuimedo> yeah, that's what I guessed ;-)
[15:02] <lazyPower> apuimedo: baseline answer with midonet: Network all teh things!
[15:02] <apuimedo> :P
[15:02] <apuimedo> but who will deploy the MidoNet that is used by Juju to deploy MidoNet
[15:03] <apuimedo> it's turtles all the way down
[15:03] <lazyPower> thats just it, we're reconfiguring the LXC bridge with the flannel charm
[15:03] <lazyPower> the thing to be aware of, if you're reconfiguring LXC - you need to config that software bridge *before* the service is up
[15:04] <apuimedo> lazyPower: do you use that config file for defining the interfaces for lxc like nova-flex does?
[15:05] <lazyPower> we've targeted 2 network devices - lxcbr0 and docker0 - we dont support other networking changes in those charms.
[15:05] <lazyPower> the rest is leveraging default routes to pick the proper device to send the data OTW
[15:07] <apuimedo> good
[15:08] <lazyPower> mbruzek: when you're done fixing up /42 - i have /20 on the kubes charm rdy for rev - https://github.com/whitmo/charm-kubernetes/pull/20
[21:30] <dpb1> anyone know how to silence the bootstrap on maas from this "ARNING no architecture was specified, acquiring an arbitrary node"
[21:31] <dpb1> *WARNING