[00:44] babbageclunk: I just need to get some more context on that code before chatting [00:48] axw_: ok - the start agent code or the ebs stuff? [00:48] babbageclunk: ebs [00:48] cool [00:49] babbageclunk: for the ebs thing, I think you should just compare the pool's storage provider type to the model provider type. ec2 can have ebs, maas can have maas, etc. [00:49] babbageclunk: rather than looking at the name of the pool, or treating ec2/ebs specially [00:49] axw_: ok, that sounds nicer. [00:50] axw_: so filter out any that don't match the model provider type [00:50] babbageclunk: yes, but they don't all match exactly. you'll need a hard-coded table [00:51] axw_: Right. [00:52] babbageclunk: is there something else you wanted to chat about? we can grab another hangout [00:53] axw_: Just an opinion really - I was just looking in start-agents and it uses sudo service start, which should work on either, right? It's just a matter of working out which machines it needs to be run on post-agent-upgrade. [00:54] axw_: I'm tempted to use the saved machines that rollback-agents uses. [00:54] axw_: Does that sound reasonable or hacky to you? [00:55] work on either what? started or stopped? xenial or trusty? [00:55] babbageclunk: ^ [00:56] axw_: oh sorry - 1.25 or 2, I guess. But also xenial or trusty. (I didn't realise service still worked on xenial.) [00:57] babbageclunk: ah ok. yes, should be fine on both - names haven't changed AFAIK [00:57] babbageclunk: using the saved list sounds fine [00:57] axw_: cool. [00:57] axw_: thanks - I'll make that change to the export code and land it. [00:58] babbageclunk: sounds good, thanks [01:18] thumper, babbageclunk: just to follow up the issue from earlier where the elasticsearch would start on a default vpc, and bounce when deployed to non-default vpc with a space constraint [01:18] http://paste.ubuntu.com/25435596/ [01:19] ^ I find that in the elasticsearch.log [01:20] strange I only get that when deployed to a space [01:24] bdx: what's the diff in the ifconfig of the two differently deployed setups? [01:26] not-working: http://paste.ubuntu.com/25435632/ [01:26] working: http://paste.ubuntu.com/25435639/ [01:27] nothing... other then the hardware address and ip/ip6 [01:56] Bug #1701481 changed: juju 1.25 leaks memory (1.25.11+)

[01:56] I made a bug with the maintainers of the elasticsearch charm ... here's the link https://bugs.launchpad.net/elasticsearch-charm/+bug/1714126 [01:56] Bug #1714126: Elasticsearch won't start when deployed to a space [01:59] Bug #1701481 opened: juju 1.25 leaks memory (1.25.11+)

[02:08] Bug #1701481 changed: juju 1.25 leaks memory (1.25.11+)

[02:13] wallyworld: when did we move from mongo 2.4 to mongo 3.2? [02:13] hmmm, a while back. i think we did it for juju 2.0 actually [02:13] as we were part way through upgrade steps for 2.4->2.6->3.2 [02:14] and we aborted since for 2.0 we didn;t need that [02:56] Bug #1714130 opened: juju reports units in non-existent OpenStack availability zones

[03:10] * babbageclunk goes for a run [05:49] axw_: I've updated https://github.com/juju/1.25-upgrade/pull/20, can you take another look please? [05:50] axw_: took a while to get it tested - I had a successful import but when I tried to roll it back and remove the model from the target controller it killed the machines, even though I'd removed them from the model with --keep-instance beforehand. Not sure what's going on there. [05:54] babbageclunk: LGTM [05:54] axw_: ta [05:54] babbageclunk: I suspect "keep-instance" isn't removing the tags that we use to clean up [05:55] axw_: yeah, I think that's it too. [05:56] axw_: the upside is running through the upgrade steps fresh is pointing out places where I was expecting the toolsDir to exist and it doesn't yet. [05:57] babbageclunk: for example? [05:59] axw_: well, at the moment it's only created in upgrade-agents, but import (which needs to run first since it uses the agent.conf to connect to state) was trying to download tools into it. [06:00] okey dokey [06:01] axw_: ha, also running things without --debug is showing that I really need some helpful output when an import succeeds. [06:33] juju/juju has finally hit 1000 stars [06:34] * axw_ listens out for fireworks and jingling money sacks === axw_ is now known as axw [06:38] axw: hah ^_^ [06:56] heh === frankban|afk is now known as frankban [08:35] axw: if you have a chance before eod, here's a PR, or else whenever https://github.com/juju/juju/pull/7813 [08:36] wallyworld: ok [08:37] ta, it's a folloeup from the one you looked at yersterday [09:39] axw: thank you [10:22] yay, thanks for reviews axw! [16:05] kwmonroe: halp! [16:06] sup rick_h? [16:06] kwmonroe: I've got an INTERFACE_PATH defined and an updated grafana-source interface code there edited. [16:07] kwmonroe: now how do I tell charm build to use that locally checked out version of the interface to make sure the charm works with the changes? [16:07] i can tell where this is going. you've mistaken me for cory_fu ;) [16:07] kwmonroe: yea, but you're all helpful and use this stuff :P [16:07] cory_fu: also halp then please kthx :) ^ [16:07] kwmonroe: has abandoned me in my hour of need [16:07] well ok then... so, if you have INTERFACE_PATH and do not use "charm build --no-local-layers", then the build should just work to pick up your local interface changes [16:08] so rick_h, by default, charm build will prefer your local bits. it's only when you specify "--no-local-layers" that it ignores included layers/interfaces. [16:08] kwmonroe: what files does that go into to check if the code is there? [16:08] rick_h: As long as INTERFACE_PATH is set in your env to a directory containing a copy of that layer, named as the layer name, it should use it. [16:09] rick_h: It looks like there's a bug where charm-build will tell you that it's using a local layer for regular layers, but not for interface layers [16:10] rick_h: I opened an issue for it: https://github.com/juju/charm-tools/issues/340 [16:11] rick_h: So, if INTERFACE_PATH=/tmp/interfaces; and you want a local copy of interface:grafana-source, then it should be checked out in /tmp/interfaces/graphana-source [16:22] cory_fu: ok, where's the interface stuff build int the build charm? I want ot grep/check the source there to see if it's in fact there [16:23] hooks/relations/ [16:23] rick_h: ^ === frankban is now known as frankban|afk [16:28] cory_fu: <3 ty I had a typo in my path and the output doesn't say it's doing anything differently but fixing my path and checking the source I see it updated now [16:38] hi all - what do i need to do to deploy series: artful with juju at this time? i'm getting https://bugs.launchpad.net/juju/+bug/1714305 with agent-stream proposed. [16:38] Bug #1714305: artful: no matching agent binaries available [16:39] beisner: since there's no agents released it needs to be uploaded from the client which means it needs to be deployed from an artful machine? [16:39] beisner: balloons correct me here, I feel like there's got to be something I'm forgetting. ^ [16:39] ooo weird, that'll be a problem for us rick_h [16:40] beisner: yea, I mean agents are compiled binaries for the series, no release has had them with artful yet I don't think...so it's got to be supplied from the outside. I must be missing something if we've done any testing/etc yet. [17:27] hey, did I see something coming over the wire about replacing creds? [17:28] for a model [17:28] or was that just for a controller [17:41] anyone seen failed to create relation egress networks: forbidden transaction: references unknown collection "relationNetworks" before? [17:44] bdx: it's in a controller working out how to hook things up [17:45] rick_h: ^ is that a mongo error? [17:46] stokachu: seems like it. I'd assme relationNetworks is in the CMR feature flag [17:46] stokachu: so maybe something landed that missed the feature flagging bit? [17:47] yea possible, this user is running from edge [17:49] rick_h: lol it is [17:49] https://travis-ci.org/conjure-up/conjure-up/builds/270515922#L866 [17:49] ugh [17:50] stokachu: yea, so you could try turning on the feature flag and seeing if it works out and file a bug and let wallyworld know what's up [17:50] export JUJU_DEV_FEATURE_FLAGS=cross-model [17:50] but that has to be done pre-bootstrap [17:51] ok [17:53] wallyworld: https://bugs.launchpad.net/juju/+bug/1714318 [17:53] Bug #1714318: juju fails to bootstrap with "references unknown collection "relationNetworks"" [18:58] rick_h balloons - with artful in freeze, release just around the corner, we need to be able to deploy/test it. other than deploying from a client on an artful machine, what options do we have? [21:00] stokachu: rick_h: damn, will fix straight away this morning. it's almost time we turn off the cross model feature flag [21:01] wallyworld: \o/ [21:01] i just want to get the data model and api stable; we're almost there [21:09] wallyworld: can't wait for it :D [21:13] wallyworld: i also have this one https://bugs.launchpad.net/juju/+bug/1711019 [21:13] Bug #1711019: vsphere: cache VMDKs in datastore to avoid repeated downloads and firewalled hosts [21:14] wallyworld: more people are running into where they dont like having the images downloaded to their local machine [21:14] and also the firewall issue [21:15] axw: ^ [21:27] stokachu: ok, we'll look into it [21:27] wallyworld: ty! [22:02] Happy Birthday thomi! [22:02] hah wrong channel sorry [22:03] wtf http://paste.ubuntu.com/25441085/ [22:03] just added a model, deployed some stuff to it [22:03] then I go to add another [22:03] and WHOAMMI [22:03] ERROR cannot obtain authorization to collect usage metrics: failed to authorize reseller plan [22:04] bdx, we're in the middle of a db migration, it's the planned outage i emailed about on the ml [22:05] oooOOooo [22:05] :) [22:05] bdx, sorry for the trouble. i'll let you know when it's back [22:05] no worries [22:05] cmars: thx [22:22] wallyworld: have a minute or two to review my pr? config-changed hook one [22:23] hml: yep, will do [22:25] hml: initial comment - if we refresh and get life, we don't also need u.st.life(u.tag) [22:29] hml: also, i think we can drop the facade version check as the controller is always updated first before the unit agents [22:29] wallyworld: okay [22:30] hml: and probably we can drop the embedding of the common.Life stuff since it's no longer used [22:30] on the client side anyway [22:37] hml: just a few small things, otherwise looks good [22:38] wallyworld: thx - i’ll get working on those [22:38] hml: also, would be worth just another manual bootstrap and test just to be sure [22:38] if not already done [22:39] wallyworld:I’ve done a couple - a couple more won’t hurt [22:39] bdx, hey, we should be all done with the maintenance, are you able to create models now? [22:40] cmars: yea, good to go! [22:40] bdx, \o/ ok, glad to hear [22:42] cmars: what was the upgrade from -> to ? [22:43] bdx, it was an VM migration to a different openstack VM host [22:44] ahh nice [22:44] I remember those days [22:45] thank god for openstack [23:33] wallyworld: looks like common.Life is still used in the uniter, but i removed the version check [23:34] we should look at that usage [23:34] see if it should be replaced by refresh [23:49] wallyword: application in uniter uses it, not just unit, but perhaps unit should use refresh instead