[00:37] thumper: i remember why I lost interest in using ppc and went back to intel for testing juju with go 1.5 [00:37] ppc is _SOOOO SLOW_ [00:37] which is partly the imaturity of the compiler [00:37] and mainly because the vm's that we have are underpowered [00:39] this is not a problem with the s390x port, at least :-) [02:16] Bug #1534307 changed: juju-metadata plugin tests are currently being skipped on Windows [02:16] Bug #1535165 opened: Unable to create hosted environments with MAAS provider [02:55] Bug #1534238 changed: juju debug-log fails with 1.26alpha3 and lxd [04:12] mwhudson: omg rockne is sloooow [04:12] did you say that s390 was fast [04:22] * thumper is done [04:22] laters [08:52] fwereade: howdy. I've taken care of most of your review comments for http://reviews.vapour.ws/r/3541/ and the code is much better for it. thanks! [08:53] fwereade: can you please answer my one query about one of your suggestions some time during your day today? (the second remaining open issue) [09:20] voidspace, http://reviews.vapour.ws/r/3550/ - when you have a moment. I'll also reciprocate with your outstanding review. [09:29] frobware: mine's been done, but thanks [09:29] frobware: will look shortly, wrestling with merged tests at the moment :-/ [09:29] voidspace, ooops... sorry! [10:02] voidspace, standup? [10:02] frobware: omw [10:19] voidspace, http://reports.vapour.ws/releases [10:33] Hi all - hopefully quick Q: I have a subordinate charm which needs to know the public-address of every primary charm with which it and its peers are related during the update-status hook. i.e. Every subordinate needs to have a full list of the primaries. [10:33] What is the right way to achieve this? [10:33] Do I need to gather the public-address from the related primary on each subordinate (during the relation-joined hook), then send that data across the peer relation and store it for use during the update-status hook? [10:34] This feels like a really good way to get inconsistent data on each subordinate, but I couldn't think of another way to do it. [10:46] OK - I guess that wasn't a quick Q. I'm heading off for the evening; hopefully someone can suggestion better than mine. [10:46] s/can /can think of a / [11:48] good morning all [12:28] perrito666, morning [12:42] frobware: heh, found the magic combination [12:42] frobware: of the correct versions of bundlechanges, charm.v6, charmrepo.v2 and charmstore.v5 [12:43] frobware: for everything to build [12:43] let's see if tests pass [12:44] voidspace, which version won? [12:46] frobware: some are maas-spaces and some are master [12:46] I should have just done a blame and taken the most recent of each [12:46] I still get test failures [12:46] ah, because I removed a line [12:46] I'll add it back [12:47] frobware: the trouble was that it took time to work out *which* dependencies were the problem [12:51] frobware: and tests pass! [12:53] voidspace, great [12:53] voidspace, which version of charm-store won? [12:54] frobware: I think charmstore is master [12:54] frobware: but charm is maas-spaces [12:56] frobware: so this is the PR, it's only 8000 lines of diff [12:56] frobware: https://github.com/juju/juju/pull/4139/files [12:56] frobware: if you can check it in the next hour or so we can land it [12:56] ;-) [12:57] voidspace, at line 1... [12:58] * frobware is now at lunch. :) [12:58] :-D [12:58] voidspace, will take a look later today. still trying to find out how to get, or why we get, multiple dns-nameserver entries. [13:00] frobware: I'll check it first anyway [13:00] frobware: more eyes needed, definitely though - but I want to look through the maas changes on master [14:14] is there some documentation on how to use the new controller/environment setup? [14:24] bogdanteleaga, heh, good question. I've been bouncing between maas-spaces and master today, and getting confused between killing an environments. [14:36] Bug #1535328 opened: TestUniterRelationErrors fails

[15:14] bogdanteleaga: https://jujucharms.com/docs/master/wip-systems [15:14] but that hasn't been updated with the new terminology and commands [15:14] systems are now called controllers [15:14] and all the commands are flat, like juju kill-controller rather than juju system kill [15:19] evilnick: how long would it take to update that page? https://jujucharms.com/docs/master/wip-systems [15:19] evilnick: I could take a pass at updating the commands and terminology tonight [15:20] cherylj, if you wanted to do that it would be most helpful [15:20] it isn't something we have been working on or near the top of the list for juju stuff [15:21] (in terms of when we do it, not how important it is) [15:24] evilnick: yeah, I'll take a pass at updating it tonight [15:32] cherylj: thanks [16:13] voidspace, we might as well pass up on the network interlock as jay may not be there (US holiday) [16:18] voidspace, http://reviews.vapour.ws/r/3564/ - this is a forward port from 1.25 to master. [17:34] bbl === tinwood is now known as tinwood_ === tinwood_ is now known as tinwood__ === tinwood__ is now known as tinwood [18:30] frobware: oops [18:30] frobware: will look in a bit [18:30] (and yes on the network interloc - I forgot it was on!) [18:56] beisner, your last png looks nothing like my setup. interesting... [19:01] hi frobware - just in for a bit, on us holiday, little one is napping tho and i just can't help but work a little. [19:02] frobware, how about this one? are you set to "DHCP and DNS" ? https://launchpadlibrarian.net/234527105/maas-cluster-controller-interface-detail.png [19:02] beisner, do you have 10-15 to HO? [19:03] yah, sec... lm grab headset [19:04] beisner, https://plus.google.com/hangouts/_/canonical.com/juju-sapphire === mwhudson is now known as Guest86296 === Guest86296 is now known as mwhudson === mwhudson is now known as Guest65934 === Guest65934 is now known as mwhudson