[00:25] 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] 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] 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] 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] 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] 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] 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] 1614345, 1614364, 1614559, 1614635, 1614689, 1614948, 1615051, 1615839 [00:28] chill out bot, you will get something === thumper is now known as thumper-dogwalk [00:38] bbiab ~730PDT [00:39] 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] 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] 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] 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] Bug #1615868 opened: interactive bootstrap fails with tools mismatch [01:10] Bug #1615868 changed: interactive bootstrap fails with tools mismatch [01:16] Bug #1615868 opened: interactive bootstrap fails with tools mismatch [01:25] Bug #1615868 changed: interactive bootstrap fails with tools mismatch [01:36] thumper-dogwalk: can you ping me, or see last comment in bug 1615051 [01:36] Bug #1615051: Dubious hook failures deploying trivial charm === thumper-dogwalk is now known as thumper [01:49] wallyworld: seems reasonable [01:49] thumper: so you will fix :-) [01:50] wallyworld: you got to blame it on me [01:50] um... [01:50] \o/ [01:50] they need to fix their tests [01:50] but the charm is broken [01:50] we have broken the production charm [01:50] so they need to fix their charm [01:50] for mediawiki and others [01:51] a lot of stuff will just break now [01:51] wallyworld: marcoceppi seemed to think that most charms use charmtools and wouldn't be impacted by this change [01:51] does charm tools do the right thing? what does it do? [01:51] it always says --format json [01:51] so maybe we just got unlucky [01:51] charmhelpers* [01:52] marcoceppi: sorry [01:52] the dummy test charm and the mediawiki one the CI tests use [01:52] marcoceppi: would you expect mediawiki to work? [01:52] it's probalby bash [01:52] because it's garbage [01:53] no, ot's python [01:53] https://api.jujucharms.com/charmstore/v5/mediawiki/archive/hooks/cache-relation-changed [01:53] wallyworld: it uses --format json [01:54] really? [01:54] rl = subprocess.Popen("relation-list",stdout=subprocess.PIPE) [01:54] no python there that i can see - that's the bit that is causing the failure [01:54] unless i am mistaken [01:54] wallyworld: it's not using charmhelpers, it's not a good charm [01:55] agreed [01:55] p = subprocess.Popen(["relation-get", "--format", "json", "-", memcached_unit.strip()], [01:55] thumper: right but that's not the issue [01:55] ugh [01:55] sabdfl said "fix the charms" [01:55] the issue is that the memcahced_unit value has changed [01:56] thumper: so for now, i guess we ask CI to set the feature flag [01:56] wallyworld: that would certainly be the easiest solution [01:57] wallyworld: I'll email appropriate people [01:57] thumper: can you be the one then to mark the bug as "invalid" or "won't fix" for core :-) [01:57] ta [01:58] thumper: also cc rick who was the one who the bug passed through [01:59] ack [02:41] woah, hot bug action. === ses is now known as Guest38591 [03:01] 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] sure, I'll look again shortly [03:01] thumper: no rush at all. as long as i wake up in 10h or so and something's there :) [03:01] :) [03:01] thumper: ta [03:02] * katco disappears [03:02] poof [03:03] so I guess juju on launchpad is now what we're using for 2.0 bugs? [03:04] as opposed to juju-core [03:04] Bug #1615095 changed: storage: volumes not supported [03:07] Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal [03:11] 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] Bug #1615580 opened: logging emits inappropriate ANSI escape codes on non-ANSI terminal [03:20] anastasiamac: cool. Hopefully someone will send out an email soon, so we don't add new bugs to the wrong place? [03:20] natefinch: Rcik sent an email couple of weeks ago. [03:25] anastasiamac: oh. huh. [03:25] Rick* even :D [03:26] anastasiamac: ahh, I see it. It's buried at the bottom of a long-ish email about bug cleanup :) [03:27] 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] anastasiamac: so it's on 2.0 bugs that'll get moved over? [03:31] s/on/only [03:31] natefinch: yes, 2.+ [03:31] \o/ [03:32] Oh, I know why I missed it, rick sent it to cloud [03:33] natefinch: yes :D [03:34] I don't ever look at cloud, because it's so spammy [03:34] natefinch: sorry. want to file a bug? :D [03:34] haha [03:34] Bug #1615580 changed: logging emits inappropriate ANSI escape codes on non-ANSI terminal [03:34] Bug #1615719 changed: [juju-2.0-beta15] during the bootstrap stage the no-proxy config is ignored [03:34] just wondering if I should add juju-dev to my re-forwarding of the email [03:35] seems like it would be good for people outside canonical to know, too. but maybe that was on purpose [03:55] thumper: probs not - did we have anything like dave's process info endpoint in 1.25? [03:55] yes [03:55] but it was less easy to access [03:56] thumper: oh awesome, i didn't think it was for 1.25, can you point me to docs? [03:56] it landed in 1.25 I think [03:56] https://github.com/juju/juju/wiki/pprof-facility [03:56] 1.25.4 [03:57] awesome thanks [04:07] 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] Bug # changed: 1614599, 1614622, 1614835, 1614992, 1615008 [04:18] can has small review? http://reviews.vapour.ws/r/5506/ [04:19] Bug # opened: 1614599, 1614622, 1614835, 1614992, 1615008 [04:25] wallyworld: looking [04:25] \o/ [04:25] redir: need any help with the config stuff - just let me know [04:26] yeah, I have a couple ? in a minute, wallyworld [04:27] wow, this is kinda awesome, just saw it in warthogs http://www.boredpanda.com/ive-just-painted-all-25-ubuntu-animals/ [04:33] 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] veebers: the big macaroon changes for migrations have landed [04:34] wallyworld: I don't think that work was ever completed [04:34] wallyworld: I think it'll be obsoleted by natefinch's work [04:36] ok, but i need it now :-) [04:36] for proper default config management [04:36] this week [04:36] first in wins :-) [04:36] wallyworld: what do you need to do? [04:37] 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] 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] 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] 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] 1613829, 1613882, 1613888, 1614256, 1614599, 1614622, 1614835, 1614992, 1615008, 1615118 [04:37] menn0: awesome, I'll build and fire off a run shortly :-) [04:38] 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] so i can easily solve the issue by processing the provider schema at bootstrap time [04:39] 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] will do [04:40] he may even be lurking here now :-) [04:40] 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] 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] 1606566, 1606568, 1606571, 1606711, 1606939, 1606991, 1607044, 1607362, 1607365, 1607368, 1607794, 1607858, 1607859, 1608528, 1608533, 1608938, 1608942, 1608947, 1609405, [04:40] 1609818, 1609896, 1609980, 1610238, 1610255, 1610993, 1611764, 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118 [04:43] 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] 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] 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] 1611766, 1612026, 1612744, 1612745, 1612747, 1613311, 1613824, 1613829, 1613882, 1613888, 1614256, 1615118 [04:44] 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] redir: let me look at the code [04:46] 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] redir: ok. with regards to ComposeNewModelConfig, you are talking about weaving in the region defaults right? [04:49] if so, there's nothing to pass across the wire for that, so nothing from params [04:49] wallyworld: yes, currently just passing cloudSpec [04:49] but only need cloud and region [04:49] wallyworld: right nothing for the wire. [04:49] internal? [04:50] no, stuff in those dirs is just for on the wire data [04:50] wallyworld: in internal is only for wire data? [04:51] yes, internal api calls [04:51] from workes to state etc [04:51] OK. [04:51] 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] which should really be elsewhere [04:52] there needs to be a separate business service layer [04:52] but we have conflated apiserver for that [04:53] wallyworld: I'm going to pause on azure stuff and look at removing the remaining model config from the lxd provider [04:53] awesome^100 [04:54] i'd love to get all this sorted this week [04:54] thumper: blocking of user API requests to a model while it is being imported http://reviews.vapour.ws/r/5508/ [04:54] 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] no rush to review, just FYI [04:54] ok, ta [05:13] 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] 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] 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] 1610450, 1611076, 1611110, 1612099, 1612112, 1612163, 1613842 [05:22] 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] 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] 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] 1589339, 1589350, 1590699, 1590732, 1593274, 1596960, 1598127, 1600600 [05:49] 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] night juju-dev [05:49] thaks reed [05:49] ttyl [05:49] Bug # opened: 1463608, 1536885, 1543404, 1543408, 1564157, 1564500, 1566268, 1567952, 1593274, 1598127, 1600600 [05:53] Bug # changed: 1463608, 1536885, 1543404, 1543408, 1557540, 1563117, 1564157, 1564500, 1564677, 1566268, 1567952, 1593274, 1598127, 1600600 [06:11] Bug #1557540 opened: Missing help for payloads [06:11] Bug #1563117 opened: api: data race adding local charm. [06:11] Bug #1564677 opened: Create one binary for juju and all plugins [06:14] Bug # changed: 1512569, 1557540, 1563117, 1564677 [06:22] 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] ok [06:24] axw: could you take look at my small pr that reed looked at? just to give sign off? [06:24] wallyworld: sure, looking [06:49] 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] wallyworld: I was thinking that yeah [06:55] wallyworld: not too concerned [06:55] axw: ok, i'll add warning to the text [06:57] axw: axctually, i meant that you look at this one http://reviews.vapour.ws/r/5506/ [06:57] wallyworld: heh whoops [06:57] the other one may need to have other changes added [06:57] looking :) [06:57] ta [06:59] wallyworld: LGTM [06:59] ta === frankban|afk is now known as frankban [07:37] 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] anastasiamac: sure [07:38] axw: \o/ [07:38] anastasiamac: I have a meeting at 8am, so may have to be short or after that [07:39] 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] anastasiamac: and I plan to be out between 9:30 and don't-know-when looking at cars (again) [07:42] axw: that's exciting :D know what u want? [07:42] anastasiamac: there's a couple that are ok. I'm not too bothered, as long as I don't get ripped off [07:43] 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] anastasiamac: ok, sounds good [07:43] axw: i love shopping for cars :) [07:44] Bug #1615958 opened: Switch to model name does't work anymore, admin should not be allowed to switch to users model [07:44] Bug #1615960 opened: remove-machine and remove-application don't work on google cloud [08:27] fwereade: ping [08:30] dimitern: land your lxd fix and let mgz handle the packaging mess when he returns ;-) [08:30] * voidspace wants lxd working again [08:30] voidspace: :) [08:30] I might try one more time to go back to 2.0 [08:31] voidspace: yeah, and I'm not convinced there is any packaging issue anyway [08:31] I burned at least two hours on it yesterday [08:31] dimitern: it seems odd [08:31] dimitern: however I'm sure frobware wouldn't invent it - so there must be some issue [08:31] dimitern: maybe a trusty thing? [08:31] but still can't see how [08:31] I'm sure mgz will explain :-( [08:33] voidspace: it was something about building .debs that includes building the lxd source and running into conflicts [08:33] but I don't believe this is avoidable at all [08:34] it'll break if lxd changes binary compatibility, like adding an extra arg to Init() [08:44] 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] voidspace, babbageclunk: heyhey, I'm off today but you're in luck, everybody else is still asleep for the moment [08:48] fwereade: hehe [08:48] fwereade: I'm making some progress code spelunking on my own [08:48] voidspace, excellent [08:48] fwereade: but it's unfamiliar code so I'm sure you can help with some quick pointers [08:48] fwereade: IRC or hangout? [08:49] voidspace, irc probably better [08:56] 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] babbageclunk: always [08:57] babbageclunk: and stop winking [08:58] voidspace: oh, that's involuntary - I think it's my meds. [08:58] babbageclunk: :-) [08:59] babbageclunk, hahaha [09:08] o/ [09:08] fwiw I'm fixing my fubar [09:08] will need some reviewers soon [09:08] 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] \o thumper [09:14] dimitern: sounds good to me [09:14] thumper: o/ [09:14] o/ [09:14] thumper: o/ [09:14] babbageclunk: how's the laptop? [09:16] thumper: :( I'm using a loaner at the moment. [09:17] thumper: But it's super chunky - 8 cores & 32 Gb! [09:17] thumper: (the loaner, I mean) [09:17] babbageclunk: so fucked then? [09:18] thumper: And it was a pretty good test of my ansible setup scripts. [09:18] thumper: yup - just the drive, though [09:18] thumper: need to order a new ssd [09:18] * thumper nods [09:18] lose much? [09:18] here is the first branch: http://reviews.vapour.ws/r/5511/ [09:19] 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] :) [09:34] dimitern: I want to retry a merge, but I can wait if you're about to queue-up the LXD fix. [09:35] macgreagoir: I've just sent the merge comment on mine [09:36] Cool [09:43] * thumper runs all tests [09:46] prelim review anyone? http://reviews.vapour.ws/r/5512/ [09:46] I'm running all the tests now to make sure I didn't miss something [09:47] thumper: looking at both, in order [09:47] dimitern: first one has landed already [09:47] :) [09:47] it is a juju/cmd change [09:47] which the second needs [09:48] oh [09:48] ok [09:52] so far, so good [09:52] up to featuretests [09:52] worker/uniter was the other big failure [09:52] You just jinxed it! :-) [09:52] perhaps [10:14] oh poop [10:21] anyone ? http://reviews.vapour.ws/r/5513/ [10:22] real fix waiting now for the above cmd fix [10:23] babbageclunk ? ^^ [10:24] thumper: I started looking but it was longer than my attention span! I'll take another run at it. [10:24] the one above is a missed behaviour change in juju/cmd [10:25] I have an update for the big branch once that has landed [10:25] thumper: Oh, right - looking at that now [10:25] babbageclunk: thanks [10:26] thumper: LGTM [10:27] thumper: How are you verifying these? [10:27] thumper: (I mean against the old one.) [10:28] I have been looking at the test changes I did on my friday branch [10:28] and making the code like that again [10:28] then fixing other things that need fixing [10:28] gotch [10:28] thumper: 5512 lgtm, fwiw [10:29] a [10:29] wow macgreagoir, how'd you do that? sharp packets? [10:31] babbageclunk: gotch...a ? I'd been reviewing 5512 much longer than that :-) [10:34] babbageclunk, macgreagoir: 5512 just got a fresh push [10:34] * thumper runs another complete test run just to be sure [10:39] 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] ok looking for reals now [10:44] babbageclunk: thanks, I appreciate it [10:44] babbageclunk: FWIW, it isn't very exciting [10:48] thumper: Ok, done - LGTM! [10:48] thumper: It wasn't very exciting though. :) [10:55] thanks [10:55] tests all good this side [10:55] I'm submitting and signing off [10:55] laters [10:56] \o [11:02] macgreagoir: adding one more item for that list for the card you're working on please, controller version [11:04] rick_h_: ack [11:04] ty macgreagoir [11:04] dimitern: around to chat? [11:07] rick_h_: yeah, sorry - joining our 1:1 now [11:11] * babbageclunk has to reboot to enable on virtualisation! [11:17] mgz: ping [11:29] frobware: ping? [11:30] voidspace: Are you around? Do you have frobware's hacked xenial image with the fixed cloud-init? [11:30] voidspace: I'm sorry about those mean things I said this morning. [11:30] voidspace: That was before I realised I needed something from you. [11:31] babbageclunk: haha [11:31] babbageclunk: I don't - I thought cloud-init was fixed in the standard images now [11:31] babbageclunk: that's all I've been using [11:31] voidspace: hmm - my xenial instance won't start [11:34] 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] babbageclunk: oh, weird [11:34] babbageclunk: maas? [11:34] pretty sure I've had it working fine [11:37] voidspace: Well, I haven't got to the point of installing maas yet - this is just starting the controller. [11:38] voidspace: I'm using the daily build - maybe I should use something else? [11:38] babbageclunk: http://178.62.20.154/~aim/xenial-server-cloudimg-amd64-disk1.img [11:38] frobware: Thanks, I'll try that instead. [11:38] * frobware is unexpedtedly out of office today dealing with leaking pipes :( [11:39] frobware: good luck! [11:52] frobware: That worked, thanks. === ses is now known as Guest14201 [12:46] Bug #1616059 opened: Unit test failure in github.com/juju/juju/cmd/juju/application [13:11] rick_h_: late pong [13:16] Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [13:31] Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [13:31] 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] 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] Bug #1511822 opened: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [13:46] Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed [13:46] 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] voidspace: Did you have any trouble commissioning nodes in maas19? [13:57] 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] natefinch: yea, I guess I assumed folks are on the wider distribution lists [13:58] 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] babbageclunk: I didn't [13:58] voidspace: No worries, worked it out - missed a step in DHCP setup. [13:58] ah [13:59] 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] katco: dimitern ping for standup [14:17] Bug #1616098 opened: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 [14:18] 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] mgz: yes please [14:20] mgz: anything that's more than a couple of hours to jfdi [14:20] okay, thanks [14:20] that one was actually pretty short, but I'll make sure to add anything meatier [14:24] Oh, of course trying to bootstrap to two maases at once gets all confused. [14:25] rick_h_: so, should I continue working on the add-cloud stuff or... ? [14:25] natefinch: no, please grab a critical [14:26] rick_h_: will do [14:29] Bug #1616098 changed: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 [14:55] dimitern: around? [15:05] babbageclunk: yeah [15:06] 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] 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] katco: ping, got a sec? [15:10] rick_h_: yep [15:10] can you jump in https://hangouts.google.com/hangouts/_/canonical.com/developer?authuser=1 please? [15:11] babbageclunk: you need to also use maas [15:11] https://hangouts.google.com/hangouts/_/canonical.com/sorry-you're-fired?authuser=1 [15:11] dimitern: yeah, sorry, should have said that - that's what I'm testing on. [15:12] babbageclunk: and all top-level nics that have children you want to bridge need addresses\ [15:12] babbageclunk: but having that should give you multi-nic containers [15:16] 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] 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] dimitern: Cool, it totally just works! [15:26] dimitern: This juju thing's pretty neat. [15:31] babbageclunk: awesome! :) when it works.. [16:44] Bug #1536477 changed: utils/debugstatus: test failure [16:44] Bug #1538583 changed: manual provider add-machine fails immediately after bootstrap [16:44] Bug #1590161 changed: apiserver/client: panic: Session already closed [17:28] rick_h_: did you get the logs for this bug? https://bugs.launchpad.net/juju/+bug/1610880 [17:28] Bug #1610880: Downloading container templates fails in manual environment [17:29] natefinch: yes, sec. Let me find that email [17:32] 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] siv: yes, look into https://jujucharms.com/docs/2.0/authors-subordinate-services to help do something like that [17:41] 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] Can I modify the cinder driver settings post autopilot openstack deployment using my created charm? [17:50] Bug #1616149 opened: Incompatible protocol between older client and candidate server [17:57] 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] siv: check out https://jujucharms.com/docs/stable/authors-charm-store and https://jujucharms.com/docs/stable/charm-review-process [18:13] rich_h : thank you === frankban is now known as frankban|afk [18:26] Bug #1615958 changed: Switch to model name does't work anymore, admin should not be allowed to switch to users model [18:26] Bug #1615960 changed: remove-machine and remove-application don't work on google cloud [18:26] Bug #1616059 changed: Unit test failure in github.com/juju/juju/cmd/juju/application [18:26] Bug #1615986 opened: Agents failing, blocked by upgrade but no upgrade performed [18:57] postgresql-peeps: say I have an application that needs to connect to 2 separate postgresql applications [18:58] 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] charmers:^ [19:04] eeeh, s/postgresql applications/postgresql db instances/ [19:04] bdx: hey [19:05] bdx: might be better to ask in #juju [19:05] bdx: but you can define two different relations with the same interface [19:05] and that way have a scope of reacting to each relation name [19:14] my bad, thought I was on #juju ... grr [19:14] bdx: no worries! does my reply make sense? [19:15] yes, can you give more context in #juju though? [19:37] sigh... the instructions for bootstrapping to manual don't actually work :/ https://jujucharms.com/docs/stable/clouds-manual [19:50] Bug #1474607 changed: worker/uniter/relation: HookQueueSuite.TestAliveHookQueue failure [19:50] Bug #1616197 opened: juju restore-backup error [20:08] marcoceppi: i see now [20:08] marcoceppi: thx [20:08] exactly what I was thinking [20:31] thumper, ping [20:32] alexisb_: hey [20:33] thumper, can you take a look at htis bug: https://bugs.launchpad.net/juju/+bug/1616158 [20:33] Bug #1616158: Int overflow during build for Windows [20:33] * thumper looks [20:33] https://github.com/juju/juju/commit/5ac0e259560382ea0c0e2a4120e028f2613ed857 [20:33] ^^ this is the suspect commit [20:36] we don't build x86 anymore, do we? [20:36] alexisb_: poo [20:36] alexisb_: mgo is assuming a 64 bit int [20:36] seems that windows still specifies 32? [20:36] thumper: only if we're specifying a 32 bit architecture [20:37] natefinch: thoughts on the bug https://bugs.launchpad.net/juju/+bug/1616158 [20:37] Bug #1616158: Int overflow during build for Windows [20:37] mgo.v2/bson/json.go:320: constant 9007199254740992 overflows int [20:37] thumper: yeah, I was just looking at it. [20:38] int is a signed integer type that is at least 32 bits in size [20:38] ^^ language spec [20:38] how can we find out how many bits the int uses? [20:40] 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] so... let's not build with GOARCH=386 [20:41] 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] sinzui: do you know why we're building juju for windows as 32 bit? [20:41] Bug #1616149 changed: Incompatible protocol between older client and candidate server [20:42] natefinch: can you try replacing line 320 with this: [20:42] if int64(n) <= 1<<53 { [20:43] and then test the 386 [20:44] 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] hmm... [20:44] ok [20:45] ok that works [20:45] alexisb_: we have two choices [20:45] alexisb_: stop building the windows client with GOARCH=386 [20:45] alexisb_: or patch mgo [20:47] either way, we should file a bug against mgo... I'm sure it was not intentional to break 386 [20:47] natefinch: yes, *you* explained we should because Windows 64 bit is not common. We never chnged the rules you wrote. [20:47] heh [20:48] natefinch: If you believe 64bit clients are good for windows, we can change the build script in a few hours [20:49] apparently 32 bit versions stopped with windows 7 and vista [20:49] oh [20:49] no [20:49] 8.1 can still be in 32 bit [20:50] we should support 32 bit still [20:50] so... patch mgo [20:50] and file a bug etc etc [20:50] 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] we dont support 32 bit linux [20:51] and yes, 32 bit applications run on both 32 bit and 64 bit windows... the reverse is not true. [20:51] why would we do that for windows? [20:51] 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] alexisb_: previously, presumably because it was free [20:51] alexisb_: I believe that is because ubuntu no longer builds for 32 [20:51] alexisb_: i.e. no extra work [20:52] well... how many people likely to be using juju will be using 32 bit windows? [20:52] perhaps we just make it 64 bit and see who screams? [20:53] alexisb_: who makes this call? [20:53] sinzui, do we have stats on 32 bit windows client downloads [20:53] 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] alexisb_: I can get them from the milestone pages [20:56] 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] 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] Given today's hardware and defaults, I think we'd be fine saying 64 bit only windows... [20:58] I'll file a bug on mgo though [21:01] gotta run to dinner, back in a bit === natefinch is now known as natefinch-afk [21:02] https://github.com/go-mgo/mgo/issues/325 [21:26] simple review for someone: http://reviews.vapour.ws/r/5516/ [21:34] thumper: shipit, btw, you used the wrong dialect of markup [21:34] :) [21:40] w00t, current master lets me do this: `juju debug-log --replay --color --location | less -R` [21:40] for show me the log in color, no tail [21:40] marcoceppi, jcastro: ^^ [21:45] Bug #1513165 changed: Containers registered with MAAS use wrong name [22:21] Bug #1421270 changed: juju deploy failure WebSocketConnection closed [22:32] redir: did you want to chat? [22:32] y [22:32] brt [22:33] thumper: --color isn't default ;) [22:33] marcoceppi: yes it is [22:34] oh, well I saw it explicitly called out [22:34] marcoceppi: but just like ls, if it isn't a terminal, it isn't there by default [22:34] oh, because of the detection stuff, nvm [22:34] :) [22:57] meh, squid never comes ok out of a reboot [23:11] perrito666: oh, is that what does it? [23:11] hadn't worked that out [23:11] thumper: at least for me, needs to restart squid-deb-proxy [23:11] do you clear out the cache as well? [23:11] I had always assumed that was necessary [23:14] thumper: I find it empty, I assume it empties on reboot? [23:14] * thumper shrugs [23:14] nah, that is not the cache, my bad [23:14] was looking at wrong dir [23:14] I dont clean it [23:18] alexisb_: standup? we miss you [23:32] Hey thumper! Long time no see. [23:32] o/ [23:32] Could you review this for me? https://github.com/juju/gomaasapi/pull/56 [23:37] thumper: ^^ [23:38] * thumper looks [23:41] babbageclunk: LGTM [23:41] thumper: Awse. Thanks! [23:48] is it me or we all sound like daft punk songs in this call?