[00:25] <mup> Bug # changed: 1167616, 1292116, 1346597, 1349949, 1383453, 1425808, 1426728, 1453805, 1455627, 1465317, 1466514, 1473069, 1475212, 1480616, 1485781, 1498232, 1501475, 1504658, 1506044, 1509635, 1510688, 1510787, 1513667, 1516150, 1517632, 1518480, 1518482, 1521453, 1530840, 1531444, 1532130,
[00:25] <mup> 1532266, 1534103, 1535838, 1536447, 1538583, 1540301, 1546794, 1548078, 1552274, 1555475, 1555727, 1555808, 1557726, 1557914, 1558185, 1560107, 1560888, 1563015, 1563611, 1563933, 1564026, 1566014, 1566426, 1566583, 1566639, 1566684, 1566791, 1567607, 1567747, 1567934, 1568183, 1568666, 1569802,
[00:25] <mup> 1570216, 1570660, 1571982, 1572116, 1572695, 1572700, 1573407, 1573742, 1576534, 1577524, 1577567, 1577587, 1577589, 1577590, 1577593, 1577638, 1577798, 1578898, 1579887, 1579976, 1580231, 1580423, 1580485, 1580717, 1581894, 1582021, 1582065, 1582463, 1582801, 1584193, 1585878, 1586089, 1586890,
[00:25] <mup> 1587345, 1587503, 1587734, 1588041, 1589641, 1590362, 1591488, 1592613, 1592811, 1593185, 1593350, 1594332, 1594663, 1595600, 1596619, 1596687, 1596688, 1596842, 1596858, 1596888, 1596890, 1596893, 1596906, 1597481, 1597490, 1597601, 1597830, 1598206, 1598290, 1598707, 1599272, 1599570, 1599886,
[00:25] <mup> 1600063, 1600221, 1600453, 1600515, 1600523, 1600546, 1602032, 1602237, 1602416, 1602749, 1602840, 1602885, 1602952, 1603060, 1603176, 1603228, 1603473, 1603640, 1603841, 1604120, 1604817, 1604883, 1604915, 1604961, 1604965, 1604988, 1605241, 1605335, 1605449, 1605653, 1605714, 1605986, 1606282,
[00:25] <mup> 1606308, 1606354, 1606487, 1606506, 1606617, 1606684, 1606917, 1606922, 1607161, 1607170, 1607347, 1607599, 1607601, 1607608, 1607611, 1607855, 1607895, 1607964, 1607971, 1608494, 1608529, 1608597, 1608677, 1608956, 1608959, 1609893, 1610880, 1611067, 1611093, 1611159, 1611391, 1611404, 1611427,
[00:25] <mup> 1611453, 1611514, 1611799, 1611981, 1611990, 1612046, 1612105, 1612110, 1612417, 1612500, 1612624, 1612717, 1612836, 1613150, 1613200, 1613262, 1613300, 1613429, 1613444, 1613459, 1613491, 1613688, 1613782, 1613838, 1613839, 1613855, 1613858, 1613866, 1613892, 1613960, 1613992, 1614010, 1614161,
[00:25] <mup> 1614345, 1614364, 1614559, 1614635, 1614689, 1614948, 1615051, 1615839
[00:28] <perrito666> chill out bot, you will get something
[00:38] <redir> bbiab ~730PDT
[00:39] <anastasiamac> thumper-dogwalk: RB strikes again :D PR behind this RB has been merged but RB is still open.. could u plz close it? http://reviews.vapour.ws/r/5472/
[00:49] <mup> Bug # changed: 1205113, 1334482, 1397201, 1403722, 1444066, 1445066, 1455625, 1468188, 1492530, 1494939, 1536448, 1539156, 1542488, 1545712, 1554116, 1555801, 1556176, 1564168, 1566023, 1569632, 1570651, 1571831, 1571855, 1572350, 1573099, 1574798, 1575245, 1575283, 1575405, 1576184, 1576295,
[00:49] <mup> 1576301, 1576342, 1576359, 1576851, 1579833, 1579836, 1581138, 1581211, 1581612, 1581879, 1582018, 1585289, 1590237, 1591379, 1591499, 1592031, 1592837, 1594440, 1595330, 1596476, 1596593, 1596603, 1596605, 1596607, 1596612, 1596615, 1596616, 1596853, 1604106, 1607303, 1609463, 1609879, 1610007,
[00:49] <mup> 1610254, 1611111, 1611267, 1611269, 1611271, 1611273, 1611275, 1612043, 1612048, 1612478, 1612645, 1612658, 1612687, 1612775, 1612793, 1613537, 1613672, 1614065, 1614230, 1614239, 1614329, 1614330, 1614571, 1614633, 1614732, 1614749, 1614809, 1615108, 1615601
[00:58] <mup> Bug #1615868 opened: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:10] <mup> Bug #1615868 changed: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:16] <mup> Bug #1615868 opened: interactive bootstrap fails with tools mismatch <juju-core:Triaged> <https://launchpad.net/bugs/1615868>
[01:25] <mup> Bug #1615868 changed: interactive bootstrap fails with tools mismatch <juju:Triaged> <https://launchpad.net/bugs/1615868>
[01:36] <wallyworld> thumper-dogwalk: can you ping me, or see last comment in bug 1615051
[01:36] <mup> Bug #1615051: Dubious hook failures deploying trivial charm <ci> <deploy> <hooks> <jujuqa> <regression> <juju:Triaged by thumper> <https://launchpad.net/bugs/1615051>
[01:49] <thumper> wallyworld: seems reasonable
[01:49] <wallyworld> thumper: so you will fix :-)
[01:50] <thumper> wallyworld: you got to blame it on me
[01:50] <thumper> um...
[01:50] <wallyworld> \o/
[01:50] <thumper> they need to fix their tests
[01:50] <wallyworld> but the charm is broken
[01:50] <wallyworld> we have broken the production charm
[01:50] <thumper> so they need to fix their charm
[01:50] <wallyworld> for mediawiki and others
[01:51] <wallyworld> a lot of stuff will just break now
[01:51] <thumper> wallyworld: marcoceppi seemed to think that most charms use charmtools and wouldn't be impacted by this change
[01:51] <wallyworld> does charm tools do the right thing? what does it do?
[01:51] <thumper> it always says --format json
[01:51] <wallyworld> so maybe we just got unlucky
[01:51] <marcoceppi> charmhelpers*
[01:52] <thumper> marcoceppi: sorry
[01:52] <wallyworld> the dummy test charm and the mediawiki one the CI tests use
[01:52] <thumper> marcoceppi: would you expect mediawiki to work?
[01:52] <marcoceppi> it's probalby bash
[01:52] <marcoceppi> because it's garbage
[01:53] <wallyworld> no, ot's python
[01:53] <wallyworld> https://api.jujucharms.com/charmstore/v5/mediawiki/archive/hooks/cache-relation-changed
[01:53] <thumper> wallyworld: it uses --format json
[01:54] <wallyworld> really?
[01:54] <wallyworld> rl = subprocess.Popen("relation-list",stdout=subprocess.PIPE)
[01:54] <wallyworld> no python there that i can see - that's the bit that is causing the failure
[01:54] <wallyworld> unless i am mistaken
[01:54] <marcoceppi> wallyworld: it's not using charmhelpers, it's not a good charm
[01:55] <wallyworld> agreed
[01:55] <thumper> p = subprocess.Popen(["relation-get", "--format", "json", "-", memcached_unit.strip()],
[01:55] <wallyworld> thumper: right but that's not the issue
[01:55] <thumper> ugh
[01:55] <thumper> sabdfl said "fix the charms"
[01:55] <wallyworld> the issue is that the memcahced_unit value has changed
[01:56] <wallyworld> thumper: so for now, i guess we ask CI to set the feature flag
[01:56] <thumper> wallyworld: that would certainly be the easiest solution
[01:57] <thumper> wallyworld: I'll email appropriate people
[01:57] <wallyworld> thumper: can you be the one then to mark the bug as "invalid" or "won't fix" for core :-)
[01:57] <wallyworld> ta
[01:58] <wallyworld> thumper: also cc rick who was the one who the bug passed through
[01:59] <thumper> ack
[02:41] <redir> woah, hot bug action.
[03:01] <katco> thumper: hey, i responded to your review of http://reviews.vapour.ws/r/5485/ can you give me a ship it (or not)?
[03:01] <thumper> sure, I'll look again shortly
[03:01] <katco> thumper: no rush at all. as long as i wake up in 10h or so and something's there :)
[03:01] <thumper> :)
[03:01] <katco> thumper: ta
[03:02]  * katco disappears
[03:02] <redir> poof
[03:03] <natefinch> so I guess juju on launchpad is now what we're using for 2.0 bugs?
[03:04] <natefinch> as opposed to juju-core
[03:04] <mup> Bug #1615095 changed: storage: volumes not supported <landscape> <juju:Triaged> <https://launchpad.net/bugs/1615095>
[03:07] <mup> Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged> <https://launchpad.net/bugs/1615580>
[03:11] <anastasiamac> natefinch: yes. this si the attempt to make sure that we important 2.0 bugs do not disappear in the heap of old 15K bugs.. when I say old, i mean like 2012,2013...:D
[03:19] <mup> Bug #1615580 opened: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged by thumper> <https://launchpad.net/bugs/1615580>
[03:20] <natefinch> anastasiamac: cool.  Hopefully someone will send out an email soon, so we don't add new bugs to the wrong place?
[03:20] <anastasiamac> natefinch: Rcik sent an email couple of weeks ago.
[03:25] <natefinch> anastasiamac: oh. huh.
[03:25] <anastasiamac> Rick* even :D
[03:26] <natefinch> anastasiamac: ahh, I see it.  It's buried at the bottom of a long-ish email about bug cleanup :)
[03:27] <anastasiamac> natefinch: i like the idea of following up to sya "we are done" but i think a redirect from juju-core to juju (or some kind of note that 2.0 bugs do not belong there) would be nice..
[03:31] <natefinch> anastasiamac: so it's on 2.0 bugs that'll get moved over?
[03:31] <natefinch> s/on/only
[03:31] <anastasiamac> natefinch: yes, 2.+
[03:31] <anastasiamac> \o/
[03:32] <natefinch> Oh, I know why I missed it, rick sent it to cloud
[03:33] <anastasiamac> natefinch: yes :D
[03:34] <natefinch> I don't ever look at cloud, because it's so spammy
[03:34] <anastasiamac> natefinch: sorry. want to file a bug? :D
[03:34] <natefinch> haha
[03:34] <mup> Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal <juju:Triaged> <https://launchpad.net/bugs/1615580>
[03:34] <mup> Bug #1615719 changed: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored <openstack-provider> <juju:Triaged> <https://launchpad.net/bugs/1615719>
[03:34] <natefinch> just wondering if I should add juju-dev to my re-forwarding of the email
[03:35] <natefinch> seems like it would be good for people outside canonical to know, too.  but maybe that was on purpose
[03:55] <wallyworld> thumper: probs not - did we have anything like dave's process info endpoint in 1.25?
[03:55] <thumper> yes
[03:55] <thumper> but it was less easy to access
[03:56] <wallyworld> thumper: oh awesome, i didn't think it was for 1.25, can you point me to docs?
[03:56] <thumper> it landed in 1.25 I think
[03:56] <thumper> https://github.com/juju/juju/wiki/pprof-facility
[03:56] <thumper> 1.25.4
[03:57] <wallyworld> awesome thanks
[04:07] <mup> Bug # changed: 1456659, 1457092, 1457148, 1459300, 1493058, 1507359, 1510651, 1510944, 1512782, 1536230, 1536333, 1554088, 1559299, 1560331, 1568186, 1568189, 1568715, 1578327, 1580221, 1582268, 1588147, 1596559, 1605593, 1606300, 1615121
[04:13] <mup> Bug # changed: 1614599, 1614622, 1614835, 1614992, 1615008
[04:18] <wallyworld> can has small review? http://reviews.vapour.ws/r/5506/
[04:19] <mup> Bug # opened: 1614599, 1614622, 1614835, 1614992, 1615008
[04:25] <redir> wallyworld: looking
[04:25] <wallyworld> \o/
[04:25] <wallyworld> redir: need any help with the config stuff - just let me know
[04:26] <redir> yeah, I have a couple ? in a minute, wallyworld
[04:27] <wallyworld> wow, this is kinda awesome, just saw it in warthogs http://www.boredpanda.com/ive-just-painted-all-25-ubuntu-animals/
[04:33] <wallyworld> axw: it seems that we have Schema() methods on various environ providers but don't call this method anywhere but from tests, and I can't see an interface that declares it either - it's not on the EnvironProvider interface. am i missing something?
[04:33] <menn0> veebers: the big macaroon changes for migrations have landed
[04:34] <axw> wallyworld: I don't think that work was ever completed
[04:34] <axw> wallyworld: I think it'll be obsoleted by natefinch's work
[04:36] <wallyworld> ok, but i need it now :-)
[04:36] <wallyworld> for proper default config management
[04:36] <wallyworld> this week
[04:36] <wallyworld> first in wins :-)
[04:36] <axw> wallyworld: what do you need to do?
[04:37] <wallyworld> when bootstrapping and setting up config defaults, we currently ignore provider specific config - we only handle what's in config/config.go. So juju model-defaults will not show use-floating-ip for example on openstack
[04:37] <mup> Bug # changed: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560618,
[04:37] <mup> 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1578237, 1580714, 1582264, 1583304, 1585300, 1589628, 1603221, 1604959, 1605767, 1605769, 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313,
[04:37] <mup> 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405, 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764, 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824,
[04:37] <mup> 1613829, 1613882, 1613888, 1614256, 1614599, 1614622, 1614835, 1614992, 1615008, 1615118
[04:37] <veebers> menn0: awesome, I'll build and fire off a run shortly :-)
[04:38] <wallyworld> and when a user sets or resets a value, they get a bullshit warning because those provider config items are not in the vocab
[04:38] <wallyworld> so i can easily solve the issue by processing the provider schema at bootstrap time
[04:39] <axw> wallyworld: ok, sounds like adding Schema to EnvironProvider is reasonable. please let natefinch know your requirements so he can work that into what he's doing
[04:39] <wallyworld> will do
[04:40] <wallyworld> he may even be lurking here now :-)
[04:40] <mup> Bug # opened: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560618,
[04:40] <mup> 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1578237, 1580714, 1582264, 1583304, 1585300, 1589628, 1603221, 1604959, 1605767, 1605769, 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313,
[04:40] <mup> 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405,
[04:40] <mup> 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764, 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118
[04:43] <mup> Bug # changed: 1242783, 1514555, 1515016, 1517076, 1519147, 1519176, 1519189, 1521020, 1521699, 1528070, 1528572, 1531719, 1534626, 1536336, 1536340, 1536345, 1542988, 1543839, 1544838, 1544855, 1545713, 1547891, 1548921, 1554136, 1554797, 1556238, 1559701, 1559708, 1559789, 1560152, 1560593,
[04:43] <mup> 1560618, 1561526, 1561959, 1563335, 1563373, 1563380, 1563400, 1563888, 1565461, 1565462, 1567396, 1569529, 1571065, 1571687, 1572102, 1573681, 1574637, 1575229, 1575400, 1578237, 1580714, 1582264, 1583304, 1585300, 1585361, 1589628, 1589890, 1590239, 1596071, 1603221, 1604959, 1605767, 1605769,
[04:43] <mup> 1605776, 1606256, 1606265, 1606302, 1606303, 1606310, 1606313, 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405, 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764,
[04:43] <mup> 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118
[04:44] <redir> wallyworld: sooo for passing params to the ComposeNewModelConfig from apiserver/modelmanager were you thinking params that live in apiserver/params/... or somewhere else?
[04:45] <wallyworld> redir: let me look at the code
[04:46] <redir> wallyworld: I'll put it there and make a PR, so I wrap and have feedback for tomorrow, whence I can also get the modeldefaults done and move on to get/set
[04:47] <wallyworld> redir: ok. with regards to ComposeNewModelConfig, you are talking about weaving in the region defaults right?
[04:49] <wallyworld> if so, there's nothing to pass across the wire for that, so nothing from params
[04:49] <redir> wallyworld: yes, currently just passing cloudSpec
[04:49] <redir> but only need cloud and region
[04:49] <redir> wallyworld: right nothing for the wire.
[04:49] <redir> internal?
[04:50] <wallyworld> no, stuff in those dirs is just for on the wire data
[04:50] <redir> wallyworld: in internal is only for wire data?
[04:51] <wallyworld> yes, internal api calls
[04:51] <wallyworld> from workes to state etc
[04:51] <redir> OK.
[04:51] <wallyworld> everything in apiserver should be about pulling stuff of the wire for remote calls and composing into business objects for use elsewhere, but sadly we have put a lot of business logic in apiserver
[04:51] <wallyworld> which should really be elsewhere
[04:52] <wallyworld> there needs to be a separate business service layer
[04:52] <wallyworld> but we have conflated apiserver for that
[04:53] <axw> wallyworld: I'm going to pause on azure stuff and look at removing the remaining model config from the lxd provider
[04:53] <wallyworld> awesome^100
[04:54] <wallyworld> i'd love to get all this sorted this week
[04:54] <menn0> thumper: blocking of user API requests to a model while it is being imported http://reviews.vapour.ws/r/5508/
[04:54] <axw> wallyworld: I have a PR up for azure that reduces the number of API calls made. I didn't get as far as using templates, but that can be done later
[04:54] <axw> no rush to review, just FYI
[04:54] <wallyworld> ok, ta
[05:13] <mup> Bug # changed: 1190293, 1258051, 1287658, 1372543, 1421650, 1433161, 1488777, 1512481, 1516975, 1524823, 1528073, 1531995, 1534511, 1535891, 1536819, 1545563, 1546142, 1554802, 1556167, 1559402, 1560527, 1561375, 1562088, 1564452, 1564880, 1566044, 1566271, 1566893, 1567712, 1569109, 1569963,
[05:13] <mup> 1571923, 1572585, 1573668, 1574677, 1575310, 1575895, 1576324, 1578383, 1579592, 1579593, 1579849, 1580626, 1581069, 1581537, 1581600, 1582214, 1582818, 1582948, 1583787, 1584170, 1584212, 1584896, 1585674, 1585847, 1588092, 1588224, 1589351, 1589581, 1590468, 1590520, 1592583, 1592872, 1593492,
[05:13] <mup> 1593708, 1594578, 1594883, 1595314, 1595720, 1595937, 1596038, 1596039, 1596496, 1596850, 1598319, 1599269, 1599612, 1600061, 1600296, 1600559, 1602838, 1603202, 1603888, 1604542, 1604551, 1604586, 1605976, 1606337, 1606569, 1606611, 1606706, 1606709, 1607109, 1607766, 1608422, 1608723, 1609910,
[05:13] <mup> 1610450, 1611076, 1611110, 1612099, 1612112, 1612163, 1613842
[05:22] <mup> Bug # changed: 1545568, 1548809, 1558657, 1558668, 1558924, 1560428, 1560920, 1561339, 1569949, 1572703, 1573665, 1577606, 1580400, 1581337, 1584832, 1584897, 1584899, 1584900, 1584901, 1584903, 1584905, 1584906, 1588970, 1589339, 1589350, 1590699, 1590732, 1596960
[05:31] <mup> Bug # opened: 1545568, 1548809, 1558657, 1558668, 1558924, 1560428, 1560920, 1561339, 1569949, 1572703, 1573665, 1577606, 1580400, 1581337, 1584832, 1584897, 1584899, 1584900, 1584901, 1584903, 1584905, 1584906, 1588970, 1589339, 1589350, 1590699, 1590732, 1596960
[05:43] <mup> Bug # changed: 1463608, 1536885, 1543404, 1543408, 1545568, 1548809, 1558657, 1558668, 1558924, 1560428, 1560920, 1561339, 1564157, 1564500, 1566268, 1567952, 1569949, 1572703, 1573665, 1577606, 1580400, 1581337, 1584832, 1584897, 1584899, 1584900, 1584901, 1584903, 1584905, 1584906, 1588970,
[05:43] <mup> 1589339, 1589350, 1590699, 1590732, 1593274, 1596960, 1598127, 1600600
[05:49] <redir> wallyworld: http://reviews.vapour.ws/r/5510/ at your leisure. I'm off for the night. If that is close I should be able to move on to the defaults output and then the get/set bits
[05:49] <redir> night juju-dev
[05:49] <wallyworld> thaks reed
[05:49] <wallyworld> ttyl
[05:49] <mup> Bug # opened: 1463608, 1536885, 1543404, 1543408, 1564157, 1564500, 1566268, 1567952, 1593274, 1598127, 1600600
[05:53] <mup> Bug # changed: 1463608, 1536885, 1543404, 1543408, 1557540, 1563117, 1564157, 1564500, 1564677, 1566268, 1567952, 1593274, 1598127, 1600600
[06:11] <mup> Bug #1557540 opened: Missing help for payloads <docs> <payloads> <juju:Triaged> <https://launchpad.net/bugs/1557540>
[06:11] <mup> Bug #1563117 opened: api: data race adding local charm. <race-condition> <unit-tests> <juju:Triaged> <https://launchpad.net/bugs/1563117>
[06:11] <mup> Bug #1564677 opened: Create one binary for juju and all plugins <osx> <packaging> <juju:Triaged> <https://launchpad.net/bugs/1564677>
[06:14] <mup> Bug # changed: 1512569, 1557540, 1563117, 1564677
[06:22] <axw> wallyworld: can you please see my comments on http://reviews.vapour.ws/r/5502/, make sure I'm not leading anastasiamac up the garden path again
[06:24] <wallyworld> ok
[06:24] <wallyworld> axw: could you take look at my small pr that reed looked at? just to give sign off?
[06:24] <axw> wallyworld: sure, looking
[06:49] <wallyworld> axw: fmt.Fprintf(ctx.Stderr) vs logger.Warning - i was hoping to avoid the logger extras and keep the output clean. was your issue that we should be showing a WARNING text?
[06:54] <axw> wallyworld: I was thinking that yeah
[06:55] <axw> wallyworld: not too concerned
[06:55] <wallyworld> axw: ok, i'll add warning to the text
[06:57] <wallyworld> axw: axctually, i meant that you look at this one http://reviews.vapour.ws/r/5506/
[06:57] <axw> wallyworld: heh whoops
[06:57] <wallyworld> the other one may need to have other changes added
[06:57] <axw> looking :)
[06:57] <wallyworld> ta
[06:59] <axw> wallyworld: LGTM
[06:59] <wallyworld> ta
[07:37] <anastasiamac> axw: wallyworld: re: defaults for image metadata, want to discuss tomorrow after standup? i think we are all pretty much in agreement but i;d rather minimise the churn on PR \o/
[07:38] <axw> anastasiamac: sure
[07:38] <anastasiamac> axw: \o/
[07:38] <axw> anastasiamac: I have a meeting at 8am, so may have to be short or after that
[07:39] <anastasiamac> axw: that's k. as long as it's sometime tomorrow :) i have a meeting at 11am my time =9am urs? :) so maybe early afternoon :D
[07:40] <axw> anastasiamac: and I plan to be out between 9:30 and don't-know-when looking at cars (again)
[07:42] <anastasiamac> axw: that's exciting :D know what u want?
[07:42] <axw> anastasiamac: there's a couple that are ok. I'm not too bothered, as long as I don't get ripped off
[07:43] <anastasiamac> axw: well, actually, i'll remove the method and will ensure that data is populated at the right spots so it may be just the matter of re-viewing changes ;)
[07:43] <axw> anastasiamac: ok, sounds good
[07:43] <anastasiamac> axw: i love shopping for cars :)
[07:44] <mup> Bug #1615958 opened: Switch to model name does't work anymore, admin should not be allowed to switch to users model <juju-core:New> <https://launchpad.net/bugs/1615958>
[07:44] <mup> Bug #1615960 opened: remove-machine and remove-application don't work on google cloud <juju-core:New> <https://launchpad.net/bugs/1615960>
[08:27] <voidspace> fwereade: ping
[08:30] <voidspace> dimitern: land your lxd fix and let mgz handle the packaging mess when he returns ;-)
[08:30]  * voidspace wants lxd working again
[08:30] <dimitern> voidspace: :)
[08:30] <voidspace> I might try one more time to go back to 2.0
[08:31] <dimitern> voidspace: yeah, and I'm not convinced there is any packaging issue anyway
[08:31] <voidspace> I burned at least two hours on it yesterday
[08:31] <voidspace> dimitern: it seems odd
[08:31] <voidspace> dimitern: however I'm sure frobware wouldn't invent it - so there must be some issue
[08:31] <voidspace> dimitern: maybe a trusty thing?
[08:31] <voidspace> but still can't see how
[08:31] <voidspace> I'm sure mgz will explain :-(
[08:33] <dimitern> voidspace: it was something about building .debs that includes building the lxd source and running into conflicts
[08:33] <dimitern> but I don't believe this is avoidable at all
[08:34] <dimitern> it'll break if lxd changes binary compatibility, like adding an extra arg to Init()
[08:44] <babbageclunk> Hey fwereade, could you take another look at http://reviews.vapour.ws/r/5495/? I really think I've got it this time! :)
[08:47] <fwereade> voidspace, babbageclunk: heyhey, I'm off today but you're in luck, everybody else is still asleep for the moment
[08:48] <voidspace> fwereade: hehe
[08:48] <voidspace> fwereade: I'm making some progress code spelunking on my own
[08:48] <fwereade> voidspace, excellent
[08:48] <voidspace> fwereade: but it's unfamiliar code so I'm sure you can help with some quick pointers
[08:48] <voidspace> fwereade: IRC or hangout?
[08:49] <fwereade> voidspace, irc probably better
[08:56] <babbageclunk> fwereade: Yay thanks! Hope your day off gets better once voidspace stops bothering you. So rude!
[08:56]  * babbageclunk does a big wink.
[08:57] <voidspace> babbageclunk: always
[08:57] <voidspace> babbageclunk: and stop winking
[08:58] <babbageclunk> voidspace: oh, that's involuntary - I think it's my meds.
[08:58] <voidspace> babbageclunk: :-)
[08:59] <fwereade> babbageclunk, hahaha
[09:08] <thumper> o/
[09:08] <thumper> fwiw I'm fixing my fubar
[09:08] <thumper> will need some reviewers soon
[09:08] <dimitern> mgz, frobware, voidspace, babbageclunk: I'm about to push https://github.com/juju/juju/pull/6054 for landing, unless anyone is strongly against it.
[09:09] <dimitern> \o thumper
[09:14] <voidspace> dimitern: sounds good to me
[09:14] <voidspace> thumper: o/
[09:14] <thumper> o/
[09:14] <babbageclunk> thumper: o/
[09:14] <thumper> babbageclunk: how's the laptop?
[09:16] <babbageclunk> thumper: :( I'm using a loaner at the moment.
[09:17] <babbageclunk> thumper: But it's super chunky - 8 cores & 32 Gb!
[09:17] <babbageclunk> thumper: (the loaner, I mean)
[09:17] <thumper> babbageclunk: so fucked then?
[09:18] <babbageclunk> thumper: And it was a pretty good test of my ansible setup scripts.
[09:18] <babbageclunk> thumper: yup - just the drive, though
[09:18] <babbageclunk> thumper: need to order a new ssd
[09:18]  * thumper nods
[09:18] <thumper> lose much?
[09:18] <thumper> here is the first branch: http://reviews.vapour.ws/r/5511/
[09:19] <babbageclunk> thumper: a couple days' work - although lots of that was working out time rather than typing time, so it wasn't too bad. Definitely pushing a lot more frequently now though!
[09:25] <thumper> :)
[09:34] <macgreagoir> dimitern: I want to retry a merge, but I can wait if you're about to queue-up the LXD fix.
[09:35] <dimitern> macgreagoir: I've just sent the merge comment on mine
[09:36] <macgreagoir> Cool
[09:43]  * thumper runs all tests
[09:46] <thumper> prelim review anyone? http://reviews.vapour.ws/r/5512/
[09:46] <thumper> I'm running all the tests now to make sure I didn't miss something
[09:47] <dimitern> thumper: looking at both, in order
[09:47] <thumper> dimitern: first one has landed already
[09:47] <thumper> :)
[09:47] <thumper> it is a juju/cmd change
[09:47] <thumper> which the second needs
[09:48] <dimitern> oh
[09:48] <dimitern> ok
[09:52] <thumper> so far, so good
[09:52] <thumper> up to featuretests
[09:52] <thumper> worker/uniter was the other big failure
[09:52] <macgreagoir> You just jinxed it! :-)
[09:52] <thumper> perhaps
[10:14] <thumper> oh poop
[10:21] <thumper> anyone ? http://reviews.vapour.ws/r/5513/
[10:22] <thumper> real fix waiting now for the above cmd fix
[10:23] <thumper> babbageclunk ? ^^
[10:24] <babbageclunk> thumper: I started looking but it was longer than my attention span! I'll take another run at it.
[10:24] <thumper> the one above is a missed behaviour change in juju/cmd
[10:25] <thumper> I have an update for the big branch once that has landed
[10:25] <babbageclunk> thumper: Oh, right - looking at that now
[10:25] <thumper> babbageclunk: thanks
[10:26] <babbageclunk> thumper: LGTM
[10:27] <babbageclunk> thumper: How are you verifying these?
[10:27] <babbageclunk> thumper: (I mean against the old one.)
[10:28] <thumper> I have been looking at the test changes I did on my friday branch
[10:28] <thumper> and making the code like that again
[10:28] <thumper> then fixing other things that need fixing
[10:28] <babbageclunk> gotch
[10:28] <macgreagoir> thumper: 5512 lgtm, fwiw
[10:29] <babbageclunk> a
[10:29] <babbageclunk> wow macgreagoir, how'd you do that? sharp packets?
[10:31] <macgreagoir> babbageclunk: gotch...a ? I'd been reviewing 5512 much longer than that :-)
[10:34] <thumper> babbageclunk, macgreagoir: 5512 just got a fresh push
[10:34]  * thumper runs another complete test run just to be sure
[10:39] <babbageclunk> frobware: Have you got your hacked trusty image around? Need to recreate my kvm-maases.
[10:39]  * thumper is still hoping for a +1 from babbageclunk
[10:39]  * babbageclunk sighs.
[10:40] <babbageclunk> ok looking for reals now
[10:44] <thumper> babbageclunk: thanks, I appreciate it
[10:44] <thumper> babbageclunk: FWIW, it isn't very exciting
[10:48] <babbageclunk> thumper: Ok, done - LGTM!
[10:48] <babbageclunk> thumper: It wasn't very exciting though. :)
[10:55] <thumper> thanks
[10:55] <thumper> tests all good this side
[10:55] <thumper> I'm submitting and signing off
[10:55] <thumper> laters
[10:56] <macgreagoir> \o
[11:02] <rick_h_> macgreagoir: adding one more item for that list for the card you're working on please, controller version
[11:04] <macgreagoir> rick_h_: ack
[11:04] <rick_h_> ty macgreagoir
[11:04] <rick_h_> dimitern: around to chat?
[11:07] <dimitern> rick_h_: yeah, sorry - joining our 1:1 now
[11:11]  * babbageclunk has to reboot to enable on virtualisation!
[11:17] <rick_h_> mgz: ping
[11:29] <babbageclunk> frobware: ping?
[11:30] <babbageclunk> voidspace: Are you around? Do you have frobware's hacked xenial image with the fixed cloud-init?
[11:30] <babbageclunk> voidspace: I'm sorry about those mean things I said this morning.
[11:30] <babbageclunk> voidspace: That was before I realised I needed something from you.
[11:31] <voidspace> babbageclunk: haha
[11:31] <voidspace> babbageclunk: I don't - I thought cloud-init was fixed in the standard images now
[11:31] <voidspace> babbageclunk: that's all I've been using
[11:31] <babbageclunk> voidspace: hmm - my xenial instance won't start
[11:34] <babbageclunk> voidspace: just hangs during startup. although at a different point than the cloud-init problem did, now that I look harder at it.
[11:34] <voidspace> babbageclunk: oh, weird
[11:34] <voidspace> babbageclunk: maas?
[11:34] <voidspace> pretty sure I've had it working fine
[11:37] <babbageclunk> voidspace: Well, I haven't got to the point of installing maas yet - this is just starting the controller.
[11:38] <babbageclunk> voidspace: I'm using the daily build - maybe I should use something else?
[11:38] <frobware> babbageclunk: http://178.62.20.154/~aim/xenial-server-cloudimg-amd64-disk1.img
[11:38] <babbageclunk> frobware: Thanks, I'll try that instead.
[11:38]  * frobware is unexpedtedly out of office today dealing with leaking pipes :(
[11:39] <babbageclunk> frobware: good luck!
[11:52] <babbageclunk> frobware: That worked, thanks.
[12:46] <mup> Bug #1616059 opened: Unit test failure in github.com/juju/juju/cmd/juju/application	 <juju-core:Triaged> <https://launchpad.net/bugs/1616059>
[13:11] <mgz> rick_h_: late pong
[13:16] <mup> Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:New> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:31] <mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:31] <mup> Bug # opened: 1425808, 1457575, 1474607, 1510651, 1513165, 1534643, 1538583, 1573136, 1580221, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633
[13:43] <mup> Bug # changed: 1425808, 1457575, 1474607, 1510651, 1513165, 1534643, 1538583, 1573136, 1580221, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633
[13:43] <mup> Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:46] <mup> Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.25:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1511822>
[13:46] <mup> Bug # opened: 1425808, 1457575, 1474607, 1493058, 1510651, 1513165, 1534643, 1538583, 1554088, 1573136, 1584616, 1587644, 1592887, 1596597, 1597830, 1599503, 1604988, 1610880, 1612645, 1613992, 1614364, 1614633, 1615118
[13:51] <babbageclunk> voidspace: Did you have any trouble commissioning nodes in maas19?
[13:57] <natefinch> rick_h_: btw, that email you sent about moving bugs from juju-core to juju was only sent to cloud@canonical - should it have been sent to juju and juju-dev@ubuntu also?  Seems like it's pretty important for everyone to see it.
[13:58] <rick_h_> natefinch: yea, I guess I assumed folks are on the wider distribution lists
[13:58] <rick_h_> natefinch: we're going to send a new email today focusing on how to file bugs and to confirm the move and such
[13:58] <voidspace> babbageclunk: I didn't
[13:58] <babbageclunk> voidspace: No worries, worked it out - missed a step in DHCP setup.
[13:58] <voidspace> ah
[13:59] <natefinch> rick_h_: cool.  Yeah, I honestly rarely look at the cloud list, because it's fairly spammy, and obviously people outside canonical aren't on that list
[14:02] <rick_h_> katco: dimitern ping for standup
[14:17] <mup> Bug #1616098 opened: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <cpec> <juju-core:New> <https://launchpad.net/bugs/1616098>
[14:18] <mgz> rick_h_: mini thing, should I add cards to the board for the random tasks I end up picking up? (like changing the release tools behaviour with patches and such)
[14:19] <rick_h_> mgz: yes please
[14:20] <rick_h_> mgz: anything that's more than a couple of hours to jfdi
[14:20] <mgz> okay, thanks
[14:20] <mgz> that one was actually pretty short, but I'll make sure to add anything meatier
[14:24] <babbageclunk> Oh, of course trying to bootstrap to two maases at once gets all confused.
[14:25] <natefinch> rick_h_: so, should I continue working on the add-cloud stuff or... ?
[14:25] <rick_h_> natefinch: no, please grab a critical
[14:26] <natefinch> rick_h_: will do
[14:29] <mup> Bug #1616098 changed: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <cpec> <juju-core:New> <https://launchpad.net/bugs/1616098>
[14:55] <babbageclunk> dimitern: around?
[15:05] <dimitern> babbageclunk: yeah
[15:06] <babbageclunk> dimitern: hey! I'm just doing some manual testing of my machine undertaker worker (it works yay), but I want to try it with multi-nic containers.
[15:07] <babbageclunk> dimitern: Is that just a matter of setting up the hosts with multiple nics and those will show up bridged in the containers?
[15:10] <rick_h_> katco: ping, got a sec?
[15:10] <katco> rick_h_: yep
[15:10] <rick_h_> can you jump in https://hangouts.google.com/hangouts/_/canonical.com/developer?authuser=1 please?
[15:11] <dimitern> babbageclunk: you need to also use maas
[15:11] <natefinch> https://hangouts.google.com/hangouts/_/canonical.com/sorry-you're-fired?authuser=1
[15:11] <babbageclunk> dimitern: yeah, sorry, should have said that - that's what I'm testing on.
[15:12] <dimitern> babbageclunk: and all top-level nics that have children you want to bridge need addresses\
[15:12] <dimitern> babbageclunk: but having that should give you multi-nic containers
[15:16] <babbageclunk> dimitern: Awesome. And giving them addresses is just a matter of setting the nics to auto-assign in maas, right? Does it matter if they're all on the same subnet?
[15:17] <dimitern> babbageclunk: auto assign or static assign should work - dhcp or unconfigured won't (the latter set on a parent NIC will lead to br-parent not getting created)
[15:26] <babbageclunk> dimitern: Cool, it totally just works!
[15:26] <babbageclunk> dimitern: This juju thing's pretty neat.
[15:31] <dimitern> babbageclunk: awesome! :) when it works..
[16:44] <mup> Bug #1536477 changed: utils/debugstatus: test failure <juju-core:Fix Released> <https://launchpad.net/bugs/1536477>
[16:44] <mup> Bug #1538583 changed: manual provider add-machine fails immediately after bootstrap <add-machine> <ci> <manual-provider> <regression> <juju:Triaged> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1538583>
[16:44] <mup> Bug #1590161 changed: apiserver/client: panic: Session already closed <juju-core:Fix Released> <https://launchpad.net/bugs/1590161>
[17:28] <natefinch> rick_h_: did you get the logs for this bug? https://bugs.launchpad.net/juju/+bug/1610880
[17:28] <mup> Bug #1610880: Downloading container templates fails in manual environment <juju:Triaged by rharding> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1610880>
[17:29] <rick_h_> natefinch: yes, sec. Let me find that email
[17:32] <siv> Hi. I want to develop a juju charm which will go and  change the Openstack cinder service configuration file. created charm will perform this action post Openstack juju deployment. can I create a charm like this?
[17:34] <rick_h_> siv: yes, look into https://jujucharms.com/docs/2.0/authors-subordinate-services to help do something like that
[17:41] <siv> rich_h: Hi. I have an Ubuntu OpenStack autopilot setup. After the regular OpenStack install using AutoPilot, my created juju charm used to modify cinder driver settings. This is my intension.
[17:49] <siv> Can I modify the cinder driver settings post autopilot openstack deployment using my created charm?
[17:50] <mup> Bug #1616149 opened: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1616149>
[17:57] <siv> How do a newly created juju charm get certified? what is the procedure for that? how many days that it will take to get certify the newly created juju charm?
[18:11] <rick_h_> siv: check out https://jujucharms.com/docs/stable/authors-charm-store and https://jujucharms.com/docs/stable/charm-review-process
[18:13] <siv> rich_h : thank you
[18:26] <mup> Bug #1615958 changed: Switch to model name does't work anymore, admin should not be allowed to switch to users model <juju:New> <https://launchpad.net/bugs/1615958>
[18:26] <mup> Bug #1615960 changed: remove-machine and remove-application don't work on google cloud <juju:New> <https://launchpad.net/bugs/1615960>
[18:26] <mup> Bug #1616059 changed: Unit test failure in github.com/juju/juju/cmd/juju/application	 <juju:Triaged> <https://launchpad.net/bugs/1616059>
[18:26] <mup> Bug #1615986 opened: Agents failing, blocked by upgrade but no upgrade performed <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1615986>
[18:57] <bdx> postgresql-peeps: say I have an application that needs to connect to 2 separate postgresql applications
[18:58] <bdx> postgresql-peeps: is there a way to react to the states of the same service under a different name? Is this done by providing service sensitive interface names?
[18:59] <bdx> charmers:^
[19:04] <bdx> eeeh, s/postgresql applications/postgresql db instances/
[19:04] <marcoceppi> bdx: hey
[19:05] <marcoceppi> bdx: might be better to ask in #juju
[19:05] <marcoceppi> bdx: but you can define two different relations with the same interface
[19:05] <marcoceppi> and that way have a scope of reacting to each relation name
[19:14] <bdx> my bad, thought I was on #juju ... grr
[19:14] <marcoceppi> bdx: no worries! does my reply make sense?
[19:15] <bdx> yes, can you give more context in #juju though?
[19:37] <natefinch> sigh... the instructions for bootstrapping to manual don't actually work :/ https://jujucharms.com/docs/stable/clouds-manual
[19:50] <mup> Bug #1474607 changed: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure <ci> <go1.5> <go1.6> <regression> <windows> <juju:Fix Released by axwalk> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1474607>
[19:50] <mup> Bug #1616197 opened: juju restore-backup error <juju-core:New> <https://launchpad.net/bugs/1616197>
[20:08] <bdx> marcoceppi: i see now
[20:08] <bdx> marcoceppi: thx
[20:08] <bdx> exactly what I was thinking
[20:31] <alexisb_> thumper, ping
[20:32] <thumper> alexisb_: hey
[20:33] <alexisb_> thumper, can you take a look at htis bug: https://bugs.launchpad.net/juju/+bug/1616158
[20:33] <mup> Bug #1616158: Int overflow during build for Windows <blocker> <ci> <regression> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1616158>
[20:33]  * thumper looks
[20:33] <alexisb_> https://github.com/juju/juju/commit/5ac0e259560382ea0c0e2a4120e028f2613ed857
[20:33] <alexisb_> ^^ this is the suspect commit
[20:36] <natefinch> we don't build x86 anymore, do we?
[20:36] <thumper> alexisb_: poo
[20:36] <thumper> alexisb_: mgo is assuming a 64 bit int
[20:36] <thumper> seems that windows still specifies 32?
[20:36] <natefinch> thumper: only if we're specifying a 32 bit architecture
[20:37] <thumper> natefinch: thoughts on the bug https://bugs.launchpad.net/juju/+bug/1616158
[20:37] <mup> Bug #1616158: Int overflow during build for Windows <blocker> <ci> <regression> <juju:Triaged by alexis-bruemmer> <https://launchpad.net/bugs/1616158>
[20:37] <thumper> mgo.v2/bson/json.go:320: constant 9007199254740992 overflows int
[20:37] <natefinch> thumper: yeah, I was just looking at it.
[20:38] <thumper> int is a signed integer type that is at least 32 bits in size
[20:38] <thumper> ^^ language spec
[20:38] <thumper> how can we find out how many bits the int uses?
[20:40] <natefinch> thumper: if you build with GOOS=windows GOARCH=amd64 it works fine  if you build with GOARCH=386 regardless of OS (windows or linux) it fails
[20:40] <natefinch> so... let's not build with GOARCH=386
[20:41] <natefinch> there's something tickling inside my head that says we were doing that on purpose for some reason... but I can't remember why now
[20:41] <natefinch> sinzui: do you know why we're building juju for windows as 32 bit?
[20:41] <mup> Bug #1616149 changed: Incompatible protocol between older client and candidate server <ci> <regression> <test-failure> <juju-core:Won't Fix> <https://launchpad.net/bugs/1616149>
[20:42] <thumper> natefinch: can you try replacing line 320 with this:
[20:42] <thumper> if int64(n) <= 1<<53 {
[20:43] <thumper> and then test the 386
[20:44] <natefinch> sure.. you can do it too (just sayin').  cross compile in go 1.5 and up is just "GOOS=windows GOARCH=386 go build ./..."
[20:44] <thumper> hmm...
[20:44] <thumper> ok
[20:45] <thumper> ok that works
[20:45] <thumper> alexisb_: we have two choices
[20:45] <thumper> alexisb_: stop building the windows client with GOARCH=386
[20:45] <thumper> alexisb_: or patch mgo
[20:47] <natefinch> either way, we should file a bug against mgo... I'm sure it was not intentional to break 386
[20:47] <sinzui> natefinch: yes, *you* explained we should because Windows 64 bit is not common. We never chnged the rules you wrote.
[20:47] <thumper> heh
[20:48] <sinzui> natefinch: If you believe 64bit clients are good for windows, we can change the build script in a few hours
[20:49] <thumper> apparently 32 bit versions stopped with windows 7 and vista
[20:49] <thumper> oh
[20:49] <thumper> no
[20:49] <thumper> 8.1 can still be in 32 bit
[20:50] <thumper> we should support 32 bit still
[20:50] <thumper> so... patch mgo
[20:50] <thumper> and file a bug etc etc
[20:50] <natefinch> I guess so.  honestly, I doubt anyone actually runs 32 bit windows anymore, but if 8.1 supports it, we probably should too
[20:51] <alexisb_> we dont support 32 bit linux
[20:51] <natefinch> and yes, 32 bit applications run on both 32 bit and 64 bit windows... the reverse is not true.
[20:51] <alexisb_> why would we do that for windows?
[20:51] <sinzui> thumper: natefinch : I the client is needs about 5 lines of change to switch to 64 bit when you are ready. We just match the rules of the win agent
[20:51] <natefinch> alexisb_: previously, presumably because it was free
[20:51] <perrito666> alexisb_: I believe that is because ubuntu no longer builds for 32
[20:51] <natefinch> alexisb_: i.e. no extra work
[20:52] <thumper> well... how many people likely to be using juju will be using 32 bit windows?
[20:52] <thumper> perhaps we just make it 64 bit and see who screams?
[20:53] <thumper> alexisb_: who makes this call?
[20:53] <alexisb_> sinzui, do we have stats on 32 bit windows client downloads
[20:53] <sinzui> alexisb_:  to be clear, agents cannot be 32 bit in clouds. and Ubuntu doesn't support 32 bit server anywhere. Clients are in a grey area. Ubuntu makes 32 bit clients and we don't say no.
[20:54] <sinzui> alexisb_: I can get them from the milestone pages
[20:56] <natefinch> alexisb_:  the problem is, we can't tell if people downloading have 32 or 64 bit windows, since the 32 bit download is all we offer.
[20:57] <natefinch> pretty sure you haven't been able to buy a machine with 32 bit windows in several years.... so the only people with 32 bit would be those who upgraded an old machine
[20:58] <thumper> Given today's hardware and defaults, I think we'd be fine saying 64 bit only windows...
[20:58] <thumper> I'll file a bug on mgo though
[21:01] <natefinch> gotta run to dinner, back in a bit
[21:02] <thumper> https://github.com/go-mgo/mgo/issues/325
[21:26] <thumper> simple review for someone: http://reviews.vapour.ws/r/5516/
[21:34] <perrito666> thumper: shipit, btw, you used the wrong dialect of markup
[21:34] <thumper> :)
[21:40] <thumper> w00t, current master lets me do this: `juju debug-log --replay --color --location | less -R`
[21:40] <thumper> for show me the log in color, no tail
[21:40] <thumper> marcoceppi, jcastro: ^^
[21:45] <mup> Bug #1513165 changed: Containers registered with MAAS use wrong name <cdo-qa-blocker> <sts> <sts-needs-review> <juju:Fix Released by thumper> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1513165>
[22:21] <mup> Bug #1421270 changed: juju deploy failure WebSocketConnection closed <api> <oil> <oil-bug-1372407> <juju-core:Won't Fix> <juju-deployer:Invalid> <https://launchpad.net/bugs/1421270>
[22:32] <wallyworld> redir: did you want to chat?
[22:32] <redir> y
[22:32] <redir> brt
[22:33] <marcoceppi> thumper: --color isn't default ;)
[22:33] <thumper> marcoceppi: yes it is
[22:34] <marcoceppi> oh, well I saw it explicitly called out
[22:34] <thumper> marcoceppi: but just like ls, if it isn't a terminal, it isn't there by default
[22:34] <marcoceppi> oh, because of the detection stuff, nvm
[22:34] <thumper> :)
[22:57] <perrito666> meh, squid never comes ok out of a reboot
[23:11] <thumper> perrito666: oh, is that what does it?
[23:11] <thumper> hadn't worked that out
[23:11] <perrito666> thumper: at least for me, needs to restart squid-deb-proxy
[23:11] <thumper> do you clear out the cache as well?
[23:11] <thumper> I had always assumed that was necessary
[23:14] <perrito666> thumper: I find it empty, I assume it empties on reboot?
[23:14]  * thumper shrugs
[23:14] <perrito666> nah, that is not the cache, my bad
[23:14] <perrito666> was looking at wrong dir
[23:14] <perrito666> I dont clean it
[23:18] <wallyworld> alexisb_: standup? we miss you
[23:32] <babbageclunk> Hey thumper! Long time no see.
[23:32] <thumper> o/
[23:32] <babbageclunk> Could you review this for me? https://github.com/juju/gomaasapi/pull/56
[23:37] <babbageclunk> thumper: ^^
[23:38]  * thumper looks
[23:41] <thumper> babbageclunk: LGTM
[23:41] <babbageclunk> thumper: Awse. Thanks!
[23:48] <perrito666> is it me or we all sound like daft punk songs in this call?