[00:21] <cherylj> mgz: http://paste.ubuntu.com/13840643/
[00:42] <mup> Bug #1524135 opened: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
[00:51] <mup> Bug #1524135 changed: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
[00:54] <mup> Bug #1524135 opened: 'debug-log' fails when logs are large when using db-log <logging> <juju-core:Triaged> <https://launchpad.net/bugs/1524135>
[03:54] <mup> Bug #1524171 opened: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
[04:06] <mup> Bug #1524171 changed: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
[04:12] <mup> Bug #1524171 opened: make preupgrade disk space checks smarter <juju-core:Triaged> <https://launchpad.net/bugs/1524171>
[06:15] <mup> Bug #1524190 opened: Undocumented update-status hook <juju-core:New> <https://launchpad.net/bugs/1524190>
[09:59] <voidspace> frobware: I need coffee and the loo (bad timing)
[10:00] <voidspace> frobware: can we postpone ten minutes?
[10:00] <frobware> sure
[10:17] <voidspace> frobware: omw
[11:18] <voidspace> frobware: just a note
[11:18] <voidspace> frobware: my internet switches over to fibre tomorrow
[11:18] <voidspace> frobware: so I expect to be offline for some of tomorrow whilst the switch happens
[11:25] <mup> Bug #1524297 opened: juju behaviour in multi-hypervisor OpenStack clouds <juju-core:New> <https://launchpad.net/bugs/1524297>
[11:25] <frobware> voidspace, ack
[11:25] <frobware> voidspace, pretty sure you'll like the net result though
[11:26] <voidspace> frobware: :-)
[11:36] <voidspace> frobware: gah, worked out the difference between my code and master
[11:36] <frobware> voidspace, rebase gone awry, or something else?
[11:36] <voidspace> frobware: it's not strictly between my code and master - it's my code and the apiserver/spaces stuff
[11:37] <voidspace> frobware: there is a type mismatch, but we have this horrible piece of code called stateShim that works as an adaptor
[11:37] <voidspace> From the code: stateShim forwards and adapts state.State methods to Backing   method.
[11:37] <voidspace> *sigh*
[11:38] <voidspace> so I'll move the common code first and then adapt the new api to use it
[14:55] <mup> Bug #1524369 opened: i386 github.com/juju/juju/upgrades_test constant overflows int <blocke> <ci> <i386> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1524369>
[15:35] <mup> Bug #1524385 opened: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
[15:38] <mup> Bug #1524385 changed: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
[15:41] <mup> Bug #1524385 opened: local precise cannot be upgraded <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1524385>
[17:04] <dimitern> frobware, hey there
[17:05] <dimitern> frobware, I'm currently bootstrapping with your branch on 1.9 with 1 phys and 2 vlan nics on the vm
[17:06] <dimitern> frobware, I'm not sure though if we should add multiple bridges by default in master yet, rather than do it in maas-spaces first
[17:07] <dimitern> voidspace, o/
[17:07] <voidspace> dimitern: o/
[17:07] <dimitern> voidspace, how's the discovery going ? :)
[17:08] <voidspace> dimitern: stateShim is an abomination
[17:08] <voidspace> dimitern: I'm still moving code into common
[17:08] <voidspace> dimitern: nearly done with the apiserver - don't think I'll get it finished today but nearly
[17:10] <dimitern> voidspace, right, that's great
[17:11] <dimitern> frobware, well, it worked like charm!
[17:11] <voidspace> better in Python isn't it :-D
[17:11] <dimitern> voidspace, indeed :)
[17:13] <dimitern> frobware, uhm.. however it didn't create multiple bridges, just juju-br0
[17:16] <frobware> dimitern, ping
[17:18] <frobware> dimitern, can you pastebin your /e/n/i that didn't work
[17:18] <dimitern> frobware, just a sec
[17:19] <dimitern> frobware, http://paste.ubuntu.com/13863808/
[17:20] <frobware> dimitern, so I was wondering about this a little earlier. the expectation is that eth0.100 becomes juju-br-eth0.100
[17:21] <frobware> dimitern, much in the same way we do for eth0/juju-br0?
[17:21] <dimitern> frobware, it did work and connectivity is there, but I kinda expected I guess, to see juju-br0 for eth0, juju-brXYZ for eth0.50, juju-brUXV for eth0.100 (names of the bridges do not matter)
[17:22] <frobware> dimitern, so just a naming concern?
[17:22] <frobware> dimitern, I was conscious of len(name)
[17:22] <dimitern> frobware, yeah - the point is to be able to enslave an lxc NIC per bridge, such that if the host has IPs on eth0, eth0.50, and eth0.100, the container can mirror that with its eth0, eth1, and eth2 (as seen inside the container)
[17:23] <dimitern> frobware, am I making sense ? :)
[17:23] <frobware> nope
[17:23] <frobware> :)
[17:23] <dimitern> frobware, sorry, let me try again..
[17:23] <frobware> dimitern, any way we can HO or not very practical?
[17:23] <frobware> dimitern, alternatively annotate your pastebin with your expectations
[17:24] <dimitern> frobware, we're in a session and it won't work very well I'm afraid
[17:24] <dimitern> frobware, sure, let me do that
[17:30] <frobware> dimitern, you also said: "I'm not sure though if we should add multiple bridges by default in master yet" - agreed, though the script in my branch is so much better than either on master of 1.25 that I would like to get some of it there soon-ish. Also, I'm not sure what the net affect is addressable containers, which is why I wanted to chat.
[17:31] <dimitern> frobware, right, addressable containers in maas a less of a concern to me, as with the bridges we get addressability (for the primary nic now, with this script for all nics, which is even better)
[17:34] <frobware> dimitern, do we foresee a case where ethN is not active (ie. it is manual) but the vlans associated with it are active (ie. "static/dhcp")? Because that won't bridge atm...
[17:35] <frobware> dimitern, before catering for that case I wanted to know it that's in any way a reality as the parsing would have to hold more state to make this work.
[17:37] <dimitern> frobware, any vlans have to be on an active, link up device
[17:37] <dimitern> frobware, if the raw device is down, there won't be any possibility to pass vlan traffic on it
[17:38] <dimitern> frobware, I'm preparing /e/n/i example, just a few minutes and I'll paste it
[17:38] <frobware> dimitern, so from a re-rendering perspective if the raw device is not active we won't add a bridge. or should not.
[17:38] <frobware> thx
[17:53] <dimitern> frobware, we're making some experiments with dooferlad here to figure out what we can do with bridges and vlans
[17:55] <dimitern> frobware, if it gets late, don't stay up :) we'll stay in touch by mail
[17:55] <dimitern> frobware, the open question is can "juju-br0.50" be both a vlan virtual device AND a bridge we ca use for container nics
[17:56] <dimitern> or it has to be e.g. juju-br0-50 as a bridge, which has vlan-raw-device and vlan_id on
[18:06] <frobware> dimitern, the latter was mostly my question when I was doing this; I'll experiment a little after dinner too.
[19:45] <cherylj> can I get a review?   http://reviews.vapour.ws/r/3346/
[20:17] <mup> Bug #1524190 changed: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
[20:20] <mup> Bug #1524190 opened: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
[20:32] <mup> Bug #1524190 changed: Undocumented update-status hook <juju-core:Invalid> <https://launchpad.net/bugs/1524190>
[21:47] <menn0> thumper: git merge-base upstream/<parent-branch> HEAD should give you the commit that's the common ancestor
[21:47] <menn0> thumper: then git log <sha>.. or git log <sha>..
[21:47] <menn0> diff
[22:00] <perrito666> how can I find out what provider is one running? never thought of that
[23:03] <mup> Bug #1494951 changed: Panic "unexpected message" in vivid and wily tests <bug-squad> <ci> <intermittent-failure> <panic> <unit-tests> <wily> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1494951>
[23:03] <mup> Bug #1524527 opened: deploy incompatible charm using --to should error earlier <juju-core:Triaged> <https://launchpad.net/bugs/1524527>
[23:14] <jw4> wq
[23:16] <perrito666> jw4: vi ftw
[23:18] <jw4> heh
[23:18] <jw4> don't tell katco
[23:43] <perrito666> seems that we didn't thought much how to upgrade stuff in the provider side
[23:47] <rick_h_> cccccceefhiubfgdelvcctfftfklkugnjciiefbtcvkl
[23:48] <perrito666> rick_h_: yeah, I agree