=== defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === thumper is now known as thumper-afk === marlinc is now known as marlinc|away === TheRealMue is now known as TheMue === marlinc|away is now known as marlinc === marlinc is now known as marlinc|away === thumper-afk is now known as thumper === marlinc|away is now known as marlinc === rogpeppe1 is now known as rogpeppe === marlinc is now known as marlinc|away [11:06] A quick question. Canonistack is not launching instances reliably. Is there any way I can kill a machine and tell juju to try to start another node. juju destroy-unit/machine/service do not work reliably. [11:07] you mean juju terminate-machine ? [11:09] It marks it as dying but it does not really terminates it because it never started up [11:09] so now I am stuck with an inconsistent state === marlinc|away is now known as marlinc [12:08] E: Unable to locate package juju-core | http://askubuntu.com/q/310604 [13:29] hey jam, silly question [13:30] but do you know how we ended up with packages in the PPA being built differently than in distro? [13:30] I am wondering if we did that on purpose or if it's just a consequence of something [13:30] jcastro: because the PPA was done first, but isn't "legitimate" for how they wanted the build to be done in Ubuntu [13:31] ah ok [13:31] jcastro: so it got fixed for official builds, and the changes need to be applied to the PPA [13:31] but there is some reason it isn't trivial to do it [13:31] mgz knows a bit more. [13:35] I was just curious [13:36] Guys, can you explain me one very basic thing? Is it supposed that service instance would be stopped/started or rebooted? [13:40] jcastro: the ppa generation wasn't updated to use the new packaging, I'm going to try to sync up with dave on fixing that === huats_ is now known as huats [13:47] pavel: could you clarify that a bit? I'm not sure I understand what you're saying [13:48] I mean, what if I stop and start instance with service deployed by juju in aws console [13:48] marcoceppi, what will happen then? [13:49] pavel: Depends on which version of juju you use [13:49] 0.7 [13:51] If you're using juju <= 0.7 Juju will provision a new unit to replace it when you stop an instance. In juju >= 1.0 Juju won't try to replace the stopped unit, but I'm not 100% certain things will "come back up" properly. In that the juju service on the unit will start, but the start hook won't be explicitly executed so your service will need to install itself as an upstart or init script properly configured to start on machine up. Also [13:51] , relations might go haywire as well [13:55] I see [13:56] so there is no predictable behavior for this case [13:56] and I should suppose that instance always run [13:56] pavel: not at the moment, no real predicatbility. It's best to remove and re-add units instead of turning them on and off via the console [13:56] because my problem is that I didn't find a way to increase root partition size on AWS with JuJu, so I use ephemerial storage mounted to /mnt === wedgwood_away is now known as wedgwood [15:15] Hi all -- is there a way in juju-core to associate a public IP through juju with just one service or unit? [15:18] nope, that would be handy though [15:21] I'm working on the addressing code currently, so if you have use-cases I'd really like if you could send a message to the list or something so they get recoreded === marlinc is now known as marlinc|away === defunctzombie_zz is now known as defunctzombie === marlinc|away is now known as marlinc === marlinc is now known as marlinc|away === hatch_ is now known as hatch === defunctzombie is now known as defunctzombie_zz === adam_g_ is now known as adam_g === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === wedgwood is now known as wedgwood_away