[00:44] <axw_> babbageclunk: I just need to get some more context on that code before chatting
[00:48] <babbageclunk> axw_: ok - the start agent code or the ebs stuff?
[00:48] <axw_> babbageclunk: ebs
[00:48] <babbageclunk> cool
[00:49] <axw_> 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] <axw_> babbageclunk: rather than looking at the name of the pool, or treating ec2/ebs specially
[00:49] <babbageclunk> axw_: ok, that sounds nicer.
[00:50] <babbageclunk> axw_: so filter out any that don't match the model provider type
[00:50] <axw_> babbageclunk: yes, but they don't all match exactly. you'll need a hard-coded table
[00:51] <babbageclunk> axw_: Right.
[00:52] <axw_> babbageclunk: is there something else you wanted to chat about? we can grab another hangout
[00:53] <babbageclunk> axw_: Just an opinion really - I was just looking in start-agents and it uses sudo service <agent> 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] <babbageclunk> axw_: I'm tempted to use the saved machines that rollback-agents uses.
[00:54] <babbageclunk> axw_: Does that sound reasonable or hacky to you?
[00:55] <axw_> work on either what? started or stopped? xenial or trusty?
[00:55] <axw_> babbageclunk: ^
[00:56] <babbageclunk> 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] <axw_> babbageclunk: ah ok. yes, should be fine on both - names haven't changed AFAIK
[00:57] <axw_> babbageclunk: using the saved list sounds fine
[00:57] <babbageclunk> axw_: cool.
[00:57] <babbageclunk> axw_: thanks - I'll make that change to the export code and land it.
[00:58] <axw_> babbageclunk: sounds good, thanks
[01:18] <bdx> 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] <bdx> http://paste.ubuntu.com/25435596/
[01:19] <bdx> ^ I find that in the elasticsearch.log
[01:20] <bdx> strange I only get that when deployed to a space
[01:24] <rick_h> bdx: what's the diff in the ifconfig of the two differently deployed setups?
[01:26] <bdx> not-working: http://paste.ubuntu.com/25435632/
[01:26] <bdx> working: http://paste.ubuntu.com/25435639/
[01:27] <bdx> nothing... other then the hardware address and ip/ip6
[01:56] <mup> Bug #1701481 changed: juju 1.25 leaks memory (1.25.11+) <canonical-bootstack> <sts> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1701481>
[01:56] <bdx> 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] <mup> Bug #1714126: Elasticsearch won't start when deployed to a space <Elasticsearch Charm:New> <https://launchpad.net/bugs/1714126>
[01:59] <mup> Bug #1701481 opened: juju 1.25 leaks memory (1.25.11+) <canonical-bootstack> <sts> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1701481>
[02:08] <mup> Bug #1701481 changed: juju 1.25 leaks memory (1.25.11+) <canonical-bootstack> <sts> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1701481>
[02:13] <thumper> wallyworld: when did we move from mongo 2.4 to mongo 3.2?
[02:13] <wallyworld> hmmm, a while back. i think we did it for juju 2.0 actually
[02:13] <wallyworld> as we were part way through upgrade steps for 2.4->2.6->3.2
[02:14] <wallyworld> and we aborted since for 2.0 we didn;t need that
[02:56] <mup> Bug #1714130 opened: juju reports units in non-existent OpenStack availability zones <juju:Incomplete> <juju-core:New> <https://launchpad.net/bugs/1714130>
[03:10]  * babbageclunk goes for a run
[05:49] <babbageclunk> axw_: I've updated https://github.com/juju/1.25-upgrade/pull/20, can you take another look please?
[05:50] <babbageclunk> 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] <axw_> babbageclunk: LGTM
[05:54] <babbageclunk> axw_: ta
[05:54] <axw_> babbageclunk: I suspect "keep-instance" isn't removing the tags that we use to clean up
[05:55] <babbageclunk> axw_: yeah, I think that's it too.
[05:56] <babbageclunk> 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] <axw_> babbageclunk: for example?
[05:59] <babbageclunk> 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] <axw_> okey dokey
[06:01] <babbageclunk> axw_: ha, also running things without --debug is showing that I really need some helpful output when an import succeeds.
[06:33] <axw_> juju/juju has finally hit 1000 stars
[06:34]  * axw_ listens out for fireworks and jingling money sacks
[06:38] <veebers> axw: hah ^_^
[06:56] <thumper> heh
[08:35] <wallyworld> axw: if you have a chance before eod, here's a PR, or else whenever https://github.com/juju/juju/pull/7813
[08:36] <axw> wallyworld: ok
[08:37] <wallyworld> ta, it's a folloeup from the one you looked at yersterday
[09:39] <wallyworld> axw: thank you
[10:22] <babbageclunk> yay, thanks for reviews axw!
[16:05] <rick_h> kwmonroe: halp!
[16:06] <kwmonroe> sup rick_h?
[16:06] <rick_h> kwmonroe: I've got an INTERFACE_PATH defined and an updated grafana-source interface code there edited.
[16:07] <rick_h> 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] <kwmonroe> i can tell where this is going.  you've mistaken me for cory_fu ;)
[16:07] <rick_h> kwmonroe: yea, but you're all helpful and use this stuff :P
[16:07] <rick_h> cory_fu: also halp then please kthx :) ^
[16:07] <rick_h> kwmonroe: has abandoned me in my hour of need
[16:07] <kwmonroe> 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] <kwmonroe> 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] <rick_h> kwmonroe: what files does that go into to check if the code is there?
[16:08] <cory_fu> 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] <cory_fu> 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] <cory_fu> rick_h: I opened an issue for it: https://github.com/juju/charm-tools/issues/340
[16:11] <cory_fu> 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] <rick_h> 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] <cory_fu> hooks/relations/<interface-name>
[16:23] <cory_fu> rick_h: ^
[16:28] <rick_h> 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] <beisner> 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] <mup> Bug #1714305: artful: no matching agent binaries available <openstack> <uosci> <juju:New> <https://launchpad.net/bugs/1714305>
[16:39] <rick_h> 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] <rick_h> beisner: balloons correct me here, I feel like there's got to be something I'm forgetting. ^
[16:39] <beisner> ooo weird, that'll be a problem for us rick_h
[16:40] <rick_h> 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] <bdx> hey, did I see something coming over the wire about replacing creds?
[17:28] <bdx> for a model
[17:28] <bdx> or was that just for a controller
[17:41] <stokachu> anyone seen failed to create relation egress networks: forbidden transaction: references unknown collection "relationNetworks" before?
[17:44] <rick_h> bdx: it's in a controller working out how to hook things up
[17:45] <stokachu> rick_h: ^ is that a mongo error?
[17:46] <rick_h> stokachu: seems like it. I'd assme relationNetworks is in the CMR feature flag
[17:46] <rick_h> stokachu: so maybe something landed that missed the feature flagging bit?
[17:47] <stokachu> yea possible, this user is running from edge
[17:49] <stokachu> rick_h: lol it is
[17:49] <stokachu> https://travis-ci.org/conjure-up/conjure-up/builds/270515922#L866
[17:49] <stokachu> ugh
[17:50] <rick_h> 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] <rick_h>  export JUJU_DEV_FEATURE_FLAGS=cross-model
[17:50] <rick_h> but that has to be done pre-bootstrap
[17:51] <stokachu> ok
[17:53] <stokachu> wallyworld: https://bugs.launchpad.net/juju/+bug/1714318
[17:53] <mup> Bug #1714318: juju fails to bootstrap with "references unknown collection "relationNetworks"" <conjure> <juju:New> <https://launchpad.net/bugs/1714318>
[18:58] <beisner> 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] <wallyworld> stokachu: rick_h: damn, will fix straight away this morning. it's almost time we turn off the cross model feature flag
[21:01] <stokachu> wallyworld: \o/
[21:01] <wallyworld> i just want to get the data model and api stable; we're almost there
[21:09] <stokachu> wallyworld: can't wait for it :D
[21:13] <stokachu> wallyworld: i also have this one https://bugs.launchpad.net/juju/+bug/1711019
[21:13] <mup> Bug #1711019: vsphere: cache VMDKs in datastore to avoid repeated downloads and firewalled hosts <conjure> <juju:Triaged> <https://launchpad.net/bugs/1711019>
[21:14] <stokachu> wallyworld: more people are running into where they dont like having the images downloaded to their local machine
[21:14] <stokachu> and also the firewall issue
[21:15] <stokachu> axw: ^
[21:27] <wallyworld> stokachu: ok, we'll look into it
[21:27] <stokachu> wallyworld: ty!
[22:02] <veebers> Happy Birthday thomi!
[22:02] <veebers> hah wrong channel sorry
[22:03] <bdx> wtf http://paste.ubuntu.com/25441085/
[22:03] <bdx> just added a model, deployed some stuff to it
[22:03] <bdx> then I go to add another
[22:03] <bdx> and WHOAMMI
[22:03] <bdx> ERROR cannot obtain authorization to collect usage metrics: failed to authorize reseller plan
[22:04] <cmars> bdx, we're in the middle of a db migration, it's the planned outage i emailed about on the ml
[22:05] <bdx> oooOOooo
[22:05] <bdx> :)
[22:05] <cmars> bdx, sorry for the trouble. i'll let you know when it's back
[22:05] <bdx> no worries
[22:05] <bdx> cmars: thx
[22:22] <hml> wallyworld: have a minute or two to review my pr?  config-changed hook one
[22:23] <wallyworld> hml: yep, will do
[22:25] <wallyworld> hml: initial comment - if we refresh and get life, we don't also need u.st.life(u.tag)
[22:29] <wallyworld> hml: also, i think we can drop the facade version check as the controller is always updated first before the unit agents
[22:29] <hml> wallyworld: okay
[22:30] <wallyworld> hml: and probably we can drop the embedding of the common.Life stuff since it's no longer used
[22:30] <wallyworld> on the client side anyway
[22:37] <wallyworld> hml: just a few small things, otherwise looks good
[22:38] <hml> wallyworld: thx - i’ll get working on those
[22:38] <wallyworld> hml: also, would be worth just another manual bootstrap and test just to be sure
[22:38] <wallyworld> if not already done
[22:39] <hml> wallyworld:I’ve done a couple - a couple more won’t hurt
[22:39] <cmars> bdx, hey, we should be all done with the maintenance, are you able to create models now?
[22:40] <bdx> cmars: yea, good to go!
[22:40] <cmars> bdx, \o/ ok, glad to hear
[22:42] <bdx> cmars: what was the upgrade from -> to ?
[22:43] <cmars> bdx, it was an VM migration to a different openstack VM host
[22:44] <bdx> ahh nice
[22:44] <bdx> I remember those days
[22:45] <bdx> thank god for openstack
[23:33] <hml> wallyworld: looks like common.Life is still used in the uniter, but i removed the version check
[23:34] <wallyworld> we should look at that usage
[23:34] <wallyworld> see if it should be replaced by refresh
[23:49] <hml> wallyword: application in uniter uses it, not just unit, but perhaps unit should use refresh instead