| axw_ | babbageclunk: I just need to get some more context on that code before chatting | 00:44 |
|---|---|---|
| babbageclunk | axw_: ok - the start agent code or the ebs stuff? | 00:48 |
| axw_ | babbageclunk: ebs | 00:48 |
| babbageclunk | cool | 00:48 |
| 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:49 |
| 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:50 |
| babbageclunk | axw_: Right. | 00:51 |
| axw_ | babbageclunk: is there something else you wanted to chat about? we can grab another hangout | 00:52 |
| 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:53 |
| 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:54 |
| axw_ | work on either what? started or stopped? xenial or trusty? | 00:55 |
| axw_ | babbageclunk: ^ | 00:55 |
| 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:56 |
| 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:57 |
| axw_ | babbageclunk: sounds good, thanks | 00:58 |
| 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:18 |
| bdx | ^ I find that in the elasticsearch.log | 01:19 |
| bdx | strange I only get that when deployed to a space | 01:20 |
| rick_h | bdx: what's the diff in the ifconfig of the two differently deployed setups? | 01:24 |
| bdx | not-working: http://paste.ubuntu.com/25435632/ | 01:26 |
| bdx | working: http://paste.ubuntu.com/25435639/ | 01:26 |
| bdx | nothing... other then the hardware address and ip/ip6 | 01:27 |
| 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:56 |
| 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> | 01:59 |
| 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:08 |
| 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:13 |
| wallyworld | and we aborted since for 2.0 we didn;t need that | 02:14 |
| mup | Bug #1714130 opened: juju reports units in non-existent OpenStack availability zones <juju:Incomplete> <juju-core:New> <https://launchpad.net/bugs/1714130> | 02:56 |
| * babbageclunk goes for a run | 03:10 | |
| babbageclunk | axw_: I've updated https://github.com/juju/1.25-upgrade/pull/20, can you take another look please? | 05:49 |
| 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:50 |
| 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:54 |
| babbageclunk | axw_: yeah, I think that's it too. | 05:55 |
| 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:56 |
| axw_ | babbageclunk: for example? | 05:57 |
| 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. | 05:59 |
| axw_ | okey dokey | 06:00 |
| babbageclunk | axw_: ha, also running things without --debug is showing that I really need some helpful output when an import succeeds. | 06:01 |
| axw_ | juju/juju has finally hit 1000 stars | 06:33 |
| * axw_ listens out for fireworks and jingling money sacks | 06:34 | |
| === axw_ is now known as axw | ||
| veebers | axw: hah ^_^ | 06:38 |
| thumper | heh | 06:56 |
| === frankban|afk is now known as frankban | ||
| wallyworld | axw: if you have a chance before eod, here's a PR, or else whenever https://github.com/juju/juju/pull/7813 | 08:35 |
| axw | wallyworld: ok | 08:36 |
| wallyworld | ta, it's a folloeup from the one you looked at yersterday | 08:37 |
| wallyworld | axw: thank you | 09:39 |
| babbageclunk | yay, thanks for reviews axw! | 10:22 |
| rick_h | kwmonroe: halp! | 16:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| cory_fu | rick_h: I opened an issue for it: https://github.com/juju/charm-tools/issues/340 | 16:10 |
| 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:11 |
| 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:22 |
| cory_fu | hooks/relations/<interface-name> | 16:23 |
| cory_fu | rick_h: ^ | 16:23 |
| === frankban is now known as frankban|afk | ||
| 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:28 |
| 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:38 |
| 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:39 |
| 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. | 16:40 |
| bdx | hey, did I see something coming over the wire about replacing creds? | 17:27 |
| bdx | for a model | 17:28 |
| bdx | or was that just for a controller | 17:28 |
| stokachu | anyone seen failed to create relation egress networks: forbidden transaction: references unknown collection "relationNetworks" before? | 17:41 |
| rick_h | bdx: it's in a controller working out how to hook things up | 17:44 |
| stokachu | rick_h: ^ is that a mongo error? | 17:45 |
| 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:46 |
| stokachu | yea possible, this user is running from edge | 17:47 |
| 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:49 |
| 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:50 |
| stokachu | ok | 17:51 |
| 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> | 17:53 |
| 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? | 18:58 |
| wallyworld | stokachu: rick_h: damn, will fix straight away this morning. it's almost time we turn off the cross model feature flag | 21:00 |
| stokachu | wallyworld: \o/ | 21:01 |
| wallyworld | i just want to get the data model and api stable; we're almost there | 21:01 |
| stokachu | wallyworld: can't wait for it :D | 21:09 |
| 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:13 |
| 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:14 |
| stokachu | axw: ^ | 21:15 |
| wallyworld | stokachu: ok, we'll look into it | 21:27 |
| stokachu | wallyworld: ty! | 21:27 |
| veebers | Happy Birthday thomi! | 22:02 |
| veebers | hah wrong channel sorry | 22:02 |
| 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:03 |
| cmars | bdx, we're in the middle of a db migration, it's the planned outage i emailed about on the ml | 22:04 |
| 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:05 |
| hml | wallyworld: have a minute or two to review my pr? config-changed hook one | 22:22 |
| wallyworld | hml: yep, will do | 22:23 |
| wallyworld | hml: initial comment - if we refresh and get life, we don't also need u.st.life(u.tag) | 22:25 |
| 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:29 |
| 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:30 |
| wallyworld | hml: just a few small things, otherwise looks good | 22:37 |
| 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:38 |
| 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:39 |
| bdx | cmars: yea, good to go! | 22:40 |
| cmars | bdx, \o/ ok, glad to hear | 22:40 |
| bdx | cmars: what was the upgrade from -> to ? | 22:42 |
| cmars | bdx, it was an VM migration to a different openstack VM host | 22:43 |
| bdx | ahh nice | 22:44 |
| bdx | I remember those days | 22:44 |
| bdx | thank god for openstack | 22:45 |
| hml | wallyworld: looks like common.Life is still used in the uniter, but i removed the version check | 23:33 |
| wallyworld | we should look at that usage | 23:34 |
| wallyworld | see if it should be replaced by refresh | 23:34 |
| hml | wallyword: application in uniter uses it, not just unit, but perhaps unit should use refresh instead | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!