=== jcw4|afk is now known as jcw4
[00:35] <mwhudson> er
[00:35] <mwhudson> what might cause bootstrap to hang?
[00:35] <mwhudson> local provider
=== scuttle|afk is now known as scuttlemonkey
[01:46] <thumper> mwhudson: hey
[01:46] <thumper> mwhudson: which version?
[01:46] <thumper> mwhudson: unfortunately it can be one of several things
[01:46] <thumper> it may have the appearance of hanging
[01:46] <thumper> or it may really be hanging
[01:46] <thumper> we have fixed the latter in recent releases
[01:50] <mwhudson> this was pretty hung
[01:50] <mwhudson> but it was an automated test, so i just killed it and started again
[01:50] <mwhudson> also: not local provider, manual provider
=== mup_ is now known as mup
=== psivaa_ is now known as psivaa
=== viperZ28_ is now known as viperZ28
=== uru is now known as urulama
=== CyberJacob|Away is now known as CyberJacob
=== rharper is now known as rharper_brux
[06:56] <gnuoy`> jamespage, neutron-api nsx mp https://code.launchpad.net/~gnuoy/charms/trusty/neutron-api/nsx/+merge/238237
=== gnuoy` is now known as gnuoy
=== CyberJacob is now known as CyberJacob|Away
[07:35] <jamespage> gnuoy, ack - looking
[07:35] <jamespage> gnuoy, I think we should probably switch to using nsx-* for the config options
[07:35] <jamespage> gnuoy, so that its all inline with upstream naming
[07:36] <gnuoy> jamespage, but not inline with nsx transport charm
[07:36] <jamespage> gnuoy, hmm
[07:36]  * jamespage muses this issue
[07:36] <gnuoy> jamespage, I think it makes sense to switch to nsx
=== rogpeppe2 is now known as rogpeppe
[07:37] <jamespage> gnuoy, hmm
[07:37] <jamespage> so I started a renamed charm - https://code.launchpad.net/~openstack-charmers/charms/trusty/nsx-transport-node/trunk
[07:37] <jamespage> but I've held off publishing that due to lack for 14.04 support from upstream as yet
[07:38] <jamespage> gnuoy, lets switch neutron-api to nsx-* now otherwise we are stuck with it for ever
[07:38] <jamespage> and as its >= icehouse it really is nsx!
[07:38] <gnuoy> agreed, will do
[07:40] <jamespage> gnuoy, added a comment to the mp - one of the config options is obsolete
[07:40] <gnuoy> ta
[07:49] <gnuoy> jamespage, mp updated
=== jacekn_ is now known as jacekn
=== Guest61804 is now known as rcj
=== rcj is now known as Guest90815
=== smoser` is now known as smoser
=== Guest24850 is now known as balloons
[13:40] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charms/trusty/nova-compute/fixup-rbd-libvirt/+merge/238296
[13:48] <gnuoy> jamespage, did you see dosaboys comment on that ?
[13:55] <gnuoy> jamespage, approved
[13:55] <jamespage> gnuoy,
[13:55] <jamespage> ta
=== rcj_ is now known as rcj
=== mgz_ is now known as mgz
[17:00] <bladernr_> Hey, I have a question I haven't been able to find an answer for yet.  How would I use Juju to deploy into multiple physical zones on a single MAAS cluster?  e.g., lets say I have one maas server (region and cluster on one machine) and two physical zones with some nodes on each.
[17:01] <bladernr_> Any docs on how to tell juju to bootstrap them separately, or to bootstrap and then deploy one workload to zone A and one workload to Zone b?
=== balloons is now known as Guest18783
=== Guest18783 is now known as balloons_
=== balloons_ is now known as balloons
=== roadmr is now known as roadmr_afk
=== CyberJacob|Away is now known as CyberJacob
=== wendar_ is now known as wendar
=== jcw4 is now known as jcw4|afk
=== perrito6` is now known as perrito666
=== thumper is now known as thumper-dogwalk
[21:30] <bic2k> I upgraded to juju 1.20.7 two weeks ago, new machines are now reporting private ip's as their public ips. An attempt to upgrade to 1.20.9 appears to have left the cluster in a very invalid state.
=== wallyworld_ is now known as wallyworld
[21:44] <marcoceppi_> bic2k: sorry to hear about that, what cloud is this?
[21:45] <bic2k> marcoceppi_: AWS. It looks like it got part way through upgrading from 1.20.7 to 1.20.9
[21:45] <bic2k> marcoceppi_: I'm finishing that by updating the /var/lib/juju/tools symlinks and restarting the services
[21:46] <bic2k> once I get machine-0 running I hope it can resolve the rest of machines
[21:47] <bic2k> any way to tell how far along the juju-upgrade is? We can now access juju again, and all but two machines are updated. So that looks like it worked.
=== uru_ is now known as urulama
[21:53] <marcoceppi_> bic2k: not really, in the next version of juju, after 1.21, we'll be adding better state exposure like upgrading, installing, etc
[21:54] <bic2k> marcoceppi_: cool, I'm wondering if there is an official guide related to manually finishing an upgrade. O
[21:55] <bic2k> I have done it a few times now, it isn't really hard, but it does help if things get stuck.
[21:55] <bic2k> I could write something up someplace or blog it.
[21:55] <marcoceppi_> bic2k: please write something up!! we don't have anything. If you do blog it up (or place it in the docs) that would be fantastic
[21:56] <marcoceppi_> https://github.com/juju/docs is where the docs live, this would be super helpeful in the troubleshooting section
=== thumper-dogwalk is now known as thumper
=== jcw4|afk is now known as jcw4
=== CyberJacob is now known as CyberJacob|Away
=== scuttlemonkey is now known as scuttle|afk
=== CyberJacob|Away is now known as CyberJacob
[23:42] <mwhudson> is there some way i can prep a disk image so that after installing it, juju deploying to a container on it will be faster?
[23:43] <mwhudson> well, obviously there must be
[23:44] <mwhudson> but can someone tell me what it is? :)
=== roadmr_afk is now known as roadmr
=== CyberJacob is now known as CyberJacob|Away