| === kadams54 is now known as kadams54-away | ||
| davecheney | thumper: menn0 waigani i've been working on some visualisation tools to help me | 00:10 |
|---|---|---|
| davecheney | https://twitter.com/davecheney/status/534135954420678656 | 00:10 |
| davecheney | here is an example | 00:10 |
| davecheney | dealing with something the size of juju/state is still daunting | 00:10 |
| waigani | nice! | 00:10 |
| davecheney | that is cmd/juju | 00:10 |
| davecheney | sorery | 00:10 |
| davecheney | cmd/go | 00:10 |
| * menn0 is still waiting for twitter to load the image | 00:11 | |
| waigani | davecheney: is that d3? | 00:12 |
| menn0 | wow that's awesome | 00:12 |
| menn0 | what are you using to do the rendering? | 00:12 |
| === kadams54-away is now known as kadams54 | ||
| davecheney | waigani: d3js.org | 00:13 |
| waigani | thought so | 00:13 |
| davecheney | http://imgur.com/t57nMob | 00:26 |
| davecheney | ^ juju/state | 00:26 |
| waigani | menn0: can I talk over the allwatcher store with you? I can see two ways to go | 00:26 |
| davecheney | http://imgur.com/3oErTdQ | 00:26 |
| davecheney | juju state, from the perspective of mgo/v2 | 00:26 |
| waigani | davecheney: omg... | 00:26 |
| menn0 | waigani: i was about to go for lunch... | 00:28 |
| menn0 | waigani: did you want to hangout/ | 00:28 |
| waigani | menn0: should be a quick question | 00:28 |
| waigani | menn0: standup hangout? | 00:28 |
| menn0 | waigani: ok | 00:28 |
| === kadams54 is now known as kadams54-away | ||
| davecheney | http://i.imgur.com/ioxieyg.png | 00:30 |
| davecheney | something to consider with the juju/version pacakge | 00:30 |
| davecheney | http://imgur.com/d9xNtae | 00:33 |
| davecheney | who's using loggo, and who isnt ... | 00:33 |
| thumper | davecheney: so the picture is showing what? | 00:35 |
| thumper | what are the lines? | 00:35 |
| thumper | and how do you know? | 00:35 |
| thumper | is there meaning to the relative thickness? | 00:35 |
| davecheney | thumper: it's a bit hard to tell | 00:36 |
| thumper | davecheney: it is almost like you need two graphs rather than one | 00:36 |
| davecheney | i stole most of the code from an example comparing people who like different hair color | 00:36 |
| davecheney | i'll keep working on it tonight | 00:36 |
| thumper | kinda cool picture though | 00:37 |
| davecheney | at leats it tells me who is relaed to what | 00:37 |
| * thumper nods | 00:37 | |
| davecheney | like juju/version imports bson ... | 00:37 |
| davecheney | http://imgur.com/UKYv5j3 | 00:38 |
| davecheney | this is all the things that importing juju/version brings in | 00:38 |
| davecheney | which seems excessive | 00:39 |
| davecheney | like why does juju/version depend on sync ... | 00:39 |
| davecheney | http://imgur.com/nmfRE4r | 00:40 |
| anastasiamac | davecheney: these look pretty! | 00:45 |
| anastasiamac | davecheney: are they available on the fly? | 00:45 |
| anastasiamac | davecheney: kinf of like "graph usage of blah"? | 00:45 |
| anastasiamac | s/kinf/kind | 00:46 |
| davecheney | anastasiamac: go get github.com/davecheney/junk/glyph | 00:48 |
| davecheney | $GOPATH/bin/glyph | 00:48 |
| davecheney | then go to localhost:8080/chord/cmd/go | 00:48 |
| davecheney | it works just like godoc, the first url is the visualisation, the rest is a package path to start from | 00:48 |
| davecheney | be warned | 00:48 |
| davecheney | it is very very slow | 00:48 |
| davecheney | took two minutes to generate the first image | 00:48 |
| anastasiamac | davecheney: it's monday... i feel slow too :-) | 00:49 |
| davecheney | i'm doing to much processing in the browser | 00:49 |
| davecheney | i need to offload that to the backend | 00:49 |
| anastasiamac | davecheney: thnx :-) visually seeing dependencies is enormously helpful! | 00:51 |
| davecheney | that's why i built this | 00:51 |
| davecheney | i need it to help me | 00:51 |
| thumper | davecheney: juju/version brings in io (to read the file), io brings in sync | 00:52 |
| thumper | davecheney: easy to pull in heaps | 00:52 |
| davecheney | versino is also bringing in sync directly | 00:52 |
| davecheney | which is odd | 00:52 |
| davecheney | hmm | 00:53 |
| davecheney | no it isnt | 00:53 |
| davecheney | ok | 00:53 |
| davecheney | i screwed up | 00:53 |
| davecheney | doesn't surprise me | 00:53 |
| thumper | davecheney: just checking that we both aren't sitting in a different hangout with the same name | 01:03 |
| thumper | google gets things wrong occasionally | 01:03 |
| davecheney | thumper: nope, my bad | 01:04 |
| davecheney | i ingored the reminder | 01:04 |
| davecheney | be there in a sec | 01:04 |
| === kadams54-away is now known as kadams54 | ||
| davecheney | thumper: http://godoc.org/github.com/juju/juju/state?import-graph | 01:21 |
| davecheney | thumper: http://imgur.com/TT3xgeD | 01:23 |
| davecheney | thumper: http://imgur.com/2iKJC2O | 01:25 |
| thumper | davecheney: https://github.com/juju/errors/pull/13 | 01:58 |
| * thumper takes broken kid to physio | 01:58 | |
| menn0 | waigani: http://reviews.vapour.ws/r/471/ reviewed | 02:41 |
| axw | wallyworld_: when you have a minute, can you PTAL at http://reviews.vapour.ws/r/442/ | 03:30 |
| wallyworld_ | sure | 03:30 |
| axw | wallyworld_: I've parameterised the function to list block devices in worker/diskmanager.NewWorker | 03:31 |
| axw | with a default | 03:31 |
| axw | jujud tests now override that default | 03:31 |
| wallyworld_ | axw: looks good, now tests will pass in a container | 03:38 |
| axw | yep | 03:40 |
| axw | thanks | 03:40 |
| waigani | menn0: thanks for the review. testing the constraints upgrade, I've expected three records because there is a preexisting environment constraints doc | 03:49 |
| waigani | menn0: i.e. it has a local i.d. of "e" - the global env key | 03:49 |
| thumper | wallyworld_: hey, can I get you to look at this for me? https://github.com/juju/loggo/pull/7/files | 03:51 |
| wallyworld_ | sure | 03:51 |
| wallyworld_ | thumper: the location stuff is just for tests to avoid hard coding line numbers? | 04:00 |
| thumper | wallyworld_: exactly | 04:00 |
| thumper | stolen from the errors tests, which I got from rog | 04:00 |
| wallyworld_ | can you add a doc comment then so the next person doesn't need to fiure it out? | 04:00 |
| thumper | sure | 04:00 |
| wallyworld_ | also, i think then the test commnt is wrong | 04:00 |
| wallyworld_ | as it still mentions line number fragility | 04:00 |
| thumper | ah... will fix | 04:01 |
| thumper | wallyworld_: changes pushed | 04:04 |
| wallyworld_ | +1 | 04:04 |
| thumper | cheers | 04:05 |
| menn0 | waigani: of course... I didn't think of that | 04:10 |
| waigani | menn0: cool, so good to ship? | 04:13 |
| menn0 | I think so | 04:13 |
| menn0 | just wondering if the test should check that the "e" key is still in good shape post migration | 04:14 |
| menn0 | waigani: ^ | 04:14 |
| waigani | menn0: shesh, just caught me - mouse was over the 'commit' button | 04:14 |
| thumper | wallyworld_: and a useful one: https://github.com/juju/loggo/pull/6/files | 04:15 |
| menn0 | waigani: it's probably ok | 04:16 |
| waigani | menn0: I do check that in TestAddEnvUUIDToConstraintsIdempotent | 04:16 |
| waigani | menn0: so it is covered. good enough? | 04:16 |
| menn0 | waigani: so you do. that's great then. can you just add a comment with the assertion that check for a length of 3 to avoid confusion | 04:17 |
| menn0 | waigani: then merge away | 04:17 |
| waigani | menn0: will do | 04:17 |
| menn0 | thumper: so State.NewEnvironment doesn't give you an environment you can do anything with | 04:18 |
| thumper | no | 04:18 |
| thumper | menn0: it just adds an environment into the collection | 04:18 |
| thumper | menn0: happy if you want to change that | 04:18 |
| thumper | menn0: it probably isn't used in many places | 04:18 |
| wallyworld_ | thumper: so how to developers decide to use the Stack vs non Stack variants of the various log methods | 04:18 |
| wallyworld_ | shouldn't they just use Warningf() and a log setting decides | 04:19 |
| thumper | wallyworld_: if you are logging a message, you go `logger.Infof("some garbage")` | 04:19 |
| menn0 | thumper: it isn't used anywhere, except tests | 04:19 |
| thumper | wallyworld_: the InfoStackf takes an error as the first param | 04:19 |
| thumper | wallyworld_: magical introspection of the args... params would be a bit too magic | 04:20 |
| menn0 | thumper: so basically we need Initialize (in open.go) to happen afterwards right? | 04:20 |
| thumper | wallyworld_: if you want the error stack logged, call the stack message | 04:20 |
| thumper | menn0: if you want to use it, yes | 04:20 |
| wallyworld_ | ok | 04:20 |
| wallyworld_ | i'm not sure then we need all the variants | 04:20 |
| thumper | wallyworld_: there are many many occurrances of logging where we go `logger.Warningf("something horrible: %v", err)` | 04:21 |
| wallyworld_ | would we really want to see a stack trace for an Info message | 04:21 |
| thumper | I'm thinking that it would be `logger.WarningStackf(err, "something horrible")` | 04:21 |
| thumper | wallyworld_: I don't want to make that call | 04:21 |
| thumper | wallyworld_: someone may want a stack at a different level | 04:21 |
| wallyworld_ | if they need stack trace with an info there's something wrong | 04:22 |
| wallyworld_ | but ok | 04:22 |
| wallyworld_ | i think this will be absed | 04:22 |
| thumper | abused? | 04:23 |
| wallyworld_ | yeah | 04:23 |
| thumper | I'm not sure.. I guess time will tell | 04:23 |
| menn0 | thumper: Initialize doesn't quite work as it dials it's own mongo connection and create its own uuid etc | 04:23 |
| wallyworld_ | our log output will become oven more of a firehose | 04:23 |
| thumper | I have a better one coming | 04:23 |
| menn0 | thumper: I will do some refactoring | 04:23 |
| thumper | menn0: ack | 04:23 |
| wallyworld_ | thumper: what do we do when our log files are full of stack traces and even harder to read than they are now | 04:24 |
| thumper | wallyworld_: I think this becomes one of those pragmatic things, don't record a stack for an expected error | 04:25 |
| wallyworld_ | i think we need x-team collaboration or a policy that reviewers are aware of so that this will not be misused | 04:26 |
| wallyworld_ | clear guidelines on what an "expected" error is | 04:27 |
| wallyworld_ | what's the driver for this? | 04:27 |
| wallyworld_ | is there an issue that is being solved? | 04:27 |
| thumper | one of the issues was our logging, and that I was looking for occurrances of ": %v" in the codebase | 04:30 |
| thumper | I saw that many were to log errors | 04:30 |
| thumper | we now catch error stack info which is important for debugging | 04:30 |
| thumper | that was the rationale | 04:30 |
| thumper | wallyworld_: along with this one: https://github.com/juju/testing/pull/38/files | 04:31 |
| wallyworld_ | i content you don't need the error stack 99% of the time | 04:31 |
| wallyworld_ | and if you do, it is for debugging, and not warning or error or info output | 04:32 |
| wallyworld_ | i have very rarely if ever wished to have the stack trace when debugging a juju issue | 04:32 |
| thumper | hmm... | 04:32 |
| wallyworld_ | sorry for being -1 on this, i just see a whole lot of extra logging for little benefit | 04:33 |
| wallyworld_ | but that's just IMHO | 04:33 |
| thumper | I'm happy to hold off landing that one until we talk as a team through it more | 04:34 |
| thumper | I can take it to the list | 04:34 |
| wallyworld_ | i'd personally be happier if this were a trace level thing that could be turned on when needed | 04:34 |
| thumper | but probably tomorrow | 04:34 |
| thumper | wallyworld_: or just a separate method: | 04:34 |
| thumper | logger.StackTrace(err) | 04:34 |
| thumper | although... | 04:34 |
| wallyworld_ | so long as it can be turned on/off | 04:34 |
| thumper | I had thought of having other helper methods: | 04:34 |
| thumper | one to get a limited stack trace of where you are | 04:35 |
| thumper | the other to get the stack trace of the error you have | 04:35 |
| wallyworld_ | this could be useful when developing (not foe me, but others might like it) | 04:35 |
| wallyworld_ | but it should not get into our std log output by default | 04:36 |
| wallyworld_ | happy to concede if the majority want it | 04:36 |
| thumper | I'll take this one to the list | 04:36 |
| wallyworld_ | ta | 04:36 |
| thumper | the other is `jc.IsNil` | 04:36 |
| wallyworld_ | ok | 04:36 |
| thumper | which does " if not nil, and it is an error, and it has a StackTrace method, show the stack trace in the test fail message" | 04:37 |
| wallyworld_ | now, that is useful | 04:37 |
| thumper | which I have wanted for a while | 04:37 |
| * thumper goes to make dinner for the little beings that live at his house | 04:38 | |
| wwitzel3 | axw: can you take a look at https://github.com/juju/juju/pull/1157 | 04:50 |
| axw | looking | 04:50 |
| axw | wwitzel3: I can't spot the problem that was fixed - can you please describe? | 04:54 |
| wwitzel3 | axw: well this was actually done before you merge landed adding in the break. | 04:54 |
| waigani | wtf? | 04:56 |
| axw | wwitzel3: so is this really necessary then? there are tests for zone selection already, TestStartInstanceDistribution.* | 04:56 |
| waigani | I just merged trunk and pushed my diff up to RB. What should be a four line diff has turned into a 400 line diff. | 04:57 |
| axw | also, the "continue" in the refactored function should still do an index check, otherwise the message is wrong on the last iteration | 04:57 |
| waigani | http://reviews.vapour.ws/r/473/diff/ | 04:57 |
| wwitzel3 | axw: well I think the refactor is better, since it extracts the concern out of a big monolithic method and helps to isolate the testing :) | 04:57 |
| waigani | other than the megawatcher changes, none of those changes are mine. | 04:58 |
| axw | wwitzel3: yes, that is a fair point | 04:58 |
| waigani | from this branch at least | 04:58 |
| wwitzel3 | axw: yeah, I think that got clipped out in a merge, I just noticed that | 04:58 |
| wwitzel3 | axw: I wanted you to give me a review on it since you did the code, but I'd stil like to land it | 04:59 |
| axw | wwitzel3: sure. LGTM with the continue condition readded | 04:59 |
| davecheney | http://imgur.com/94R6MwG | 05:01 |
| davecheney | the agent package is a bit of a beast | 05:01 |
| wwitzel3 | axw: on the condition, is can I use <= instead of i+1 < ? | 05:01 |
| axw | wwitzel3: that's fine with me | 05:01 |
| wwitzel3 | axw: k, yeah, that is what I changed, but I think I foobar'd a merge and ended up squashing the entire if block :/ | 05:02 |
| axw | davecheney: looks like a DHT; it's got some extra deps in case someone removes one ;) | 05:02 |
| wwitzel3 | axw: thanks, addressed both of those | 05:04 |
| axw | wwitzel3: thanks for making it better :) | 05:05 |
| axw | wwitzel3: did you figure out that latest MAAS provider bug btw? last I looked you couldn't repro | 05:05 |
| waigani | menn0: something between git, github and RB crapped itself along the way, so new PR: http://reviews.vapour.ws/r/474/ | 05:10 |
| wwitzel3 | axw: yeah, the bug was their code didn't have the back port of the "break" yet. | 05:21 |
| wwitzel3 | axw: so instead of stopping after finding the right zone, it just kept running until the last zone. | 05:21 |
| wwitzel3 | axw: and it just happened their last zone was full | 05:21 |
| wwitzel3 | axw: I couldn't repo at first because my last zone had a free slot. | 05:22 |
| axw | wwitzel3: ahh I see, thanks | 05:23 |
| wwitzel3 | axw: now I just have to figure out why my test fails on the bot , but works locally :( .. sad day, guess I will save that for tomorrow | 05:28 |
| axw | wwitzel3: nothing jumps out | 05:31 |
| === kadams54 is now known as kadams54-away | ||
| anastasiamac | axw: could u plz clarify juju convention when creating pair of corresponding commands? | 06:09 |
| anastasiamac | axw: do they sit in one file like in environment.go - set/unset | 06:09 |
| anastasiamac | axw: do they sit in different files like addmachine.go and removemachine.go? | 06:10 |
| axw | anastasiamac: I think most people prefer one command per file | 06:10 |
| anastasiamac | axw: sorry ;-( | 06:10 |
| anastasiamac | set/get for environment | 06:10 |
| anastasiamac | axw: k.. one file is gr8 ;-) | 06:11 |
| anastasiamac | axw: thnx | 06:11 |
| axw | anastasiamac: nps | 06:11 |
| anastasiamac | axw: so where would u put shared functionality? | 06:11 |
| anastasiamac | axw: i'd like to avoid duplicate code | 06:12 |
| axw | anastasiamac: I'd just stick all common functionality in one or the other, doesn't matter which... just as long as it's together | 06:12 |
| anastasiamac | axw: k. sure :-) thnx | 06:13 |
| wallyworld_ | jam: you ok for the juju status meeting later? | 07:10 |
| jam | wallyworld_: I should be able to be around | 07:28 |
| wallyworld_ | great, we need to get the spec approved, and there's a fair bit of disagreement | 07:29 |
| axw | dimitern: why does goamz use a different API version for RunInstances when specifying VPC attributes? were you being paranoid, or is there actually different behaviour? | 07:31 |
| dimitern | axw, because the VPC API is a newer version than the classic api it otherwise uses | 07:32 |
| dimitern | axw, and yes, I was being a bit paranoid :) | 07:32 |
| axw | dimitern: I realise.. I meant, why not use the newer version on all | 07:32 |
| axw | ok | 07:32 |
| axw | dimitern: I'm just asking because I'm going to have to bump the version we use to support allocating additional EBS volumes | 07:33 |
| dimitern | axw, sure, if you need to, but please sync up with niemeyer | 07:34 |
| axw | dimitern: will do | 07:34 |
| jam | wallyworld_: any news about the remaining critical bugs ? Do you need some extra manpower to work on them ? | 07:48 |
| jam | like https://bugs.launchpad.net/juju-core/+bug/1392544 isn't assigned yet | 07:49 |
| mup | Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544> | 07:49 |
| wallyworld_ | jam: i poked tim about bug 1392745 as i suspect he'll be across it, but he deferred till tomorrow | 07:49 |
| mup | Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745> | 07:49 |
| wallyworld_ | the local provider one i'm going to start looking at | 07:50 |
| wallyworld_ | the default value one is not assigned yet, if you had someone who could look that would be good | 07:50 |
| wallyworld_ | otherwise i'll do tomorrow | 07:50 |
| jam | wallyworld_: k, if you want someone on my team, I'm perfectly happy having us polishing a release branch | 07:50 |
| wallyworld_ | ok, thanks, maybe the default value one then | 07:51 |
| mattyw | morning all | 07:52 |
| jam | wallyworld_: k, I'm not sure if they'll get up to speed before someone like Tim could fix it, but I can get them started. | 07:53 |
| wallyworld_ | jam: tim will do the 1.20.11 juju run one | 07:54 |
| wallyworld_ | i haven't look in default at the default value one | 07:55 |
| wallyworld_ | in detail | 07:55 |
| jam | ah, ok | 07:55 |
| wallyworld_ | bug 1392544 should just be some generic snafu maybe | 07:56 |
| mup | Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544> | 07:56 |
| jam | wallyworld_: yeah. It looks like something is casting everything to a generic boolean type | 07:56 |
| jam | wallyworld_: I've tasked dimitern with it | 07:57 |
| wallyworld_ | the other one - the local provider log issue - is likely tim's aread also, but i'll did into it | 07:57 |
| wallyworld_ | ty | 07:57 |
| wallyworld_ | and the maas one is well in hand | 07:57 |
| * fwereade_ was up late last night, is going for a bit of a walk before he starts properly | 08:03 | |
| axw | fwereade_: when you have started, if you have some time would you please take a glance over https://github.com/juju/charm/pull/77? doesn't need to be a full review, but I'd like to know if you have had differing thoughts on how the storage metadata should look | 08:22 |
| === alexlist` is now known as alexlist | ||
| === psivaa-holiday is now known as psivaa | ||
| dimitern | fwereade_, ping | 10:00 |
| fwereade_ | dimitern, pong | 10:00 |
| dimitern | fwereade_, re https://bugs.launchpad.net/juju-core/+bug/1392544 - what's the purpose of the "default: true|false" field in juju get svcname output? | 10:01 |
| mup | Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:Triaged by dimitern> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392544> | 10:01 |
| fwereade_ | dimitern, it tells you whether it's that value because [nothing was set, and it will therefore change if there's a charm upgrade that changes the default] or [that's the actual value that was explicitly set, even if it happens to match the default, and will persist so long as there's a matching config entry] | 10:02 |
| jam | TheMue: voidspace: standup ? | 10:02 |
| dimitern | fwereade_, so if "default: true" it means yeah the respective config setting is not set (i.e. uses the default value) ? | 10:03 |
| fwereade_ | dimitern, yeah | 10:03 |
| fwereade_ | dimitern, looking at that bug I suspect it's a documentation issue more than anything | 10:04 |
| dimitern | fwereade_, it seems to me as well, but I'll do a quick test to make sure we don't set default: true for non-default values | 10:04 |
| fwereade_ | dimitern, thanks | 10:04 |
| fwereade_ | dimitern, don't close the bug without fixing the docs, though, please :) | 10:04 |
| voidspace | jam: oops | 10:04 |
| voidspace | jam: omw | 10:04 |
| dimitern | fwereade_, sure | 10:04 |
| fwereade_ | dimitern, <3 | 10:05 |
| jam | fwereade_: so for compat reasons, can we ever change that to "is-default" rather than "default" confusing people ? | 10:06 |
| fwereade_ | jam, yes and no. no for `juju get`; yes for `juju service get`, which I'll need to sync up with thumper on | 10:08 |
| fwereade_ | jam, however, for `juju service get` we really want the default output to be something we can pass back into `juju service set` | 10:09 |
| fwereade_ | jam, so a sane implementation would probably just skip the ones with default values | 10:09 |
| fwereade_ | jam, and a --schema flag or something could tell you what the defaults were | 10:09 |
| jam | fwereade_: we *could* have that as "--as-set" or some other flag that indicates the output you want. I think you *do* sometimes want to see what the value is, even if you haven't set it | 10:10 |
| fwereade_ | jam, that is not perfect for sure | 10:10 |
| jam | I've used it often to figure out what I *could* set | 10:10 |
| fwereade_ | jam, I agree we do | 10:10 |
| jam | fwereade_: you'd prefer the minimal form as the default output ? | 10:10 |
| fwereade_ | jam, but the asymetry between get and set is really kinda nasty | 10:10 |
| fwereade_ | jam, I *think* so, yeah -- in my mind the main tension is in what happens if you get, upgrade, set | 10:11 |
| fwereade_ | jam, and whether that final set shoudl change values or not | 10:11 |
| fwereade_ | jam, (assuming it's not rendered irrelevant by the original get having values that are invalid/unknown post-upgrade | 10:11 |
| fwereade_ | ) | 10:11 |
| fwereade_ | jam, not saying it should be *hard* to see the possibilities, but I don't think it's the *most* important thing | 10:12 |
| jam | fwereade_: well, I do think it is the primary use case of get, isn't it ? (what are all the current settintgs) | 10:13 |
| jam | fwereade_: or do you feel it is more the way you transfer settings to some other place | 10:13 |
| fwereade_ | jam, `get --all` feels appropriate for "and include the defaults please" -- it's more consistent with charm-side config-get apart from anything else | 10:14 |
| fwereade_ | jam, and `get --schema` feels appropriate for "tell me what the possible keys and their meanings are" | 10:15 |
| fwereade_ | jam, and I'm not automatically opposed to some nice human-readable combination of the two | 10:15 |
| fwereade_ | jam, but it feels like a lot of disparate info to cleanly fit into the default output | 10:15 |
| fwereade_ | jam, that's what we signally failed to do with the current implementation ;) | 10:16 |
| perrito666 | morning | 10:26 |
| dimitern | fwereade_, so it does work - setting a service config setting to a non-default value causes juju get svcname to *not* include "default: true" for that setting | 10:29 |
| fwereade_ | dimitern, that's good anyway | 10:30 |
| fwereade_ | dimitern, not really much less confusing | 10:30 |
| fwereade_ | dimitern, but at least working as intended | 10:30 |
| dimitern | fwereade_, so what do you suggest to add to juju help get to clarify the behavior? | 10:31 |
| * fwereade_ looks at documentation for `juju get` | 10:31 | |
| fwereade_ | dimitern, um, some documentation ;p | 10:32 |
| dimitern | fwereade_, because this is what I think the "fix" for that bug | 10:32 |
| fwereade_ | dimitern, concur | 10:32 |
| dimitern | fwereade_, barely :) | 10:32 |
| fwereade_ | dimitern, seriously, all it has is a "purpose" | 10:32 |
| fwereade_ | dimitern, give it a Doc as well | 10:32 |
| dimitern | fwereade_, yeah, a lot of commands (simpler ones) are like that | 10:32 |
| fwereade_ | dimitern, indeed | 10:32 |
| fwereade_ | dimitern, this is not actually a good thing ;) | 10:33 |
| dimitern | fwereade_, ok, I'll describe the output in the Doc of get | 10:33 |
| fwereade_ | dimitern, cool, thanks | 10:35 |
| dimitern | fwereade_, trivial review (mostly proof-reading I guess) ? https://reviews.vapour.ws/r/477/diff/ | 11:33 |
| fwereade_ | dimitern, ship it | 11:35 |
| dimitern | fwereade_, cheers! | 11:35 |
| fwereade_ | dimitern, hey, btw, apparently malta played football against bulgaria and didn't lose, I feel quite unwarrantedly smug on behalf of my place of residence | 11:35 |
| dimitern | fwereade_, :) yeah, I've heard of that | 11:36 |
| dimitern | fwereade_, and also BG won 2nd place in the kids eurovision in malta | 11:36 |
| fwereade_ | dimitern, cool, I didn't know that until today either :) | 11:36 |
| dimitern | fwereade_, btw can you actually click on Ship it! ? :) | 11:37 |
| dimitern | fwereade_, ah, sorry - I've just seen it, it must've been lagging behind | 11:37 |
| dimitern | niedbalski, ping | 11:42 |
| dimitern | voidspace, jam, can any of you please approve https://reviews.vapour.ws/r/478/ ? it's the same fix for bug 1392544, this time for master | 11:47 |
| mup | Bug #1392544: juju get shows default value true <charms> <config> <regression> <juju-core:In Progress by dimitern> <juju-core 1.21:In Progress by dimitern> <https://launchpad.net/bugs/1392544> | 11:47 |
| voidspace | dimitern: looking | 11:49 |
| dimitern | voidspace, ta | 11:49 |
| voidspace | dimitern: lgtm | 11:51 |
| dimitern | voidspace, thanks | 11:51 |
| dimitern | voidspace, did you click "Ship It!" btw? | 11:53 |
| voidspace | dimitern: yes | 11:53 |
| voidspace | dimitern: I really did | 11:54 |
| voidspace | dimitern: I've done it twice, but it doesn't seem to be showing up | 11:54 |
| dimitern | voidspace, yeah, weird... | 11:54 |
| voidspace | dimitern: I got an "untrusted connection" warning when I went to RB too | 11:54 |
| dimitern | voidspace, anyway, ta, I'll ping eric later about this | 11:54 |
| voidspace | dimitern: if I use http it works | 11:55 |
| voidspace | dimitern: https fails | 11:55 |
| voidspace | odd | 11:55 |
| voidspace | dimitern: Ship It! now visible anyway | 11:55 |
| dimitern | voidspace, ha! I've seen this as well - using https I had to add an exception because the cert was self-signed most likely | 11:56 |
| voidspace | dimitern: yeah, I added the exception ok | 11:56 |
| voidspace | dimitern: but if I use https then ship it doesn't work | 11:56 |
| dimitern | voidspace, really odd | 11:57 |
| voidspace | rogpeppe3: ping | 11:57 |
| voidspace | rogpeppe2: ping | 11:57 |
| voidspace | rogpeppe1: ping | 11:57 |
| rogpeppe3 | voidspace: pong | 11:57 |
| === rogpeppe3 is now known as rogpeppe | ||
| voidspace | rogpeppe3: hello Roger | 11:57 |
| rogpeppe | voidspace: hiya | 11:57 |
| voidspace | rogpeppe: morning | 11:57 |
| rogpeppe | voidspace: how's it going? | 11:57 |
| voidspace | rogpeppe: is there a tool for applying changes to go code that works by ast rewriting | 11:57 |
| voidspace | rogpeppe: like "go fix" but a general tool | 11:57 |
| rogpeppe | voidspace: gofmt :) | 11:57 |
| voidspace | rogpeppe: ah! | 11:58 |
| voidspace | rogpeppe: cool, thanks | 11:58 |
| rogpeppe | voidspace: check out gofmt -r | 11:58 |
| voidspace | rogpeppe: all is good, how's you? | 11:58 |
| rogpeppe | voidspace: but it depends what you want to do | 11:58 |
| voidspace | rogpeppe: do I need "gofmt" rather than "go fmt" | 11:58 |
| rogpeppe | voidspace: excellent, thanks | 11:58 |
| rogpeppe | voidspace: go fmt invokes gofmt | 11:58 |
| voidspace | rogpeppe: I want to rename an Interface method and all uses | 11:58 |
| voidspace | rogpeppe: ah, ok - I understood there were some historical differences | 11:58 |
| rogpeppe | voidspace: you possibly want to (brand new) gorename tool actually | 11:59 |
| rogpeppe | voidspace: the interface to go fmt is in terms of packages; the interface to gofmt is stdin/stdout and files | 11:59 |
| voidspace | rogpeppe: ok | 11:59 |
| rogpeppe | voidspace: i haven't succeeded in using it on a large code base yet though | 12:00 |
| voidspace | rogpeppe: ah :-) | 12:00 |
| rogpeppe | voidspace: but take a look at https://groups.google.com/forum/#!topic/golang-nuts/96hGPXYfqsM | 12:00 |
| voidspace | rogpeppe: I'm there already | 12:00 |
| rogpeppe | voidspace: if the method name is distinctive, then gofmt -r will probably do your job ok | 12:00 |
| voidspace | hmmm... gorename can't find the environs package it seems | 12:05 |
| voidspace | I'll try go fmt | 12:05 |
| wallyworld | jam: meeting? | 12:05 |
| jam | wallyworld: omw | 12:05 |
| jam | wallyworld: .... firefox just froze, be there in a sec | 12:06 |
| wallyworld | np | 12:06 |
| voidspace | dimitern: when you get a chance http://reviews.vapour.ws/r/479/ | 12:23 |
| voidspace | dimitern: it builds fine (so is probably correct), just running all tests | 12:23 |
| voidspace | dimitern: I used gofmt, but ended up having to use sed to fix comments (and then manually unfix some of things sed did) | 12:23 |
| voidspace | dimitern: so I might as well just have started with sed... | 12:24 |
| dimitern | voidspace, :) ok, looking | 12:26 |
| voidspace | dimitern: ooh | 12:27 |
| voidspace | dimitern: "Subnets returns basic information about all networks known" | 12:27 |
| voidspace | dimitern: should probably be | 12:27 |
| voidspace | dimitern: Subnets returns basic information about all subnets known | 12:28 |
| voidspace | dimitern: I'll make that change | 12:28 |
| dimitern | voidspace, yeah, I've just added a comment for this | 12:28 |
| voidspace | dimitern: pushed | 12:29 |
| voidspace | dimitern: I don't think you've published that comment yet anyway | 12:29 |
| dimitern | voidspace, LGTM, just sent my comment | 12:30 |
| voidspace | dimitern: cool, thanks | 12:30 |
| dimitern | voidspace, a bit of a problem | 13:04 |
| dimitern | voidspace, did you remember to rename ListNetworks to Subnets in environs/interface.go ? | 13:04 |
| dimitern | voidspace, because I see lots of build errors like *joyentEnviron does not implement environs.Environ (missing ListNetworks method) | 13:05 |
| dimitern | voidspace, I can't even say how this managed to land, because it does not build :) | 13:05 |
| dimitern | voidspace, ah, sorry - something was messed up with my local git repo - now it seems to work and there are no failures | 13:24 |
| sinzui | wwitzel3, is bug 1392390 not fix committed in master? | 14:11 |
| mup | Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Fix Committed by wwitzel3> <juju-core 1.21:In Progress by wwitzel3> <https://launchpad.net/bugs/1392390> | 14:11 |
| rogpeppe | fwereade_: do we check anywhere that a charm must have an install and/or a start hook? | 14:12 |
| fwereade_ | rogpeppe, nope | 14:12 |
| rogpeppe | fwereade_: ok, cool | 14:13 |
| rogpeppe | fwereade_: i could've sworn it did, but couldn't find the code | 14:13 |
| wallyworld | wwitzel3: is nate around? | 14:13 |
| jw4 | mgz, wallyworld out of disk space on CI build server? | 14:19 |
| wallyworld | jw4: just retry | 14:20 |
| jw4 | kk | 14:20 |
| jw4 | tx wallyworld | 14:20 |
| wallyworld | happens sometimes :-( | 14:20 |
| jw4 | :) | 14:20 |
| wallyworld | perrito666: when wwitzel3 or nate are around, could you mention bug 1392602 - i cannot find wtf is happening. it could be related to recent logging work, but i'm not sure. maybe they will have an idea | 14:21 |
| mup | Bug #1392602: local provider agent fails to restart on reboot of host - log dir missing <local-provider> <lxc> <regression> <juju-core:In Progress by wallyworld> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1392602> | 14:21 |
| mgz | jw4: it's still not clear what triggers that failure... but just retrying works | 14:37 |
| jw4 | mgz: yeah weird. I've $$retried$$ and so far it's looking good | 14:38 |
| jw4 | mgz: tx | 14:38 |
| jw4 | mgz: derp... now I get "failed to find "mongod" | 14:39 |
| mgz | >_< | 14:39 |
| voidspace | fun | 14:39 |
| mgz | jw4: I'll investigate, also seems like an 'ec2 is ill' type of issue | 14:39 |
| jw4 | bummer | 14:39 |
| jw4 | thx mgz | 14:40 |
| jw4 | mgz: shall I $$retry$$ or wait? | 14:40 |
| mgz | jw4: this one is just "no reachable servers" no? an intermittent test failure. | 14:40 |
| jw4 | mgz: yeah | 14:40 |
| mgz | though... I agree I've not seen MongoSuite.TestAddRemoveSet fail quite like that before | 14:41 |
| jw4 | mgz: lol it was because the build number was '1337' | 14:43 |
| jw4 | ;) | 14:43 |
| mgz | http://paste.ubuntu.com/9057111/ | 14:43 |
| mgz | jw4: send it through again | 14:43 |
| jw4 | k | 14:44 |
| wwitzel3 | sinzui: it is fix commited in master, I am getting the patch up for 1.21 now, not sure how it go reverted in lp, probably my fault :) | 14:49 |
| sinzui | wwitzel3, thank you for following up | 14:49 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| perrito666 | wwitzel3: natefinch ericsnow Ill be a couple of mins later, I am hogging my bw with a deploy | 14:57 |
| natefinch | k | 14:58 |
| natefinch | wwitzel3: ping? | 15:05 |
| wwitzel3 | natefinch: yep, sorry | 15:05 |
| sinzui | natefinch, I think bug 1392745 needs to attention, can you find someone to look into it? I amd jjo can gather information as needed | 15:16 |
| mup | Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745> | 15:16 |
| sinzui | natefinch, and I can offer access the the juju-ci3 env if someone needs to be on an affected env | 15:16 |
| mgz | jw4: you're a lucky one today | 15:17 |
| mgz | latest run, not seen a failure on this test before... | 15:17 |
| mgz | FAIL: metricmanager_test.go:20: MetricManagerSuite.TestRunner | 15:17 |
| mgz | looks like it's timing dependent though | 15:17 |
| mgz | jw4: test you added, so probably needs fixing? | 15:22 |
| mgz | wait... is that run not yours? I am confused | 15:23 |
| mgz | mattyw: ^ | 15:23 |
| mattyw | mgz, ah shit - I'll take a look, didn't realise that test had landed yet - probably only landed 10 minutes ago | 15:24 |
| jw4 | hmm; I'll investigate... I don't think it was mine | 15:24 |
| mattyw | mgz, jw4 it's all good | 15:25 |
| mattyw | mgz, jw4 it's failed trying to land the branch that test was added in - so the tests are doing their job | 15:25 |
| jw4 | mattyw: cool, tx! | 15:25 |
| jw4 | I'll try mine again for the fourth time | 15:25 |
| mattyw | jw4, I don't think you'd have seen that error? looks like my branch hasn't landed | 15:26 |
| jw4 | mattyw: right - my integration builds were failing due to space issues on the ci server | 15:26 |
| mgz | yeah, I'd just assumed the in-progress landing was jw4's again, but it was mattyw's, hence the confusion, sorry :) | 15:27 |
| jw4 | mgz: no worries - nice chat :) | 15:27 |
| * perrito666 is told that amazon will actually ship ram to his country without the 1 month wait in customs and he grins | 15:28 | |
| mgz | perrito666: real live rams? | 15:28 |
| perrito666 | mgz: well, they will be alive when shipped | 15:29 |
| perrito666 | rick_h_: btw, I loved the composition on rog/uros pic on your post | 15:36 |
| rick_h_ | perrito666: ty :) was playing with my fancy lens during the sprint a lot | 15:37 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| voidspace | anyone here familiar at all with gomaasapi ? | 15:58 |
| perrito666 | voidspace: I have been around there but most likely dont hve enough info to help youi | 15:59 |
| voidspace | perrito666: :-) | 15:59 |
| voidspace | perrito666: I need to call the api to claim a static ip address | 15:59 |
| perrito666 | voidspace: just ask the question and we can see | 15:59 |
| voidspace | I am doing... | 15:59 |
| voidspace | perrito666: I believe it looks like the following | 16:00 |
| voidspace | ipaddresses := environ.getMAASClient().GetSubObject("ipaddresses") | 16:00 |
| voidspace | _, err = ipaddresses.CallPost("", params) | 16:00 |
| voidspace | (response is not useful - either it succeeds or we get an error) | 16:00 |
| voidspace | perrito666: it's that empty string as the first argument to CallPost that bothers me | 16:00 |
| voidspace | perrito666: that's the "operation" parameter | 16:00 |
| voidspace | perrito666: but there's no operation here | 16:00 |
| perrito666 | voidspace: ah I have dealt with it | 16:00 |
| voidspace | it's a post to the ipaddresses api end point | 16:01 |
| voidspace | perrito666: right - have you called any endpoints without operations? | 16:01 |
| perrito666 | voidspace: you are dealing with a restful api there you not always have an op | 16:01 |
| voidspace | it looks odd | 16:01 |
| voidspace | perrito666: right | 16:01 |
| voidspace | I guess I have to try it :-) | 16:01 |
| voidspace | perrito666: I have a working maas server - I'll whip up some code to check it | 16:01 |
| voidspace | perrito666: thanks anyway | 16:01 |
| perrito666 | voidspace: so iirc that translates to /path/to/node?operation | 16:02 |
| voidspace | perrito666: this particularcall is directly paddresses/ | 16:02 |
| voidspace | no operation and no node id | 16:03 |
| perrito666 | voidspace: ahh addresses yes, that one is specially ugly | 16:03 |
| perrito666 | hold a sec, I was around there not long ago | 16:03 |
| voidspace | perrito666: ooh, I might be wrong | 16:03 |
| voidspace | perrito666: the GET is without an operation | 16:03 |
| voidspace | perrito666: looks like it's "reserve" | 16:03 |
| voidspace | POST /api/1.0/ipaddresses/ op=reserve | 16:03 |
| voidspace | my mistake then :-) | 16:04 |
| perrito666 | voidspace: you did look at http://maas.ubuntu.com/docs/api.html#ip-addresses right? | 16:04 |
| voidspace | perrito666: I did... | 16:04 |
| voidspace | perrito666: I think I looked at the GET by mistake :-D | 16:04 |
| voidspace | just looked now and seen "reserve" is the op... | 16:04 |
| voidspace | perrito666: thanks | 16:04 |
| perrito666 | voidspace: heh yes, happened to me too :p also there are a few with similar names so beware of not getting the wrong endpoint :p | 16:05 |
| katco | hey, go question: with a map, do you think it would be better to delete keys, or nil out their values? i would think that if the key had a good chance of being re-inserted, you'd want to nil out the value so the hash wouldn't continually be recomputed. thoughts? | 16:47 |
| mgz | katco: if it's not a giant map, I wouldn't worry about resizing | 16:48 |
| mgz | so, likely deleting makes better logical sense and is less likely to result in surprising bugs | 16:49 |
| katco | mgz: kind of thinking that as well | 16:49 |
| katco | mgz: b/c i would expect for people to be checking for "ok", not != nil | 16:49 |
| mgz | yup | 16:50 |
| katco | cool, ty sir! | 16:50 |
| katco | mgz: you've given me the confirmation bias that upholds my world-view! ;) | 16:50 |
| mgz | :) | 16:52 |
| natefinch | katco: definitely delete. Don't prematurely optimize... just do the most simple and straightforward thing . | 16:53 |
| katco | natefinch: i recognize and applaud your agreement with me. | 16:54 |
| katco | natefinch: seriously, thanks for chiming in ;) | 16:54 |
| * natefinch is the king of chiming in. ;) | 16:55 | |
| katco | haha | 16:55 |
| === tasdomas` is now known as tasdomas | ||
| voidspace | g'night all | 18:24 |
| === kadams54 is now known as kadams54-away | ||
| bodie_ | if I find that I keep needing to repeat myself with methods like map recursion, or a conformer for map keys, I would normally extract these into a library and import it. but, I don't know how I would handle this with juju | 18:59 |
| bodie_ | I expect importing a personal library would be unkosher | 18:59 |
| bodie_ | who could tell me where to put such things? e.g. a method for coercing map[interface{}]interface{} to map[string]interface{} | 19:06 |
| bodie_ | I'm kinda tempted just to open a PR with a personal import and see if it flies :S | 19:07 |
| === liam_ is now known as Guest63751 | ||
| bodie_ | it looks like charm master breaks its own tests | 20:07 |
| bodie_ | rogpeppe, config_test line 408: YAML error: reflect: reflect.Value.Set using unaddressable value | 20:09 |
| bodie_ | maybe it's an issue with my deps | 20:09 |
| bodie_ | doesn't seem to be | 20:10 |
| === urulama is now known as urulama___ | ||
| bodie_ | https://github.com/juju/charm/pull/80 rogpeppe | 20:13 |
| bodie_ | one-line fix | 20:13 |
| bodie_ | not sure if this is how it *should* work, but it patches the breakage | 20:13 |
| bodie_ | ah | 20:18 |
| bodie_ | I see | 20:18 |
| bodie_ | my charm master is out of sync with upstream because my upstream is gopkg.in/juju/charm.v4 | 20:19 |
| rogpeppe | bodie_: oops. looks like juju-core needs latest version of yaml package | 20:21 |
| rogpeppe | bodie_: i think it should anyway - if you could do that, i'd be happy :) | 20:21 |
| rogpeppe | bodie_: i'm not here BTW :) | 20:22 |
| bodie_ | rogpeppe, ack, so tweak the charm or the deps? | 20:22 |
| bodie_ | er, rogpeppe's IRC away bot | 20:22 |
| mgz | heads up for juju-core... talking about server moving to systemd, which means our dynamically upstart jobs will need adapting for vivid | 20:26 |
| ericsnow | thumper: ping | 20:27 |
| thumper | ericsnow: hey | 20:27 |
| ericsnow | thumper: I've addressed just about everything on http://reviews.vapour.ws/r/346/ | 20:28 |
| thumper | ericsnow: ok, will look again | 20:28 |
| ericsnow | thumper: left one open issue | 20:28 |
| ericsnow | thumper: thanks | 20:28 |
| === kadams54 is now known as kadams54-away | ||
| thumper | ericsnow: was trying to look at the differences, and all I get is empty files and errors: http://reviews.vapour.ws/r/346/diff/16-17/?page=2 | 20:40 |
| thumper | ericsnow: I'm assuming rb shouldn't do this? | 20:40 |
| ericsnow | thumper: it's because the branch depended on another branch | 20:42 |
| thumper | ah | 20:42 |
| thumper | ericsnow: ship it! | 20:42 |
| ericsnow | thumper: try diff'ing between 14 (where you last reviewed) and the latest | 20:42 |
| ericsnow | thumper: okay! | 20:42 |
| katco | well. i now know that my machine does not like spawning 100,000 instances of this test. | 20:57 |
| bodie_ | heh | 21:00 |
| bodie_ | my machine doesn't like running the juju core tests at all :/ I'm still trying to determine why I keep getting a reversed port number in the firewaller test | 21:01 |
| katco | i didn't expect it to become completely unresponsive... i thought the kernel scheduler was better than that | 21:03 |
| katco | 608s before it started giving me back control lol | 21:03 |
| katco | kind of. ugh. | 21:04 |
| katco | or gosh... maybe it's the window manager... | 21:06 |
| katco | ssh is working fine | 21:07 |
| katco | cpu and mem aren't under load... | 21:07 |
| * thumper goes to lie down for a bit | 21:17 | |
| waigani | thumper/menn0: after I take out the machineID and NetworkName from the openPorts doc, what should the localID of the doc look like? | 21:32 |
| waigani | right now it is: "m#<machineid>#n#<networkname> | 21:33 |
| waigani | if we update the quires to use the fields, should we let the localID just be generated by mongo? | 21:34 |
| cmars | bodie_, i've seen that firewaller bug as well, intermittently | 21:34 |
| cmars | bodie_, is it fairly repeatable for you? | 21:34 |
| cmars | bodie_, what version go compiler are you using | 21:35 |
| bodie_ | cmars, I wouldn't call it repeatable, but I've seen it I think three times now | 21:35 |
| bodie_ | cmars, 1.3.3 | 21:35 |
| cmars | bodie_, i'm using 1.3, and mgz just mentioned this could be a map ordering issue | 21:35 |
| waigani | thumper/menn0: just looking at how portsGlobalKey is used ... | 21:35 |
| bodie_ | cmars, that might make sense. should be a SameContents, perhaps | 21:36 |
| mgz | would explain why bot and others havenb't seen it, small maps are deterministically ordered on 1.2 | 21:36 |
| mgz | one of you needs to file a bug :P | 21:36 |
| cmars | bodie_, firewallerSuite.TestGetMachinePorts ? | 21:40 |
| bodie_ | cmars, aye | 21:41 |
| cmars | bodie_, i'll open it | 21:41 |
| bodie_ | much appreciated cmars, I'm already way over EOD trying to get something else landed | 21:41 |
| ericsnow | thumper: when would be a good time to talk about MESS and backups? | 21:48 |
| waigani | thumper/menn0: machineid and networkname need to be in the id for the watcher | 22:15 |
| menn0 | waigani: sorry, I don't actually know what you're doing | 22:16 |
| thumper | waigani: I didn't say to take them out of the id | 22:16 |
| thumper | waigani: just make sure they are also available outside the id | 22:16 |
| menn0 | waigani: why did you want to remove machineID and NetworkName from the openPorts doc? | 22:16 |
| waigani | thumper: right | 22:16 |
| thumper | like the envuuid | 22:16 |
| waigani | menn0: I misunderstood | 22:16 |
| menn0 | ok | 22:16 |
| rogpeppe | bodie_: tweak juju-core deps | 22:22 |
| katco | wallyworld: "This webpage has a redirect loop" | 22:24 |
| katco | not sure what's going on | 22:24 |
| wallyworld | :-( | 22:24 |
| wallyworld | i'l try opening hangout again | 22:24 |
| katco | wallyworld: i bet this is that stupid cookies issue i was having | 22:25 |
| mgz | don't eat the stupid cookies! | 22:25 |
| wallyworld | chocolate chip? | 22:25 |
| ericsnow | perrito666: FYI, all four of those patches have now landed | 22:26 |
| perrito666 | ericsnow: niiice, Ill start integration right away | 22:26 |
| menn0 | thumper: how do you feel about NewEnvironment's signature changing from this: | 22:54 |
| menn0 | NewEnvironment(env, server names.EnvironTag, owner names.UserTag, name string) (*Environment, error) | 22:54 |
| menn0 | to this: | 22:54 |
| menn0 | NewEnvironment(cfg *config.Config, server names.EnvironTag, owner names.UserTag, ownerPassword string) (*Environment, error) | 22:54 |
| thumper | so it creates an environment uuid? | 22:55 |
| thumper | why have ownerpassword? | 22:55 |
| thumper | and why remove the name? | 22:55 |
| menn0 | the name comes from the config | 22:56 |
| menn0 | ownerpassword is needed to set up the owner user | 22:56 |
| menn0 | the uuid also comes from the config | 22:56 |
| menn0 | thumper: ^ | 22:56 |
| thumper | the owner must already exist | 22:56 |
| menn0 | you're right | 22:57 |
| menn0 | createInitialUserOp should only be done by Initialize and not by NewEnvironment | 22:57 |
| menn0 | i'll fix that | 22:57 |
| thumper | perhaps, remove the server, and just add a comment that the environment will have the same server as the initial environment | 22:58 |
| thumper | the server uuid was added to enable us to store records to remote environments | 22:58 |
| thumper | which we have no use case for right now | 22:58 |
| thumper | maybe soon with cross environment relations | 22:58 |
| thumper | which will need other commands anyway | 22:58 |
| thumper | so... | 22:58 |
| menn0 | that makes sense | 22:58 |
| thumper | NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, error) | 22:59 |
| thumper | or | 22:59 |
| thumper | NewEnvironment(cfg *config.Config, owner names.UserTag) (*Environment, *State, error) | 22:59 |
| menn0 | I was wondering about returning the new state | 22:59 |
| thumper | so it returns a *State that would operate in that env? | 22:59 |
| menn0 | but it's easy to get with State.ForEnviron | 22:59 |
| thumper | sure | 23:00 |
| menn0 | and NewEnvironment doesn't need to create it itself | 23:00 |
| menn0 | so it's probably outside its responsibility to return it | 23:00 |
| menn0 | thumper: thanks I'll run with this | 23:03 |
| thumper | ok | 23:03 |
| thumper | cool | 23:03 |
| thumper | alexisb: are we meeting today? | 23:03 |
| alexisb | yes | 23:04 |
| thumper | k, be there in a sec | 23:05 |
| wallyworld | thumper: when you finished your meeting, i need to talk about bug 1392745 | 23:12 |
| mup | Bug #1392745: juju run doesn't after upgrade to 1.20.11 <canonical-bootstack> <regression> <run> <upgrade-juju> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392745> | 23:12 |
| thumper | :-( | 23:12 |
| === kadams54-away is now known as kadams54 | ||
| wallyworld | anastasiamac: review done, let me know if you have questions | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
