=== thumper is now known as thumper-afk === bentzy_ is now known as bentzy === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === anthonyf is now known as Guest97002 [12:23] Juju with multiple NICs on MAAS with openstack bundle using os-*-networks - needs work. [12:26] Specifically, I think I am seeing an issue with how juju-core decides which of it's local IP addresses are the "private" address. If I am using more than 1 RFC1918 subnet it looks like it just picks one either randomly or using a questionable decision. I am also now seeing a difference in the address reported from an LXC container Vs a proper host. [12:28] in one of my deployments I am using 192.168.92.x as the management network and a bunch of 172.16.x.x subnets as the additional networks, but when I configure the addresses manually on LXC containers juju suddenyll switches the management address to the first 172.16.x.x address set up. [12:29] So, it seems like it is just picking the address with the lowest numerical value. === liam_ is now known as Guest88779 [12:31] But on the other physical and KVM hosts in the deployment, with a proper NIC, keep the original management network address in the 192.168.92.x range [12:34] Then another deployment, very similar, but using different subnet ranges, the LXC containers are picking the public address instead of one of the RFC1918 addresses, which starts with 31.28.x.x, which would seem to agree that it is the lowest numerical address when it is in an LXC container, but not on a host [12:38] The different behaviour is a bit odd, I would have expected the behaviour from juju agent to be the same on a container vs a host. [12:39] Anyone with any insights please let me know, otherwise I'll try and tie it down and fill in a bug report. [12:44] dweaver: bug 1188126 and bug 1435283 [12:44] Bug #1188126: Juju unable to interact consistently with an openstack deployment where tenant has multiple networks configured

[12:44] Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment

[12:46] mgz, that looks like what I am seeing, thanks. [12:49] Actually, reading through those, it doesn't quite match. I am talking about MAAS deploying openstack so 1188126 doesn't match. [13:30] hi coreycb, can you give a preliminary feedback on this pair of mps?: https://code.launchpad.net/~1chb1n/charm-helpers/amulet-relations-settled/+merge/263724 ... https://code.launchpad.net/~1chb1n/charms/trusty/cinder-ceph/next-amulet-relation-settle/+merge/263716 [13:31] coreycb, that is wrt the relations not settling before tests start thing; it's actually an observable issue with all of the os-charm amulet tests, and i believe this squashes that. [13:37] beisner, sure [13:37] beisner, yeah that's a good thing to fix [13:44] coreycb, appreciate it [13:47] beisner, commented on the c-h one [13:47] beisner, looks good for the most part [13:52] coreycb, ack thx. see inline on c-h. === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [16:06] hazmat: do you have a second to reflect upon the situation in python-jujuclient head? [16:06] it looks like there are some tests without implementations? [16:06] or incomplete ones? [16:07] like KeyManager and HAFacade? [16:07] * whit has some small bug fixes to commit and is finding head... confusing === lukasa is now known as lukasa_away [17:07] coreycb, fyi, c-h adjusted, cycling without the test-and-test-again thing. i suspect that will be just fine. === lukasa_away is now known as lukasa [17:10] beisner, ok looks good === lukasa is now known as lukasa_away === lukasa_away is now known as lukasa === makyo_ is now known as Makyo === Makyo is now known as makyo_ === kadams54 is now known as kadams54-away === makyo_ is now known as Makyo === lukasa is now known as lukasa_away [19:19] stub: you around? [19:28] aisrael: pretty sure it's 2:30am stub time === lukasa_away is now known as lukasa [19:29] tvansteenburgh: oh, right! [19:39] coreycb, ok the bot's test was ok. i'm going to kick off a zillion of them to make sure that squashes le ole race. https://code.launchpad.net/~1chb1n/charms/trusty/cinder-ceph/next-amulet-relation-settle/+merge/263716 [19:41] beisner, code looks good [19:44] The office hours hangout for the top of the hour is here: https://plus.google.com/hangouts/_/hoaevent/AP36tYd8ofby2UDDUf0JW9Z5mNcoj5hhPpeMwud1D3mLnw6zwLcxeQ?authuser=0&hl=en [19:44] for anyone who wants to join [19:58] for everyone else, we're having Juju Office Hours in about 2 minutes [19:59] feel free to listen in on http://ubuntuonair.com [19:59] or participate by joining: https://plus.google.com/hangouts/_/hoaevent/AP36tYd8ofby2UDDUf0JW9Z5mNcoj5hhPpeMwud1D3mLnw6zwLcxeQ [20:19] https://blueprints.launchpad.net/ubuntu/+spec/topic-w-openstack [20:20] https://wiki.ubuntu.com/ServerTeam/CloudArchive [20:22] anyone running juju out of tmpfs? [20:28] question: does --metadata-source == $JUJU_HOME for bootstrap? [20:28] cholcombe: on the root node? [20:29] whit: yeah i'd like to spin up my containers in ram :) [20:29] whit, i switched from a laptop that had an ssd back to a desktop that has an hdd and it's so damn slow now [20:29] but... i have 24GB of ram coming tomorrow :) [20:30] that 15.04 release note doc, fyi: https://wiki.ubuntu.com/ServerTeam/OpenStackCharms/ReleaseNotes1504 [20:45] cholcombe: so i couldn't help but notice you wrote autodock [20:45] haha [20:45] yup [20:45] that was like 2yrs ago now i think [20:45] how long were you planning on keeping this from me? [20:45] :D [20:45] finding it useful? [20:46] i can't believe how many stars it got. it's incredible [20:46] well, write something ot scratch your itch, chances are you're scratching someone elses itch [20:46] it would be stellar to get your feedback on some of the stuff we have brewing in tupperware these days [20:46] this is true [20:46] tupperware? [20:47] thats our code-name for all the stuff we're working on in new workloads - aka, containers, aka tupperware [20:47] its a meta thing [21:38] when i destroy/recreate my local environment sometimes the all-machines.log file doesn't get recreated [21:38] and juju debug-log fails === kadams54 is now known as kadams54-away