| xwwt | have just a couple of steps remaining | 00:00 |
|---|---|---|
| rick_h_ | alexisb: lol | 00:01 |
| wallyworld | menn0: sorry, just got out of meetings, can talk now | 00:04 |
| menn0 | wallyworld: thanks. which hangout? | 00:05 |
| wallyworld | https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand | 00:06 |
| mwhudson | oh the cannot find encoding bug is fixed in trusty-proposed now | 00:18 |
| mup | Bug #1496639 opened: juju get incorrectly reports boolean default values <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1496639> | 00:24 |
| * thumper wanders off to make a coffee | 01:20 | |
| mup | Bug #1496652 opened: Relation settings watcher exposes txn-revno to uniter <juju-core:In Progress> <https://launchpad.net/bugs/1496652> | 01:24 |
| mup | Bug #1496652 changed: Relation settings watcher exposes txn-revno to uniter <juju-core:In Progress> <https://launchpad.net/bugs/1496652> | 01:33 |
| mup | Bug #1496652 opened: Relation settings watcher exposes txn-revno to uniter <juju-core:In Progress> <https://launchpad.net/bugs/1496652> | 01:39 |
| thumper | menn0: here is the master branch for the uniter upgrade step work http://reviews.vapour.ws/r/2682/diff/# | 01:52 |
| thumper | menn0: just a forward port of the 1.25 with the new step added | 01:53 |
| axw | wallyworld: FYI I'm doing the tweak to unblock master, just being held up writing a test | 01:54 |
| wallyworld | ty, saw the bug comment | 01:54 |
| thumper | man I love my coffee machine | 01:54 |
| menn0 | thumper: looking | 01:54 |
| thumper | davecheney: re bug 1465317, what's the current status of the fixes you have been doing? | 02:03 |
| mup | Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:Triaged> <juju-core 1.25:Triaged> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317> | 02:03 |
| thumper | davecheney: should we assign this bug to you? | 02:04 |
| thumper | for the work you have been doing? | 02:04 |
| menn0 | thumper: ship it | 02:08 |
| thumper | menn0: cheers | 02:08 |
| axw | wallyworld: http://reviews.vapour.ws/r/2683/ | 02:12 |
| wallyworld | looking | 02:13 |
| menn0 | thumper, wallyworld: i'm beginning to think this idea of Juju using MAAS' cached images is a non-starter | 02:13 |
| thumper | because? | 02:13 |
| menn0 | thumper, wallyworld: the images don't appear to be in the same format | 02:13 |
| wallyworld | not surprised | 02:14 |
| wallyworld | i was sort of afaid of that | 02:14 |
| menn0 | the MAAS images are a tarball of a root filesystem | 02:14 |
| thumper | menn0: document your findings on the bug, and we'll look for another solution | 02:14 |
| menn0 | the images served by the public server are a tarball with the kernal separate and a .img file which contains the root filesystem | 02:15 |
| menn0 | thumper: ok | 02:15 |
| menn0 | thumper: should I remove it from the 1.25-beta2 milestone? | 02:15 |
| wallyworld | axw: ship it, thanks for temp fix | 02:16 |
| thumper | um... yeah | 02:16 |
| axw | wallyworld: ta | 02:16 |
| wallyworld | thumper: menn0: this maas image thing is a direct request from dan w so i suspect we'll be asked to make it work somehow | 02:17 |
| wallyworld | by we, i mean us and maas | 02:17 |
| thumper | wallyworld: perhaps mass need to cache the initial format, then unpack for themselves | 02:18 |
| * thumper hopes it is more maas | 02:18 | |
| wallyworld | yes | 02:18 |
| * wallyworld does too | 02:18 | |
| axw | I think there was a mailing thread list about this stuff a while ago... | 02:18 |
| wallyworld | rings a bell | 02:18 |
| menn0 | i'll have a look around | 02:19 |
| menn0 | and i'll still send an email to relevant people about this | 02:19 |
| axw | menn0: not sure how relevant, "Juju + MAAS + Image Downloads" from may 2014 | 02:20 |
| axw | err sorry sept | 02:20 |
| axw | can't read US dates :) | 02:21 |
| menn0 | axw: i've seen that one | 02:21 |
| menn0 | axw: that's the discussion around the ticket i'm looking at | 02:21 |
| axw | ah ok | 02:21 |
| menn0 | axw: no one seems to have checked if the image formats are actually the same :) | 02:21 |
| axw | heh | 02:21 |
| menn0 | maybe it's easy to convert between them | 02:22 |
| menn0 | i'm just pulling down the maas code now to check a few things | 02:22 |
| menn0 | then i'll send this email | 02:22 |
| wallyworld | axw: going afk for an hour or so, bbiab | 02:42 |
| axw | wallyworld: no worries, ttyl | 02:43 |
| menn0 | wallyworld, thumper: bradm mentioned this to me when I was chatting to him earlier: https://bugs.launchpad.net/juju-core/+bug/1496639 | 02:53 |
| mup | Bug #1496639: juju get incorrectly reports boolean default values <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1496639> | 02:53 |
| menn0 | does that ring any bells? | 02:53 |
| thumper | menn0: nope | 03:07 |
| thumper | but interesting | 03:07 |
| menn0 | thumper: attach it to 1.25-beta2? | 03:13 |
| thumper | menn0: sure, why not | 03:13 |
| thumper | hmm... | 03:15 |
| thumper | wrote a simple charm to test a problem | 03:15 |
| thumper | but the charm's default apt-get is failing | 03:15 |
| thumper | E: There are problems and -y was used without --force-yes | 03:16 |
| thumper | seems a bit weird | 03:16 |
| thumper | was my squid-deb-proxy being out of date somehow | 03:55 |
| thumper | miken: here I am then :) | 03:58 |
| thumper | trying to reproduce the failure | 03:58 |
| miken | Yep, re-running my mojo spec with the same code revision that caused the config-changed failure, to see if I still see the issue too. | 03:59 |
| thumper | miken: this one https://bugs.launchpad.net/juju-core/+bug/1494542 | 03:59 |
| mup | Bug #1494542: config-changed error does not cause error state <juju-core:In Progress by thumper> <juju-core 1.24:In Progress by thumper> <juju-core 1.25:Triaged by thumper> <https://launchpad.net/bugs/1494542> | 03:59 |
| thumper | miken: ah... are you able to run the environment with --debug? | 03:59 |
| thumper | miken: then let me have the logs? | 03:59 |
| thumper | I'm not able to reproduce with my trivial failing charm | 04:00 |
| miken | possibly - I'll let the current run finish so I know whether I can reproduce it. If I can, is that an option I can add to the juju-deployer call? /me checks | 04:01 |
| thumper | no idea | 04:01 |
| thumper | miken: does the deployer bootstrap for you? | 04:01 |
| thumper | it is juju I want in debug mode, not really the deplower | 04:02 |
| thumper | yer | 04:02 |
| rick_h_ | thumper: which problem is this? deployer/config-changed sounds like the thing eric and natefinch-afk fixed today?: | 04:02 |
| miken | Ah - just to bootstrap. Sure. | 04:02 |
| thumper | miken: if you use --debug when bootstrapping, that flag is passed through to the remote server, and it logs everything at debug too | 04:02 |
| thumper | you can set it afterwards | 04:03 |
| thumper | but easiest if bootstrapping to just use --debug | 04:03 |
| miken | Nice. I'll try setting it now too in case it does reproduce (takes 10-15mins to run deployment) | 04:03 |
| miken | Hmm - how can I set it with the deploy already going? | 04:04 |
| thumper | juju set-env logging-config=juju=DEBUG | 04:05 |
| miken | Great | 04:05 |
| miken | rick_h_: https://bugs.launchpad.net/juju-core/+bug/1494542 | 04:05 |
| mup | Bug #1494542: config-changed error does not cause error state <juju-core:In Progress by thumper> <juju-core 1.24:In Progress by thumper> <juju-core 1.25:Triaged by thumper> <https://launchpad.net/bugs/1494542> | 04:05 |
| thumper | miken: has rick_h_ hit it too? | 04:05 |
| rick_h_ | miken: ah ok, that's different then | 04:06 |
| rick_h_ | thumper: no, the mention of a config-changed issue made me think of https://bugs.launchpad.net/juju-core/+bug/1495681 from today | 04:06 |
| mup | Bug #1495681: quickstart delployments broken in 1.24 <blocker> <ci> <quickstart> <regression> <juju-core:Invalid> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1495681> | 04:06 |
| rick_h_ | thumper: so just checking, but looks like that's different | 04:06 |
| thumper | ok | 04:06 |
| thumper | what causes quickstart to not work? | 04:06 |
| * rick_h_ goes back to hiding :) | 04:06 | |
| rick_h_ | thumper: something to do with nil values and the API that got cleaned up | 04:07 |
| thumper | rick_h_: WTH are you doing answering IRC now anyway? | 04:07 |
| thumper | rick_h_: you are setting a bad precident | 04:07 |
| rick_h_ | thumper: meeting in an hour :) | 04:07 |
| thumper | ew | 04:07 |
| thumper | well that sucks | 04:07 |
| rick_h_ | thumper: fortunately not too many of these | 04:07 |
| rick_h_ | thumper: if only all of you would move to the US :P | 04:07 |
| thumper | TBH I don't think the US would want us all | 04:09 |
| thumper | stealing all those jobs from real americans | 04:09 |
| rick_h_ | thumper: heh we just say that a lot, but we don't really care. | 04:09 |
| miken | thumper: ok, running with the same spec and code rev did reproduce it. I can give you logs, but I only switched on --debug half way through (but before the config-change error, afaict). Is it just the /var/log/juju/unit-sca-app-0.log that you're after? | 04:12 |
| thumper | yes, and machine-0.log | 04:12 |
| thumper | the unit one so we can see what it thinks | 04:12 |
| thumper | and machine-0 to check any server side changes | 04:13 |
| thumper | see where the problem is, client or server | 04:13 |
| thumper | miken: can you attach the logs to the bug plz? | 04:13 |
| miken | Ack | 04:13 |
| thumper | awesome | 04:13 |
| thumper | ta | 04:13 |
| rick_h_ | thumper: are all those safe to attach? e.g. cloud info? /me hasn't looked lately. | 04:19 |
| thumper | hmm... | 04:19 |
| thumper | I *think* so | 04:19 |
| rick_h_ | miken: might just give a quick grep for cloud creds or anything. I know there was work to not outut things but don't recall where it left off tbh | 04:20 |
| miken | rick_h_: yeah, I was just checking through after noticing that they're root:root 600 in ~/.juju/local/logs | 04:22 |
| miken | I can see lots of "Response": "'body redacted'" 's | 04:24 |
| thumper | miken: yeah, need to set the logging level to TRACE to get the data in there | 04:27 |
| * thumper is on kid duty, will check in later with the bug to look (maybe) | 04:28 | |
| thumper | I have a feeling that all work later will be emails and comments on documents | 04:28 |
| miken | thumper: YOu can grab the logs from: | 04:28 |
| miken | thumper: chinstrap.canonical.com:/home/michaeln/bug-1494542-logs.tgz If you can see there's nothing sensitive there, feel free to attach. | 04:28 |
| * thumper has to go cook dinner before school production tonight | 04:28 | |
| miken | thumper: Nice - enjoy! | 04:29 |
| thumper | miken: ok, ta | 04:29 |
| === urulama_ is now known as urulama | ||
| thumper | bad status test... embedding actual version numbers in expected output | 07:51 |
| * thumper settles down to write a few final emails with a glass of wine | 07:51 | |
| thumper | hopefully the wine will help | 07:51 |
| axw | fwereade: I would appreciate a review from you on http://reviews.vapour.ws/r/2685/ when you can. I'd particularly like validation of my assertion in settingsDocNeedsMigration... but really the whole thing is a *little* bit hairy | 07:55 |
| fwereade | axw, cheers | 07:56 |
| mup | Bug #1496750 opened: Failed worker can result in large number of goroutines and open socket connections and eventually gets picked on by the OOM killer <juju-core:New> <https://launchpad.net/bugs/1496750> | 08:40 |
| mup | Bug #1496750 changed: Failed worker can result in large number of goroutines and open socket connections and eventually gets picked on by the OOM killer <juju-core:New> <https://launchpad.net/bugs/1496750> | 08:49 |
| voidspace | jam: fwereade: stdup? | 09:01 |
| jam | voidspace: I' believe its strdup :) | 09:01 |
| voidspace | jam: :-p | 09:02 |
| mup | Bug #1496750 opened: Failed worker can result in large number of goroutines and open socket connections and eventually gets picked on by the OOM killer <juju-core:New> <https://launchpad.net/bugs/1496750> | 09:04 |
| mup | Bug #1495542 changed: 1.20.x cannot upgrade to 1.26-alpha1 <blocker> <ci> <regression> <upgrade-juju> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1495542> | 09:37 |
| bogdanteleaga | unit-err-0[1975]: 2015-09-17 09:39:11 DEBUG juju.worker.dependency engine.go:438 "metric-sender" manifold worker stopped: failed to open spool directory "/var/lib/juju/metricspool": stat /var/lib/juju/metricspool: no such file or directory | 09:42 |
| bogdanteleaga | anybody getting this on master? | 09:42 |
| ashipika | bogdanteleaga: windows? | 09:44 |
| bogdanteleaga | ashipika: trusty | 09:44 |
| bogdanteleaga | it appeared on windows as well fwiw, but it fails on trusty too | 09:44 |
| ashipika | bogdanteleaga: that's a change that landed with the maltese falcon feature branch… | 09:45 |
| ashipika | bogdanteleaga: which test did you run? | 09:45 |
| bogdanteleaga | ashipika: I'm trying to deploy a charm | 09:45 |
| ashipika | bogdanteleaga: will look into it! thanks for reporting it | 09:46 |
| ashipika | bogdanteleaga: could you please file a bug on launchpad? | 09:46 |
| bogdanteleaga | ashipika: I'll try later | 09:47 |
| ashipika | bogdanteleaga: thank you.. | 09:48 |
| jam | fwereade: voidspace: I was looking at https://github.com/juju/juju/wiki/mgo-txn-example the one thing that sticks out as odd is the "e, err = e.st.Environment()" to refresh itself | 10:08 |
| jam | it feels really strange to override the 'self' pointer, as it doesn't change the caller, just the local context, right? | 10:08 |
| fwereade | jam, rather than e.Refresh()? | 10:08 |
| jam | IMO it would be clearer if we use a real local variable there | 10:09 |
| jam | fwereade: well either Refresh or local var | 10:09 |
| fwereade | jam, i.e. `env := e` outside? | 10:09 |
| jam | fwereade: right | 10:09 |
| fwereade | jam, there's a convention in state that methods not change unexpected fields, which is why no Refresh() | 10:09 |
| fwereade | jam, I have no objection to local vars though | 10:10 |
| fwereade | jam, would probably be clearer | 10:10 |
| natefinch | +1 for not overriding the receiver... that's certain to cause confusion. | 10:10 |
| jam | fwereade: I'm fine with the no Refresh, cause I understand not wanting to have to introspect your object to see if there were any side effects. | 10:10 |
| fwereade | jam, then +1 to fixing it to use local vars | 10:10 |
| axw | anastasiamac: when you're working... please see https://github.com/axw/juju/commit/3168dd66426d018a00ff32c61b91c9141351e8b5 | 10:12 |
| voidspace | fwereade: jam: although if you *know* your data is out of date, deliberately *not* refreshing struck me as a little odd | 10:24 |
| voidspace | fwereade: jam: you're choosing to deliberately leave stale data for other "observers" | 10:24 |
| voidspace | but I haven't gone back and read the doc yet | 10:24 |
| fwereade | voidspace, all data is always stale anyway | 10:25 |
| voidspace | I guess the risk is that you leave other observers with inconsistent data, and stale data is better than inconsistent data | 10:25 |
| voidspace | fwereade: possibly stale versus we actually know this is wrong | 10:25 |
| fwereade | voidspace, it's not so much about other observers -- individual entity types are not generally goroutine-safe -- as it is about ensuring every individual client sees a consistent (if not correct) picture of the entity; part of that is putting the responsibility for Refresh in their hands, and not pre-empting it | 10:27 |
| voidspace | fwereade: right | 10:27 |
| voidspace | inconsistent data could be arbitrarily bad | 10:27 |
| voidspace | fair enough, although then it would seem that Refresh is almost never safe | 10:28 |
| fwereade | voidspace, *that said* the value of that approach is certainly diminished -- it came from a time when everything had a direct db connection, and there were many more long-lived *state.Things floating around in the system | 10:28 |
| fwereade | voidspace, almost all our state types are now very short-lived -- one API call and that's it | 10:29 |
| voidspace | fwereade: I've addressed all the issues on my PR except the txn assert and the tests for that | 10:29 |
| fwereade | voidspace, cool, thanks | 10:29 |
| voidspace | fwereade: will ping you when it's done as it's a different beast from when it was last reviewed | 10:29 |
| fwereade | voidspace, (fwiw, it's a slightly subtle notion of inconsistency -- a refresh *will* give you new, consistent data, but it potentially invalidates assumption you checked in the scope you're looking at it from. so we try to keep showing you the same picture; even if it *is* a lie, the cause of any failures will still be reported, and it's up to the client to Refresh and reconsider or just give up) | 10:32 |
| mattyw | fwereade, ping? | 10:39 |
| fwereade | mattyw, pong | 10:40 |
| mattyw | bogdanteleaga, are you blocked on that metric spool error? | 10:45 |
| voidspace | fwereade: sure, understood. A refresh at an arbitrary point on another goroutine could present a very odd view of the world to another observer. | 10:47 |
| voidspace | fwereade: so a Refresh is *only* safe if you know there are no other observers. So Refresh is probably a bit of an anti-pattern. | 10:48 |
| fwereade | voidspace, most of them aren't goroutine-safe, so the two observers are the internal and external views of the object -- but, yeah | 10:49 |
| fwereade | voidspace, (State itself should be, but most of the stuff you get from a state will not be) | 10:50 |
| voidspace | right | 10:50 |
| bogdanteleaga | mattyw: nope, it just made logs harder to read | 11:01 |
| bogdanteleaga | it does try a lot :) | 11:01 |
| mattyw | bogdanteleaga, yeah - it's the first time I've read the logs from the point of view of someone who doesn't know about the dep engine - how understandable they are leaves a lot to be desired | 11:11 |
| mattyw | bogdanteleaga, we'll fix it, thanks for bringing it up | 11:11 |
| bogdanteleaga | mattyw: np, shouldn't it create the directory itself though? it does still error differently if I create it manually | 11:13 |
| mattyw | bogdanteleaga, all of that stuff should get handled automatically when it needs it | 11:16 |
| mattyw | bogdanteleaga, but from the logs that'a all left very unclear :/ | 11:17 |
| bogdanteleaga | mattyw: oh, I think I get what you mean | 11:18 |
| anastasiamac | axw: saw :D | 11:21 |
| rogpeppe | anyone got an opinion on what HTTP status code is appropriate for the error with code params.CodeOperationBlocked | 11:48 |
| rogpeppe | ? | 11:48 |
| rogpeppe | i'm pretty sure that ErrBadRequest is not correct | 11:48 |
| rogpeppe | s/Err/Status/ | 11:48 |
| rogpeppe | perhaps StatusForbidden, I guess | 11:48 |
| jam | 403 Forbidden seems close (I understood you, but you can't do that) | 11:56 |
| jam | 409 Conflict is potentially valid (you made a request which conflicts with the fact it is currently blocked) | 11:57 |
| jam | rogpeppe: ^^ | 11:57 |
| rogpeppe | jam: i've gone with Forbidden | 11:58 |
| rogpeppe | jam: (thanks) | 11:58 |
| rogpeppe | [11:47:59] <voidspace> fwereade: sure, understood. A refresh at an arbitrary point on another goroutine could present a very odd view of the world to another observer. | 12:05 |
| rogpeppe | voidspace: just picking up on that at random | 12:06 |
| rogpeppe | voidspace: you *can* get a refresh at an arbitrary point in a goroutine | 12:06 |
| rogpeppe | voidspace: if we had shorter refresh times, it would happen more often | 12:06 |
| fwereade | rogpeppe, expand? we were thinking of Refresh calls on state types | 12:08 |
| rogpeppe | fwereade: ah, totally out of context then, ignore me :) | 12:08 |
| rogpeppe | fwereade: i always thought that it was a bit of an anti-pattern that state types had any internal state at all | 12:09 |
| fwereade | rogpeppe, yeah, I think you're right there | 12:09 |
| fwereade | rogpeppe, hey ho, we endure :) | 12:09 |
| jam | cmars: still up for meeting in 10 or so? | 12:14 |
| cmars | jam, yep, i'm in the hangout | 12:14 |
| alexisb | dimitern, ping | 12:16 |
| dimitern | alexisb, omw | 12:16 |
| frankban | axw: hi, could you please take a look at http://reviews.vapour.ws/r/2633/ ? it's proposed against a feature branch | 12:35 |
| perrito666 | abentley: ping? | 13:43 |
| abentley | perrito666: pong | 13:45 |
| perrito666 | abentley: by any chance would you know how I can get a hold of the packaging script of juju-mongodb? | 13:45 |
| abentley | perrito666: Sorry, I don't know where that's kept. On our team, sinzui is the main packager, but I don't think he did juju-mongodb. I think that was juju-core. | 13:47 |
| natefinch | katco: sorry for the late notice, I'm going to have to jet at 15 past the hour - our 2 year old threw up this morning and so I'm going to have to run an errand that my wife was going to do, while she's home with the kids. I'll only be gone an hour, but it's time sensitive. | 13:48 |
| katco | natefinch: no worries... it's just us for the standup, so shouldn't even take 15m | 13:49 |
| natefinch | katco: oh yeah, forgot eric's gone now, too. | 13:49 |
| perrito666 | abentley: thank you :) Ill keep hunting | 13:50 |
| abentley | Sorry I can't help more. | 13:51 |
| abentley | perrito666: Try jamespage: https://dogfood.paddev.net/ubuntu/+source/juju-mongodb/2.4.10-0ubuntu1 | 13:52 |
| perrito666 | abentley: you did, :) one less palce to look for | 13:52 |
| xwwt | abentley: Notes look ok. We are just looking for a time for those non-voting to be enabled | 14:18 |
| abentley | xwwt: And commitment from core on the ones we can't enable without their help. | 14:19 |
| xwwt | abentley: yeah, commitment on timing. we will continue to work through that on the release meeting too. | 14:22 |
| jamespage | abentley, perrito666: hello | 14:25 |
| perrito666 | jamespage: hello :) | 14:25 |
| rogpeppe | second part of my apiserver cleanup. reviews much appreciated. https://github.com/juju/juju/pull/3307 | 14:25 |
| perrito666 | jamespage: do you happen to know how can I get a hold of the scripts required to create a custom package for juju-mongodb ? | 14:25 |
| jamespage | perrito666, bzr branch ubuntu:juju-mongodb | 14:26 |
| rogpeppe | katco: this carries on from yesterday's branch if you wanna take a look | 14:26 |
| perrito666 | jamespage: that was easy, tx :) | 14:26 |
| katco | rogpeppe: probably won't have time today... meeting day | 14:26 |
| rogpeppe | katco: np, thanks for yesterday's review anyway | 14:27 |
| katco | rogpeppe: np | 14:27 |
| rogpeppe | natefinch: wanna take a look? 30 lines deleted :) | 14:27 |
| katco | rogpeppe: he had to run an errand... kiddos sick | 14:28 |
| rogpeppe | katco: ok, thanks | 14:28 |
| mgz | perrito666 darling, are you around? | 14:28 |
| perrito666 | mgz: I am sweetie (I feel a bomb coming my way) | 14:29 |
| mgz | $ grep -F 1.24 cmd/juju/status_test.go | 14:30 |
| mgz | - new available version: "1.24.7" "1.24.7 \n"+ | 14:30 |
| mgz | rev 3b8ee08c9dd6c27c1147f2aab157868987489d8c seems incomplete | 14:30 |
| perrito666 | mm, I am pretty sure I replaced that after | 14:30 |
| perrito666 | mgz: -n? | 14:33 |
| perrito666 | shi*** | 14:34 |
| perrito666 | fixing | 14:34 |
| mgz | perrito666: 3026, 3131 | 14:34 |
| mgz | you got *most* of them :P | 14:34 |
| perrito666 | mgz: I suck | 14:36 |
| perrito666 | mm, it is fixed everywhere excepting there | 14:39 |
| perrito666 | mgz: running tests now | 14:40 |
| mgz | perrito666: we'll need to combine your branch with the version bump to get the landing allowed, | 14:44 |
| mgz | perrito666: see https://github.com/juju/juju/pull/3299 | 14:45 |
| perrito666 | mgz: you can pull -r https://github.com/perrito666/juju/tree/hotfix_1.24_hardcoded_version_in_tests into the bump patch | 14:45 |
| mgz | perrito666: thanks, we'll do that | 14:45 |
| perrito666 | mgz: sorry again | 14:47 |
| mgz | perrito666: worth it just to wind you up :) | 14:47 |
| perrito666 | mgz: pleased to please :p | 14:49 |
| katco | alexisb: our meeting conflicts with the juju-core meeting. want to move to after our 9am? | 14:50 |
| dimitern | frobware, hey, I'm back again - should we start the call? | 15:00 |
| frobware | yep | 15:00 |
| dimitern | frobware, standup HO? | 15:00 |
| frobware | dimitern, yes | 15:00 |
| voidspace | fwereade: ping | 15:18 |
| voidspace | dimitern: ping | 15:20 |
| fwereade | voidspace, pong | 15:23 |
| voidspace | fwereade: I'm struggling to write the assert I need I'm afraid and would appreciate some help | 15:25 |
| voidspace | fwereade: I need to assert that the new address (type state.address) is in either the addresses field or machineaddresses field of the current machine doc | 15:25 |
| voidspace | fwereade: but the $in operator doesn't work like that, and as far as I can tell there are no good references on mgo asserts | 15:26 |
| voidspace | nor any similar examples that *I* can find | 15:26 |
| voidspace | fwereade: this is for state/machine.go | 15:27 |
| voidspace | fwereade: current state of code at http://reviews.vapour.ws/r/2593/diff/# | 15:27 |
| voidspace | fwereade: it would go inside the getPreferredAddressOps method | 15:28 |
| fwereade | voidspace, something like {$or: {addresses: {$in: [ADDR]}, machineaddresses: {$in: [ADDR]}}} ? | 15:31 |
| voidspace | just found the mongodb operator docs | 15:31 |
| fwereade | ah cool :) | 15:32 |
| voidspace | fwereade: will try that and see what happens, I had that as a straight $in and it said it needed an array | 15:32 |
| voidspace | and that addr was not a valid value | 15:33 |
| fwereade | voidspace, yeah, it's ugly but I think it works | 15:33 |
| voidspace | in some of the various permutations | 15:33 |
| voidspace | *I tried | 15:33 |
| voidspace | I have a call, will try in a bit | 15:33 |
| rogpeppe | does anyone know if the /environment/$uuid/charms GET endpoint is used at all by anything? | 15:34 |
| rick_h_ | rogpeppe: is that used by the gui to get local charm info? /me isn't sure what endpoint is called but it looks like something we'd want | 15:35 |
| rogpeppe | rick_h_: i think that's an API call - i'm talking about the REST endpoint here | 15:36 |
| rogpeppe | fwereade: ping | 15:42 |
| fwereade | rogpeppe, pog | 15:42 |
| rogpeppe | fwereade: your name seems to be associated with some of this code, so perhaps you can tell me... | 15:42 |
| * fwereade gets nervous | 15:42 | |
| rogpeppe | fwereade: i'm looking at apiserver.charmsHandler | 15:42 |
| rogpeppe | fwereade: it seems that sometimes it sends errors as JSON errors and sometimes just as text (with http.Error) | 15:43 |
| * fwereade *thinks* he wants to point at frankban? | 15:43 | |
| rogpeppe | fwereade: can you think of a reason why that might be a good thing? | 15:43 |
| fwereade | rogpeppe, I certainly can't | 15:43 |
| fwereade | rogpeppe, I do remember drivebying some fix there a while back | 15:43 |
| fwereade | rogpeppe, but I don't think that was related? | 15:43 |
| rogpeppe | fwereade: do you think it would considered API breakage to fix that? | 15:44 |
| rogpeppe | fwereade: (FWIW i can find any client code in juju-core that does a GET from that endpoint) | 15:44 |
| fwereade | rogpeppe, probably :-/ but if you send the right thing *and* the wrong thing (with a comment explaining why) that might sound more sound plausible? | 15:44 |
| rogpeppe | fwereade: (and none of those errors have any test coverage) | 15:45 |
| fwereade | rogpeppe, ffs :( | 15:45 |
| rogpeppe | fwereade: the two things are mutually exclusive | 15:45 |
| rogpeppe | fwereade: you can't send a JSON-encoded error *and* the error as text | 15:45 |
| fwereade | rogpeppe, oh balls ofc sorry | 15:45 |
| fwereade | rogpeppe, end of day ;p | 15:45 |
| rogpeppe | fwereade: np :) | 15:45 |
| rogpeppe | fwereade: for my purposes, I'd very much like it all to standardise on one error format that can return an error code too | 15:46 |
| fwereade | rogpeppe, I think it is api breakage then... can we have a /v2 handler, perhaps? | 15:46 |
| rogpeppe | fwereade: my take on it is that there's currently no way to write a correct client | 15:47 |
| rogpeppe | fwereade: so we're actually fixing things not breaking them | 15:47 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| fwereade | rogpeppe, juju error code, not an http error code? | 15:48 |
| rogpeppe | fwereade: yes | 15:48 |
| fwereade | rogpeppe, I would like that too, but... I don't see why it's impossible to write a client? bloody hindering awkward, yes | 15:48 |
| rogpeppe | fwereade: BTW if you have any time (unlikely, I know) it would be great to have a review of my ongoing apiserver cleanup http://reviews.vapour.ws/r/2689/ | 15:49 |
| fwereade | rogpeppe, but I can't see how to change it without potentially breaking the clients that have gone to the effort | 15:49 |
| rogpeppe | fwereade: so, the only decent way that I can see to write a non-breaking client is to check the content type and unmarshal as JSON if json and text otherwise | 15:50 |
| rogpeppe | fwereade: so if we change the bad endpoints to return JSON, that client would still work | 15:50 |
| rogpeppe | fwereade: also, all but one of the textual errors will be impossible to get unless there's juju internal breakage (corrupt charm cache files) | 15:51 |
| rogpeppe | fwereade: the one error that may be possible to get would be "directory listing not allowed", but tbh the worst that can happen is that some client gets an error that doesn't look like the error they expect in that case. | 15:53 |
| fwereade | rogpeppe, honestly it's too hairy for me, I have convinced myself that breakage is impossible, and been wrong, too many times :( | 15:54 |
| fwereade | rogpeppe, would much rather see a new version | 15:54 |
| rogpeppe | fwereade: the fact that this is only on a very unusual error path and that none of our actual juju code uses the endpoint makes me think that it should be ok | 15:55 |
| rogpeppe | fwereade: do you know of any external programs that use this endpoint at all, let alone relying on juju internal service error formats? | 15:56 |
| fwereade | rogpeppe, no, and that's the problem -- if I knew who used it I'd be able to find out how | 15:57 |
| voidspace | fwereade: so this as a basic syntax (not yet with $or) at least is correct syntax | 16:00 |
| voidspace | fwereade: bson.D{{"addresses", bson.D{{"$in", []address{addr}}}}} | 16:00 |
| voidspace | fwereade: the value we're checking needs to be in an array, that's what was fooling me | 16:00 |
| voidspace | however... | 16:00 |
| voidspace | that fails with: "cannot set addresses of machine 0: state changing too quickly; try again soon" | 16:00 |
| rogpeppe | fwereade: i think it's reasonable to change the internal errors as they are not possible to trigger, and thus impossible to rely on anyway. | 16:00 |
| voidspace | (deterministically it seems) | 16:00 |
| fwereade | voidspace, heh, ok, so that assert triggers? dammit | 16:01 |
| rogpeppe | fwereade: i honestly think there's room for a small amount of pragmatism in the case of the "directory listing not allowed" error | 16:02 |
| fwereade | voidspace, bugger, an address is a struct, isn't it, not sure how that'll play | 16:02 |
| voidspace | fwereade: yup | 16:02 |
| rogpeppe | fwereade: especially given the marginal cost of a version change | 16:02 |
| fwereade | voidspace, does anything stick out about how an address serializes? | 16:02 |
| voidspace | fwereade: it has a Value field which is really the *only* important bit | 16:03 |
| fwereade | rogpeppe, that doesn't feel like it should be too terribly costly? | 16:03 |
| rogpeppe | fwereade: it clutters everything to leave it as is | 16:04 |
| fwereade | voidspace, heh, then I'm afraid I must direct you back to the mongo operator reference, I'm sure there's some way to do that but I completely forget | 16:04 |
| rogpeppe | fwereade: i think the API we really need to worry about is the API that juju itself uses. | 16:05 |
| voidspace | fwereade: it's not documented on the $in page, but I will keep digging | 16:05 |
| voidspace | fwereade: I know what I'm searching for now, which makes life easier | 16:06 |
| fwereade | rogpeppe, I don't think that's the case at all, is it? | 16:06 |
| rogpeppe | fwereade: that's the primary concern, yes | 16:06 |
| fwereade | rogpeppe, doing horrible things to ourself is much more justifiable thann doing horrible things to our external clients | 16:06 |
| fwereade | rogpeppe, at least we understand the scope of the pain when we do it to oourselves | 16:07 |
| rogpeppe | fwereade: making an API endpoint consistent in the error format it hands out is doing a horrible thing to our external clients? | 16:07 |
| fwereade | rogpeppe, *changing behaviour* is being horrible | 16:08 |
| fwereade | rogpeppe, the aspects of X behaviour that people will find to depend upon are a continual source of amazement to me | 16:08 |
| rogpeppe | fwereade: if we change this and there's a client that relies on this particular format of this particular error message, i will buy you beers for an entire sprint | 16:09 |
| fwereade | rogpeppe, we both have a poor track record re predicting "safe" api changes | 16:13 |
| fwereade | rogpeppe, please just make a new version of the endpoint that does the right thing? | 16:13 |
| rogpeppe | fwereade: no, i guess i'll just keep the old behaviour | 16:13 |
| fwereade | rogpeppe, what is problematic about versioning it? | 16:14 |
| rogpeppe | fwereade: it means duplicating all the code | 16:14 |
| rogpeppe | fwereade: it's a cure worse than the ill | 16:14 |
| fwereade | rogpeppe, so we basically *can't* version http endpoints? that feels like an infinitely worse ill... | 16:15 |
| rogpeppe | fwereade: i'm saying that providing a new version of an endpoint for one error message format is not worth it | 16:16 |
| rogpeppe | fwereade: do you agree that changing the internal errors (that will never happen in practice) is OK ? | 16:17 |
| fwereade | rogpeppe, (that seems mainly to point to a failure to separate the behaviour from the transport? one would think that a v2 that shared all the code except the outermost error translation layer would be trivial...) | 16:18 |
| fwereade | rogpeppe, changing error *messages* does not bother me; changing error *codes* would bother me; changing error *formats* also bothers me | 16:19 |
| rogpeppe | fwereade: if you don't mind changing error messages, this is essentially just changing the error message | 16:19 |
| rogpeppe | fwereade: because there is no error code in this case | 16:20 |
| fwereade | rogpeppe, I see it as the format? | 16:20 |
| rogpeppe | fwereade: if a client is reading it as a textual error message, then JSON is just the text | 16:20 |
| rogpeppe | fwereade: if the client knows enough to inspect the content type, then it won't run into the problem | 16:21 |
| rogpeppe | fwereade: my aim is to remain backwardly compatible and not to require clients to fetch /environments/$uuid/charms-v2 or whatever because of a marginal-case error message. | 16:22 |
| voidspace | fwereade: so this is a valid assert, but suffers from the same problem... (so not helpful, but the dot syntax for fields is interesting to note) | 16:24 |
| voidspace | bson.D{{"$or", []bson.D{ | 16:24 |
| voidspace | bson.D{{"addresses.value", bson.D{{"$in", []string{addr.Value}}}}}, | 16:24 |
| voidspace | bson.D{{"machineaddresses.value", bson.D{{"$in", []string{addr.Value}}}}}}}}, | 16:24 |
| fwereade | rogpeppe, I maintain that this is a change in the *format* of the result, and in such cases we should always just add a new api version | 16:25 |
| rogpeppe | fwereade: adding an api version is not free | 16:25 |
| fwereade | voidspace, try a Find with your assert data and see what you get? it ought to match the doc you're looking for | 16:26 |
| voidspace | kk | 16:27 |
| fwereade | rogpeppe, externalising the costs by making secret api changes is not really ok, though | 16:27 |
| rogpeppe | fwereade: i think there is room for pragmatism here | 16:28 |
| fwereade | rogpeppe, and if there is a certainty out there, it is that you will need to change your apis | 16:28 |
| fwereade | rogpeppe, my perception is that the last 3 times you've convinced me of that we've seen breakage ;p | 16:28 |
| rogpeppe | fwereade: for an API that is just getting a file, I'm not sure. | 16:28 |
| rogpeppe | fwereade: particularly when the API is inconsistent already, sometimes returning JSON, sometimes not, with no way for the client to know which might be returned. | 16:30 |
| fwereade | rogpeppe, (so it's not even that I don't trust you -- I don't trust myself, or *anybody else*, to modify apis in place without causing breakage) | 16:30 |
| fwereade | rogpeppe, eight or nine times bitten, $spanish-inquisition times shy | 16:31 |
| rogpeppe | fwereade: oh, one other thing: you think that changing error codes is breakage. my code adds error code returns where previously there were none (Code field always empty). do you consider that breakage too? | 16:31 |
| rogpeppe | fwereade: that is, now the error code will actually reflect the error | 16:32 |
| fwereade | rogpeppe, yes, it's clearly a change in behaviour, new version please | 16:32 |
| fwereade | rogpeppe, if you ask for v2 you can be sure you'll get an error code | 16:32 |
| fwereade | rogpeppe, v1 -- maybe, maybe not. do you feel lucky? ;p | 16:33 |
| rogpeppe | fwereade: ok, another question then: how should we determine API version? | 16:33 |
| rogpeppe | fwereade: at the moment i think my tendency is towards declaring it a request header | 16:33 |
| fwereade | rogpeppe, I have a mild preference for doing it in the url in general, but in all these cases we have to construct auth headers anyway, right? | 16:34 |
| rogpeppe | fwereade: i'm not keen on the approach we've used elsewhere with the version as part of the URL path. | 16:34 |
| rogpeppe | fwereade: yes | 16:34 |
| fwereade | rogpeppe, stable urls and varying headers seem sane then | 16:38 |
| rogpeppe | fwereade: do you think i should just copy the whole apiserver directory? | 16:38 |
| fwereade | rogpeppe, ...no? | 16:38 |
| rogpeppe | fwereade: so version-based if statements scattering the code? | 16:39 |
| fwereade | rogpeppe, should it not just be a few maps of versions to handlers? | 16:40 |
| fwereade | rogpeppe, first check the version, then dispatch to the appropriate handler | 16:41 |
| rogpeppe | fwereade: if i'm copying the handler code, i might as well copy everything apart from the core | 16:41 |
| rogpeppe | fwereade: honestly, i'm thinking it's not worth fixing. | 16:41 |
| fwereade | rogpeppe, so the error format is so inextricably bound up with the rest of the code that the rest of the code can't be shared? | 16:41 |
| rogpeppe | fwereade: at the moment, the error generation is not tied to the request | 16:42 |
| voidspace | fwereade: so after the transaction, that same query finds the machine | 16:46 |
| voidspace | fwereade: the assert does see the result of earlier txn.Op in the same transaction doesn't it... | 16:47 |
| fwereade | voidspace, ah-ha! this is an address that wasn't there before? | 16:47 |
| fwereade | voidspace, certainly not | 16:47 |
| voidspace | fwereade: so extend the $or | 16:47 |
| voidspace | fwereade: no, can't that's kind of the point | 16:47 |
| voidspace | fwereade: needs to be done as a separate transaction then | 16:47 |
| voidspace | set the new field, then set the addresses checking they still exist | 16:48 |
| fwereade | voidspace, sorry, my brain was still tangled with the write-on-get code | 16:48 |
| voidspace | np | 16:49 |
| fwereade | voidspace, in this case I think you probably just want to check that addresses and machineaddresses are exactly what they were originally? | 16:49 |
| fwereade | voidspace, so sorry I didn't make connection before | 16:49 |
| voidspace | fwereade: ok | 16:49 |
| voidspace | fwereade: it's better not to do it as a separate transaction as the first one could succeed then the second fail, and then what would we do | 16:50 |
| voidspace | fwereade: and if they've changed, what do we do? we don't want to repeat the transaction | 16:50 |
| fwereade | voidspace, yeah, exactly, avoid multiple txns like the plague :) | 16:50 |
| voidspace | fwereade: we have an interesting race because of fallback scopes | 16:51 |
| voidspace | fwereade: if SetProviderAddresses and SetMachineAddreses are set concurrently, which is highly likely | 16:51 |
| voidspace | fwereade: the first time neither PreferredAddress will be (Public nor Private) | 16:52 |
| voidspace | so the first one will set both (one correctly as it has the right scope and one as a fallback because the other isn't available yet) | 16:52 |
| voidspace | and the second one will also attempt to set both | 16:53 |
| voidspace | whereas we probably want ProviderAddresses to set one and MachineAddresses to set the other | 16:53 |
| rogpeppe | fwereade: BTW are we allowed to change behaviour at all (e.g. add a field) without making a new version? | 16:54 |
| voidspace | ok, so I need to rebuild the slice of addresses which I'm not currently doing in buildTxn | 16:54 |
| voidspace | that will work | 16:54 |
| voidspace | fwereade: sorry, using you as a rubber ducky | 16:55 |
| voidspace | fwereade: I think I have it | 16:55 |
| voidspace | fwereade: will need to craft a test to prove it... | 16:55 |
| voidspace | but it will have to wait I'm afraid, EOD and PyCon UK tomorrow | 16:55 |
| voidspace | I've told alexisb that this bug will be ready for beta 2 | 16:55 |
| fwereade | rogpeppe, AFAICS, you can only reasonably do that when you don't actually need to add the field at all -- otherwise you're screwing over your clients, who can't tell whether a given server will pay any attention to that field or not | 16:58 |
| rogpeppe | fwereade: i'm talking about adding fields to a response | 16:58 |
| fwereade | rogpeppe, it's less harmful, for sure, but isn't it better for the client that might use the extra fields to ask for a response it *knows* will have those fields? | 17:00 |
| rogpeppe | fwereade: not necessarily | 17:00 |
| rogpeppe | fwereade: if the field is present, it can act on it | 17:00 |
| fwereade | rogpeppe, right, but what *actually happens* is that they use a new server to begin with, and come to depend on the field, and then their code breaks seemingly at random | 17:02 |
| rogpeppe | fwereade: ha, one problem with doing the version-in-header approach is that a new client with an old server will still get the old response. but that's potentially an issue with doing it in the path too - a "not found" response might be a legitimate response to the new path, for example. | 17:03 |
| fwereade | rogpeppe, ha, good point | 17:03 |
| fwereade | rogpeppe, (see? I'm shit at predicting these subtle breaks) | 17:03 |
| rogpeppe | fwereade: i'm thinking of adding an error code field to some responses (where there is none currently) | 17:03 |
| fwereade | rogpeppe, yeah, that sounds like a great thing but a new api version to me | 17:05 |
| fwereade | rogpeppe, and I kinda have to stop now :( | 17:05 |
| rogpeppe | fwereade: one way to get around that issue is to include the API version with the response. | 17:12 |
| wwitzel3 | looking at juju/charms I see Metadata has a Hooks() method that returns a map of all the hooks a charm might want to implement, I don't see where we call that in juju core | 18:55 |
| wwitzel3 | so where in core do we determine what hooks should be run? | 18:55 |
| wwitzel3 | or could be run I should say | 18:55 |
| natefinch | wwitzel3: not sure... haven't looked at that part of the code | 19:00 |
| bogdanteleaga | wwitzel3: https://github.com/juju/juju/blob/master/worker/uniter/hook/hook.go#L24, it's taken from juju/charms | 19:01 |
| bogdanteleaga | though you can kinda tell from validate | 19:01 |
| mup | Bug #1496972 opened: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <juju-core:Confirmed> <https://launchpad.net/bugs/1496972> | 19:06 |
| wwitzel3 | bogdanteleaga: ok, but where do we actually determine which hooks for a given charm should be run? | 19:06 |
| wwitzel3 | bogdanteleaga: I mean, where is the information that Validate is check, set | 19:07 |
| wwitzel3 | s/check/checking | 19:07 |
| mup | Bug #1496972 changed: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <juju-core:Confirmed> <https://launchpad.net/bugs/1496972> | 19:09 |
| wwitzel3 | bogdanteleaga: since a hook is really any name and interface and those could be free form, I'm trying to understand the process of how we know that the %s-relation-changed hook should be run for example | 19:09 |
| mup | Bug #1496972 opened: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <juju-core:Confirmed> <https://launchpad.net/bugs/1496972> | 19:12 |
| bogdanteleaga | wwitzel3: you mean how we choose which one is next? | 19:17 |
| bogdanteleaga | wwitzel3: https://github.com/juju/juju/blob/master/worker/uniter/resolver/loop.go#L70, here we choose the next operation that should run and then we run it until some error | 19:19 |
| bogdanteleaga | (this just changed in master btw, so it's different in other versions) | 19:21 |
| wwitzel3 | bogdanteleaga: not quite, so if I add a new provides interface to my charm and upgrade, how does juju know now there is a new hook to be run? | 19:39 |
| wwitzel3 | bogdanteleaga: I looking for the code that actually generates the list of hooks | 19:39 |
| mup | Bug #1496975 opened: upgrade-charm --switch does not warn about risks <juju-core:New> <https://launchpad.net/bugs/1496975> | 19:42 |
| wwitzel3 | katco: ping | 19:43 |
| katco | wwitzel3: hey, in meeting | 19:43 |
| wwitzel3 | rgr | 19:44 |
| wwitzel3 | NewLiveHookSource | 19:57 |
| bogdanteleaga | wwitzel3: I don't think there's a hook list and they're just taken from there, NextOp does the magic, it chooses a hook such that the localstate converges towards the remotestate | 20:02 |
| bogdanteleaga | for example the install hook: https://github.com/juju/juju/blob/master/worker/uniter/resolver.go#L220 | 20:02 |
| bogdanteleaga | and config changed close below | 20:02 |
| wwitzel3 | right, but there is something that determines the remotestate which is essentially the list of hooks to be run | 20:03 |
| bogdanteleaga | wwitzel3, found anything? I can't see anything obvious in the resolvers and those are supposed to set whatever is going to run | 20:37 |
| mup | Bug #1496997 opened: TestErrorReadingEnvironmentsFile calls chmod on win <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1496997> | 20:42 |
| === urulama is now known as urulama__ | ||
| sinzui | wallyworld: reports.vapour.ws doesn't now about this job yet. http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-mongodb3/5/console | 21:46 |
| perrito666 | thumper: are you around? | 21:47 |
| thumper | perrito666: yes, but on calls | 21:48 |
| thumper | whazzup? | 21:48 |
| perrito666 | thumper: I need someone a bit more local provider savvy than I | 21:50 |
| thumper | for what? | 21:50 |
| wallyworld | sinzui: i guess it will soon? | 21:50 |
| mup | Bug #1328129 changed: panic when apiaddresses not present <cts-cloud-review> <panic> <sts> <juju-core:Triaged> <https://launchpad.net/bugs/1328129> | 21:51 |
| perrito666 | thumper: I am trying to introduce some changes to mongo connection and I have the sensation that ensureMongoAdmin is never being called but I am not getting logs either so I thought of asking while trying a few things | 21:52 |
| thumper | sure it isn't in jujud/ bootstrap? | 21:52 |
| thumper | grep ? | 21:52 |
| perrito666 | thumper: It should be, I just have the simptomps as if it wasnt ;) then again no logs make my life a bit harder :( | 21:54 |
| sinzui | wallyworld: thumper: katco: deej in the #juju channel has an upgraded env that lost the apiaddress maybe bug 1366887. Who can help find and fix the mongo document | 21:55 |
| sinzui | waigani: menn0 : do either of you have experience fixing a mongodb that lost its apiaddress during an upgrade? deej in #juju needs help fixing a broken env where all the units lost and continue to loose the apiaddress | 22:07 |
| menn0 | sinzui: i'll take a look | 22:09 |
| menn0 | sinzui: give me 2 mins | 22:09 |
| perrito666 | wallyworld: your lateness stands? | 22:20 |
| wallyworld | perrito666: got back in time | 22:20 |
| perrito666 | wallyworld: cool, call me and tell me the lottery numbers then marty | 22:21 |
| perrito666 | :p | 22:21 |
| wallyworld | i'll ask Biff | 22:21 |
| perrito666 | mm, all internet seems to be in poor shape today, I wonder if the eartquake broke something | 22:27 |
| * thumper heads to the gym to roll around | 23:44 | |
| perrito666 | good boy | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!