| thumper | davecheney: yeah | 00:01 |
|---|---|---|
| davecheney | thumper: merged your packaging fixes | 00:03 |
| davecheney | thank you very much | 00:03 |
| thumper | davecheney: awesome, ta | 00:03 |
| thumper | davecheney: lp hasn't noticed, have you pushed your packaging branch back up? | 00:03 |
| davecheney | it has | 00:03 |
| davecheney | it's sending me all sorts of email | 00:03 |
| davecheney | sppokey | 00:04 |
| thumper | davecheney: ah, I see it now, the MP is marked as merged. | 00:05 |
| thumper | davecheney: I wrote that magic :) | 00:05 |
| davecheney | how does it work ? | 00:06 |
| davecheney | smell your branch in my push ? | 00:06 |
| davecheney | (ewww) | 00:06 |
| thumper | kinda... | 00:07 |
| thumper | it notices a push from your branch. | 00:07 |
| thumper | it then looks for any pending merge proposals targetting your branch | 00:07 |
| thumper | it then looks at the tip revision id for each of those merge proposals | 00:07 |
| thumper | and if the tip revision of the source branch is in your branches ancestry, it gets marked merged | 00:07 |
| thumper | and it also works out which revision number on your branch it was merged at and saves that too | 00:08 |
| davecheney | very nice | 00:16 |
| * bigjools appreciates thumper's work there too | 00:20 | |
| thumper | the branch also gets its state changed to "merged" too | 00:21 |
| thumper | so it drops off the various branch listing pages | 00:21 |
| * thumper fires off the can of worms email before going to lunch | 00:21 | |
| thumper | so... lunch | 00:26 |
| * davecheney reads | 00:26 | |
| thumper | davecheney: did you say that there were bugs around this pipe closing behaviour? | 00:27 |
| thumper | davecheney: or were you referring to the hook serialisation bugs? | 00:27 |
| davecheney | oh, that | 00:27 |
| davecheney | that is fine | 00:27 |
| davecheney | you are sending EOF to stdin on the child process | 00:27 |
| davecheney | then waiting for it to exit | 00:27 |
| davecheney | the race is actaully the line after that | 00:27 |
| davecheney | were we close the logger | 00:27 |
| thumper | ah... no, I don't think that is write | 00:28 |
| thumper | we aren't closing stdin of the child | 00:28 |
| thumper | the outWriter is only set for stdout and stderr | 00:28 |
| thumper | so the process writes to the pipe | 00:29 |
| davecheney | that is crack, if you close the stdout of a child process, it'll get EPIPE | 00:29 |
| davecheney | this code is really subtle | 00:29 |
| * davecheney goes to reread | 00:29 | |
| * thumper goes to lunch, and to drop stuff in at the 2nd hand shop | 00:31 | |
| bigjools | I've got juju core tests passing on a new raring VM, but when I try locally I get loads of failures (I mean LOADS) like this: | 00:38 |
| bigjools | [LOG] 24.71999 ERROR api: error receiving request: read tcp 127.0.0.1:57535: use of closed network connection | 00:38 |
| bigjools | I've no idea what's different locally, how can I work this out? | 00:38 |
| bigjools | also, constraints_test.go:283: is failing on raring, it claims that lp:1132537 is fixed | 00:41 |
| davecheney | bigjools: i think that isn't the error | 00:42 |
| davecheney | just a symptom of the TearDownTest running after a failure | 00:42 |
| bigjools | almost certainly | 00:42 |
| davecheney | bigjools: got a larger paste ? | 00:42 |
| bigjools | I'll re-run, the output is massive | 00:43 |
| bigjools | give it its due - this is the first test suite that brought my 4-core to its knees | 00:44 |
| davecheney | that we do | 00:45 |
| bigjools | the disk is gettng hammered | 00:46 |
| davecheney | blame mongo | 00:46 |
| davecheney | i put /tmp on a /tmpfs | 00:46 |
| bigjools | heh | 00:47 |
| bigjools | I used to do that for Launchpad tests | 00:47 |
| bigjools | didn't make a lot of difference | 00:48 |
| bigjools | on the bright side, the mongo in raring works out of the box with juju-core | 00:48 |
| davecheney | excellent | 00:50 |
| davecheney | that is good news | 00:50 |
| bigjools | davecheney: http://paste.ubuntu.com/5688064/ | 00:50 |
| davecheney | bigjools: turns out | 00:51 |
| davecheney | it doens't | 00:51 |
| davecheney | PANIC: addrelation.go:0: ConstraintsCommandsSuite.TearDownTest | 00:51 |
| davecheney | ... Panic: local error: bad record MAC (PC=0x4117A4) | 00:51 |
| davecheney | /build/buildd/golang-1.0.2/src/pkg/runtime/proc.c:1443 in panic | 00:51 |
| davecheney | /home/ed/canonical/GO/src/launchpad.net/juju-core/testing/mgo.go:178 | 00:51 |
| davecheney | ^ your mongo does not speak TLS | 00:51 |
| bigjools | davecheney: wtf, the same mongo is installed on the VM, which works | 00:52 |
| davecheney | ldd $(which mongod) | 00:52 |
| davecheney | (from memory) | 00:52 |
| bigjools | yeah | 00:52 |
| bigjools | ssl is linked | 00:52 |
| bigjools | better, mongod -h | 00:52 |
| bigjools | shows ssl options at bottom | 00:52 |
| * bigjools is stumped | 00:58 | |
| davecheney | got several mongos installed ? | 01:00 |
| bigjools | not that I can see | 01:00 |
| bigjools | but looking for stray ones as we speak | 01:00 |
| bigjools | well, waiting for updatedb :) | 01:00 |
| thumper | bigjools: I'm running raring, and tests passing | 01:06 |
| thumper | bigjools: apart from an intermittant one this morning | 01:06 |
| bigjools | thumper: ta | 01:13 |
| bigjools | go fmt is great and all, but it creates extra lines of diff (and buggers bzr blame) lining up struct items if I add a new long one :( | 01:49 |
| davecheney | seroiusly fellas, can you please create a new channel for bitching about Go | 01:51 |
| bigjools | will that make Go better? | 01:55 |
| davecheney | it'll make me feel better | 02:00 |
| davecheney | Go is what it is | 02:00 |
| davecheney | it's not going to change | 02:00 |
| davecheney | not in a timeframe that is relevent to the problem at hand | 02:00 |
| davecheney | so all this bitching just gives me heartburn | 02:01 |
| bigjools | "it's not going to change" ... then it'll die | 02:02 |
| thumper | davecheney: can you remind me what it means to do a case <- some_channel in a select? | 02:02 |
| thumper | davecheney: under what situations does it wait? | 02:02 |
| thumper | davecheney: if it is a closed channel, it skips it? | 02:02 |
| thumper | bigjools: not everyone cares about whitespace changes | 02:03 |
| davecheney | it will wait only in the case that there is no default: clause in a select, and none of the other cases are rady | 02:03 |
| thumper | bigjools: better tools can help that | 02:03 |
| davecheney | ready | 02:03 |
| bigjools | thumper: that's my point | 02:03 |
| thumper | bigjools: what I mean is that it is not necessarily gofmt that is at fault, but the diff checking tools | 02:03 |
| bigjools | thumper: arguably, yes. Although whitespace is important in some places of course (Python) | 02:04 |
| thumper | davecheney: so for example: cmd/jujud/machine.go:80 will wait for both channels to close before moving on | 02:04 |
| thumper | bigjools: sure, but not really go | 02:05 |
| davecheney | yes, that will block until one of those conditions is true | 02:05 |
| thumper | got I hate the name tomb | 02:05 |
| thumper | it doesn't explain what it does at all | 02:06 |
| davecheney | thumper: the trick is that it then nils out the channel reference, so it can never be satisfyable again | 02:06 |
| thumper | davecheney: sure, but it looks like if either one fails, the tomb sets to dying | 02:06 |
| davecheney | yes, then it loops agian | 02:07 |
| thumper | davecheney: so <-nil is valid? | 02:07 |
| davecheney | from a quick reading, it's waiting for both of those things to finish | 02:07 |
| davecheney | then keeping the more important error of the two | 02:07 |
| davecheney | moreImportant(err, err) may be a subjective judgement | 02:08 |
| davecheney | WHO THE FUCK CHANGED THIS !!! | 02:33 |
| davecheney | 2013/04/08 12:33:09 INFO JUJU:juju:bootstrap environs: searching for tools compatible with version: 1.9.13-precise-amd64 | 02:33 |
| davecheney | 2013/04/08 12:33:09 DEBUG JUJU:juju:bootstrap listing tools in dir: tools/juju-1. | 02:33 |
| davecheney | 2013/04/08 12:33:14 DEBUG JUJU:juju:bootstrap listing tools in dir: tools/juju-1. | 02:33 |
| davecheney | 2013/04/08 12:33:15 ERROR JUJU:juju:bootstrap juju bootstrap command failed: cannot find tools: use of closed network connection | 02:33 |
| davecheney | the directory that we look for public tools has changed | 02:33 |
| thumper | huh? | 02:34 |
| davecheney | it should be tools/ | 02:34 |
| davecheney | not tools/juju-1. | 02:34 |
| thumper | hmm... | 02:35 |
| thumper | I thought that listed tools starting with that, so only listed version 1 tools | 02:36 |
| davecheney | maybe the listing hasn't change | 02:36 |
| davecheney | changed | 02:36 |
| davecheney | it just never failed before | 02:36 |
| davecheney | odd, it works with the source version, even without using upload tools | 02:36 |
| davecheney | maybe ec2 is having a lie down | 02:37 |
| thumper | maybe | 02:37 |
| davecheney | yup, now it works | 02:37 |
| thumper | :) | 02:37 |
| thumper | panic over? | 02:38 |
| davecheney | it's justifyable | 02:38 |
| davecheney | almost every day I go to test the tool | 02:38 |
| thumper | panic expected? | 02:38 |
| davecheney | it's borken | 02:38 |
| * thumper sighs... | 02:54 | |
| thumper | why does go make me have a return statement at the end of the function if it just says "return" | 02:54 |
| thumper | that's dumb | 02:54 |
| bigjools | thumper: do you get FAIL: constraints_test.go:276: ConstraintsSuite.TestGoyamlRoundtripBug1132537 | 02:54 |
| bigjools | on raring? | 02:54 |
| thumper | bigjools: nope | 02:54 |
| thumper | bigjools: tests pass for me on raring | 02:54 |
| bigjools | that's the only one I see failing | 02:55 |
| bigjools | did you update goyaml lately? | 02:55 |
| thumper | nope | 02:56 |
| bigjools | I am on revno 39 | 02:56 |
| * thumper looks | 02:57 | |
| thumper | 36 | 02:57 |
| bigjools | that'll be it then | 02:57 |
| * bigjools lunches, ttyl | 02:58 | |
| thumper | maybe... | 02:58 |
| * thumper wonders where kapil's tool is to get the reproducible builds... | 02:58 | |
| * thumper goes to get girls from school | 02:58 | |
| thumper | bbs | 02:58 |
| thumper | back | 03:19 |
| * thumper wondered why juju boostrap failed so often with error: cannot find tools: use of closed network connection | 04:19 | |
| thumper | and then it suddenly worked | 04:19 |
| thumper | ?! | 04:19 |
| * thumper away, probably back later | 04:28 | |
| rogpeppe | mornin' all | 06:30 |
| rogpeppe | dimitern: ping | 07:07 |
| dimitern | rogpeppe: hey | 07:08 |
| rogpeppe | dimitern: ho! | 07:08 |
| rogpeppe | dimitern: i was just looking at status watching for the allWatcher | 07:08 |
| dimitern | rogpeppe: yeah? | 07:08 |
| rogpeppe | dimitern: and realised that there's no statusDoc - we have a different doc type for units and machines | 07:09 |
| rogpeppe | dimitern: that makes things more awkward, and i was wondering if there's a compelling reason for it | 07:09 |
| dimitern | rogpeppe: that's right | 07:09 |
| dimitern | rogpeppe: because they're potentially different types of status information (units/machines) | 07:10 |
| rogpeppe | dimitern: i'm considering two alternatives: 1) just define the status as a string for each, and type-convert the result when returning Status. 2) have a different field name for each, and omit the other one when empty | 07:11 |
| rogpeppe | dimitern: because it makes my code considerably simpler if i can assume that each collection has a uniform schema | 07:12 |
| dimitern | rogpeppe: what's the complication now? | 07:13 |
| rogpeppe | dimitern: the code is simpler if i assume that there's a single type for a collection that can know how to marshal itself from the collection and how to update the allInfo when it changes | 07:15 |
| rogpeppe | dimitern: and i think that the rest of the code becomes no more complex, to be honest | 07:15 |
| rogpeppe | dimitern: in fact, it probably becomes a bit less magic | 07:15 |
| dimitern | rogpeppe: i'm not convinced getting rid of typed UnitStatus + constants (and for machines as well) is a better solution | 07:16 |
| rogpeppe | dimitern: i'm not suggesting that | 07:17 |
| rogpeppe | dimitern: the external interface (Status and GetStatus) would remain exactly as is | 07:17 |
| dimitern | rogpeppe: you're saying to save them in a single doc, casted as strings | 07:18 |
| rogpeppe | dimitern: that's option 1, yes. | 07:18 |
| rogpeppe | dimitern: it's statically type safe | 07:18 |
| rogpeppe | dimitern: which the current scheme is not | 07:18 |
| dimitern | rogpeppe: and the 2nd option? how's the field names important? | 07:18 |
| rogpeppe | dimitern: you'd have type statusDoc struct {UnitStatus params.UnitStatus `bson:",omitempty"; MachineStatus params.MachineStatus `bson:"omitempty"`; Info string} | 07:19 |
| dimitern | rogpeppe: so it's like a union | 07:20 |
| rogpeppe | dimitern: yeah | 07:20 |
| rogpeppe | dimitern: which is kinda what's happening now anyway | 07:21 |
| dimitern | rogpeppe: hmm... yeah, although it's explicit | 07:21 |
| dimitern | rogpeppe: so what about the field names? | 07:22 |
| rogpeppe | dimitern: what about them? | 07:22 |
| dimitern | rogpeppe: ah, sorry - I though using the same names for the 2 different docs was confusing | 07:23 |
| rogpeppe | dimitern: the point is i'd like there to be only one doc, same as we've got for every other collection | 07:23 |
| dimitern | rogpeppe: both options seem fair enough | 07:24 |
| dimitern | rogpeppe: i'd like to pass this through fwereade as well | 07:24 |
| rogpeppe | dimitern: yeah | 07:24 |
| dimitern | rogpeppe: I might be missing some subtleties | 07:24 |
| rogpeppe | dimitern: the second is more versatile (if we wanted to change UnitStatus to be more than a string, that would be ok); but that would be a major-version change in the current scheme too. | 07:26 |
| rogpeppe | dimitern: i'm leaning towards option 1 currently. it's the simplest approach, and not hard to change in a backwardly compatible way. | 07:27 |
| rogpeppe | dimitern: thanks for the discussion. i'll pass it by william when he comes online | 07:27 |
| dimitern | fwereade: hey | 07:31 |
| fwereade | dimitern, hey dude | 07:31 |
| dimitern | fwereade: having a bit of discussion with rogpeppe here, about having a single statusDoc to simplify the allwatcher | 07:32 |
| rogpeppe | fwereade: morning! | 07:32 |
| fwereade | rogpeppe, heyhey | 07:32 |
| * fwereade raises at least half an eyebrow but would like to hear more | 07:32 | |
| rogpeppe | fwereade: yeah - status is the only place (i think!) where we have more than one schema doc for a collection | 07:32 |
| fwereade | rogpeppe, ah, yes | 07:33 |
| rogpeppe | fwereade: it doesn't look like the gains are worth that much to me | 07:33 |
| rogpeppe | fwereade: and if it was consistent, it would make my code simpler (and probably the existing code would be a little simpler too) | 07:33 |
| fwereade | rogpeppe, well, it's really down to "are the unit status constants the same as the machine ones" | 07:33 |
| fwereade | rogpeppe, I am not unsympathetic to arguments that, yes, they are | 07:34 |
| rogpeppe | fwereade: in my mind it's down to "can they both be represented by a string?" | 07:34 |
| rogpeppe | fwereade: but there's an alternative approach if we think they might grow bigger | 07:34 |
| * fwereade is listening | 07:35 | |
| rogpeppe | fwereade: we could have a different field for the different kinds of status | 07:35 |
| rogpeppe | fwereade: type statusDoc struct {UnitStatus params.UnitStatus `bson:",omitempty"; MachineStatus params.MachineStatus `bson:"omitempty"`; Info string} | 07:35 |
| fwereade | rogpeppe, mm, not so awfully keen there | 07:35 |
| rogpeppe | fwereade: (which is actually the go standard approach to "unions" when marshalling) | 07:35 |
| fwereade | rogpeppe, interesting | 07:35 |
| rogpeppe | fwereade: but tbh at the moment i'm leaning towards type statusDoc struct {Status string; Info string} | 07:36 |
| rogpeppe | fwereade: and (static) type-convert when returning from the Status function and calling SetStatus | 07:37 |
| TheMue | moin | 07:38 |
| rogpeppe | TheMue: hiya! | 07:38 |
| fwereade | rogpeppe, that does sound reasonable, I think | 07:38 |
| rogpeppe | fwereade: cool | 07:38 |
| fwereade | TheMue, heyhey | 07:40 |
| dimitern | rogpeppe: I have to finish nonced provisioning branches first, then I'll propose the change to status | 07:46 |
| rogpeppe | dimitern: i'm happy to do it if you like | 07:46 |
| rogpeppe | dimitern: it's on the critical path for me | 07:46 |
| dimitern | rogpeppe: that'll be awesome | 07:46 |
| dimitern | rogpeppe: thanks | 07:46 |
| dimitern | fwereade: did we agree not to make MachineNonce required in the first CL (agent.Conf / MachineConfig)? | 08:10 |
| fwereade | dimitern, I think we planned to require it and pass a non-empty fake | 08:11 |
| fwereade | dimitern, but as you prefer | 08:11 |
| dimitern | fwereade: yeah, so I recall correctly | 08:11 |
| rogpeppe | dimitern: i'm just trying to understand this comment, that the _id in the status doc is omitted "to allow direct use of the document in both create and update transactions." | 08:13 |
| dimitern | fwereade: hmm.. no actually - see here: https://codereview.appspot.com/8247045/diff/1/environs/agent/agent_test.go#newcode226 | 08:13 |
| rogpeppe | dimitern: how does omitting _id allow that? | 08:13 |
| dimitern | rogpeppe: it allows you to do statusDoc{status, info}, rather than statusDoc{x.globalKey(), status, info} | 08:14 |
| rogpeppe | dimitern: and if that's true, how do the other docs get away with having that field and using the same doc for both create and update transactions | 08:14 |
| rogpeppe | ? | 08:14 |
| rogpeppe | dimitern: so we're just trying to save one function call? | 08:14 |
| dimitern | rogpeppe: no, we're still calling it, when we need to pass Id: of the txn.Op | 08:15 |
| rogpeppe | dimitern: so is the comment misleading? | 08:15 |
| rogpeppe | dimitern: is it actually "allowing" something, or is it just a convenience? | 08:15 |
| dimitern | rogpeppe: maybe it should've been "allows you to avoid specifying an explicit key for the document" or something | 08:16 |
| rogpeppe | dimitern: i'm only saying because i'd find it useful to have it there | 08:16 |
| rogpeppe | dimitern: and i'm wondering if there's a particular reason to avoid it | 08:16 |
| dimitern | rogpeppe: have the _id key? | 08:16 |
| rogpeppe | dimitern: yeah | 08:16 |
| rogpeppe | dimitern: it means a status doc can know its own id | 08:17 |
| dimitern | rogpeppe: well, for settingsRefDoc{1} works better than for the statusDoc{x, y} perhaps | 08:17 |
| dimitern | rogpeppe: is this that useful? | 08:18 |
| fwereade | rogpeppe, sorry, which docs with _ids do we use in updates? | 08:18 |
| fwereade | rogpeppe, I see a statusDoc as a dumb transport mechanism essentially -- to get one, you have to have a globalKey | 08:18 |
| dimitern | fwereade: looking at the comment link I posted above, istm for that test to be valid, nonce shouldn't be required | 08:19 |
| fwereade | rogpeppe, but in your case I can see how it would be useful | 08:19 |
| fwereade | dimitern, ah, sorry | 08:20 |
| fwereade | dimitern, we agreed required in MachineConfig | 08:20 |
| dimitern | rogpeppe: but not it agent.Conf? | 08:20 |
| fwereade | dimitern, every MC refers to a machine; not every Conf does | 08:20 |
| rogpeppe | fwereade: yeah, the only other place is constraintsDoc, i see | 08:20 |
| rogpeppe | fwereade: which equally doesn't have an id field | 08:20 |
| dimitern | fwereade: ok | 08:20 |
| fwereade | rogpeppe, I was asking about the otherway round actually | 08:21 |
| rogpeppe | dimitern: yeah, agent.Conf is used by all agents | 08:21 |
| fwereade | rogpeppe, how often do we update whole docs? | 08:21 |
| rogpeppe | dimitern: but the nonce is only used by the machine agent | 08:21 |
| rogpeppe | fwereade: constraints is the only place | 08:22 |
| dimitern | hey guys, meet danilos - newest member of blue squad! | 08:23 |
| rogpeppe | fwereade: and i'm going to have the same issue there | 08:23 |
| rogpeppe | danilos: welcome! | 08:23 |
| fwereade | danilos, heyhey | 08:24 |
| fwereade | rogpeppe, I am having trouble figuring out the problem though | 08:24 |
| fwereade | rogpeppe, you get events which have the _id of the changed document | 08:24 |
| fwereade | rogpeppe, that tells you everything you need to know, right? | 08:24 |
| rogpeppe | fwereade: yeah, you're right, there's no problem. | 08:25 |
| fwereade | rogpeppe, what's the situation where you need an _id and don;t have one available? | 08:25 |
| fwereade | rogpeppe, ah ok | 08:25 |
| rogpeppe | fwereade: i now understand that comment :-) | 08:26 |
| dimitern | rogpeppe: care to explain what you understood for me? :) | 08:27 |
| rogpeppe | dimitern: i'd thought that other docs were used in update transactions | 08:27 |
| rogpeppe | dimitern: but actually they're not (and presumably you'll get an error if you do) | 08:28 |
| fwereade | rogpeppe, yeah, IIRC it complains about setting _id even if it matches | 08:28 |
| dimitern | rogpeppe: what other docs? they're only 2 of them | 08:28 |
| rogpeppe | dimitern: unitDoc, machineDoc, etc | 08:28 |
| dimitern | rogpeppe: ah, right! | 08:28 |
| rogpeppe | fwereade: you could probably use omitempty, but yeah. | 08:28 |
| * dimitern needs to dash to the bank before it closes, bbiab | 08:36 | |
| danilos | rogpeppe, fwereade: hi, thanks :) | 08:37 |
| mattyw | rogpeppe, if I wanted to call the api from a unit, is there anything special I need to do? compared to calling it from local machine? | 08:45 |
| rogpeppe | mattyw: you'll need to know the address of the api server | 08:48 |
| mattyw | rogpeppe, ok, we can grab that from a file - the same as the gui does | 08:48 |
| rogpeppe | mattyw: and... it might be best if you don't give that unit the keys to the whole environment | 08:49 |
| rogpeppe | mattyw: but it'll be ok for the time being if you do | 08:49 |
| rogpeppe | mattyw: actually, you don't use that anyway, so there's no problem | 08:50 |
| rogpeppe | mattyw: you'll have to store the admin secret in a file too | 08:51 |
| rogpeppe | mattyw: rather than grabbing it from environments.yaml | 08:51 |
| rogpeppe | mattyw: or... you could just do exactly the same thing and put bogus provider keys in the environments.yaml file | 08:52 |
| rogpeppe | mattyw: although tbh it would be better not to - that way your unit can be portable across providers | 08:52 |
| mattyw | rogpeppe, at the moment we can probably just send the admin-secret up to the uint via config setting in the charm | 08:55 |
| rogpeppe | mattyw: seems reasonable | 08:56 |
| rogpeppe | mattyw: not very "secret" though :-) | 08:56 |
| mattyw | rogpeppe, yeah - it's not very long term | 08:57 |
| TheMue | fwereade: ping | 09:12 |
| fwereade | TheMue, pong | 09:12 |
| TheMue | fwereade: i'm a bit trapped ;) | 09:12 |
| fwereade | TheMue, I'm sorry about that, how can I help? | 09:13 |
| TheMue | fwereade: i changed the doc to be embedded, i've missed that before. but that i run on a mgo bug returning the error "slice of unaddressable array". | 09:13 |
| rogpeppe | dimitern: https://codereview.appspot.com/8510043 | 09:14 |
| TheMue | fwereade: so i changed, just for testing, uuid back into a slice instead an array. and hey, it works. | 09:14 |
| fwereade | TheMue, then the complications of the array are too much hassle, I guess | 09:14 |
| fwereade | TheMue, although, embedded? | 09:14 |
| TheMue | fwereade: so next step, set bson:_id on the uuid field. and oh no, it is not hashable. *sigh* | 09:14 |
| fwereade | TheMue, I meant to say a "doc" field | 09:15 |
| rogpeppe | TheMue: i'd use string for the uuid | 09:15 |
| TheMue | fwereade: eh, not embedded, as a regular field, like in the other entities. wrong word, sorry. | 09:15 |
| rogpeppe | TheMue: simpler all round | 09:15 |
| fwereade | rogpeppe, +1 | 09:15 |
| fwereade | TheMue, cool, just checking | 09:15 |
| fwereade | rogpeppe, TheMue, I would be fine even if trivial.NewUUID returned a string | 09:16 |
| rogpeppe | fwereade: sounds good to me | 09:16 |
| fwereade | rogpeppe, TheMue, we don't really seem to get a lot of value out of the type itself | 09:16 |
| TheMue | fwereade: ook, will do so, but only due to technological reasons, which i dislike. a uuid is a 16 octed array, and it has a string representation. | 09:16 |
| TheMue | fwereade: but it shall be ok here. | 09:17 |
| fwereade | TheMue, understood, but I'm fine with and data representation which is (1) unambiguous and (2) convenient | 09:17 |
| rogpeppe | TheMue: i think there's no good reason why we need to tie ourselves to UUID "standards" | 09:17 |
| TheMue | rogpeppe: i would prefer a database client not having troubles with it. ;) | 09:19 |
| rogpeppe | TheMue: i'm not sure what you mean | 09:19 |
| rogpeppe | TheMue: what db client is going to have a problem with an arbitrary string key? | 09:20 |
| TheMue | rogpeppe: and it's no "standards", it's an OSF/DCE standard. | 09:20 |
| TheMue | rogpeppe: not with a string, but the client should be able to handle a simple array of bytes. | 09:21 |
| TheMue | rogpeppe: using the string representation here is just a compromise, but hey, it's ok. | 09:21 |
| rogpeppe | TheMue: can you name a single advantage that we get from adhering to the OSF/DCE standard? | 09:21 |
| rogpeppe | TheMue: there's at least one disadvantage that i can think of | 09:23 |
| TheMue | rogpeppe: currently none, but the consequence is to ask for each standard why do you follow it. later, e.g. when having more integration aspects or new people coming into the team, have to maintain the code and ask themselves why here a standard hasn't been used is not good. | 09:24 |
| TheMue | rogpeppe: and we also have no real reason to not follow the standard, only the problem of mgo. | 09:26 |
| rogpeppe | TheMue: AFAICS the standard here just makes things a little more complex for no gain and some loss. in particular, you can't tell by seeing the UUID that it actually refers to a juju environment or which juju environment it might refer to. | 09:26 |
| rogpeppe | TheMue: if i'm seeing lots of juju env UUIDs flying around, that's very useful information | 09:26 |
| TheMue | rogpeppe: so you don't talk about a UUID anymore. you talk about an environment identifier and the decision how it has to look like. | 09:27 |
| rogpeppe | TheMue: yes | 09:27 |
| rogpeppe | TheMue: that's what we need | 09:27 |
| TheMue | rogpeppe: that's a totally different discussion, even it is a fine one :) | 09:27 |
| rogpeppe | TheMue: a universally unique environment identifier | 09:27 |
| TheMue | rogpeppe: hehe | 09:27 |
| TheMue | rogpeppe: would not have any problem with it. how would you ensure that it "speaks" and is also unique? | 09:28 |
| TheMue | fwereade: what do you say about it? don't use a UUID but an own invention? | 09:29 |
| rogpeppe | TheMue: "speaks"? | 09:29 |
| rogpeppe | TheMue: we ensure that it's unique in exactly the same way as you're doing currently - by using random bytes. | 09:30 |
| fwereade | TheMue, is there some problem with using a string representation of a UUID as you've already implemented it? | 09:30 |
| TheMue | rogpeppe: yeah, i don't have a better word. just a direct translation. ;) an identifier that contains useful informations. | 09:30 |
| rogpeppe | fwereade: see my comments above. i think it would be nice if our environment identifiers at least identified themselves as environments | 09:31 |
| TheMue | fwereade: please see the discussion above. not technologically, but rogpeppe correctly mentioned, that a regular one doesn't contain helpful informations. | 09:31 |
| rogpeppe | fwereade: BTW it would be wrong, i think to use the UUID as the key in the environment collection. | 09:32 |
| fwereade | rogpeppe, TheMue: (1) we need to supply JUJU_ENV_UUID (2) if we're calling it a UUID, we should make it resemble one (3) it's convenient to represent it as a string, both in the data layer and when communicating it to hooks (4) make it a string :) | 09:33 |
| fwereade | (5) that came from a UUID in the "standard" way | 09:33 |
| fwereade | (6) unless there's some concern about ambiguity | 09:33 |
| fwereade | rogpeppe, expand please | 09:33 |
| rogpeppe | fwereade: it means that only way to find out the uuid is by listing all items in that collection. | 09:34 |
| rogpeppe | fwereade: which may in the future contain more items | 09:34 |
| TheMue | fwereade: reasonable. where does somebody as a user has a direct contact with it? or is it just a pure technical reference to identify an environment? | 09:34 |
| fwereade | rogpeppe, if it contains more items, you'll be accessing it via an environment-specific state connection, won't you? | 09:34 |
| fwereade | TheMue, some charms want to use it, I'm afraid I don't know the detailed use case | 09:35 |
| rogpeppe | fwereade: it seems odd to use a key that you can't know in advance. | 09:35 |
| fwereade | TheMue, also, landscape wants to be able to identify environments | 09:35 |
| TheMue | fwereade: ok, and today it is a v4 uuid (in th epy code). | 09:36 |
| fwereade | TheMue, and that is a fine thing, and it's convenient to represent it as a string in our case | 09:36 |
| fwereade | TheMue, do they not store it as a string in python? | 09:36 |
| fwereade | TheMue, *surely* that's the convenient representation for yaml-in-zk? | 09:36 |
| rogpeppe | i think a string is the right representation, and leaves us open to changing the representation easily in the future if we should choose to do so | 09:37 |
| TheMue | fwereade: have to look, the generate it with an external package imho. | 09:37 |
| fwereade | TheMue, python is irrelevant really anyway | 09:37 |
| rogpeppe | fwereade: i think an "environment uuid" can reasonably look different from other kinds of uuid | 09:37 |
| rogpeppe | fwereade: i'm thinking of places where we've got something as-yet-to-be-invented that's dealing with lots of environments | 09:38 |
| TheMue | fwereade: but i have no problem with the uuid as string, i'm only coming from a world where the types are used as long as possible and the conversion into a representation (string, xml, json etc) is done when needed. ;) | 09:38 |
| rogpeppe | fwereade: and that an env-uuid would be a very useful thing to see in log files. | 09:39 |
| fwereade | TheMue, ISTM that we are doing it when needed ;) | 09:39 |
| TheMue | fwereade: due to database client reasons, but ok. :D | 09:40 |
| rogpeppe | fwereade: it's really an *environment id* we're talking about here | 09:40 |
| fwereade | rogpeppe, agreed -- but the UUID is unique, and no other aspect of an environment necessarily is | 09:40 |
| rogpeppe | fwereade: which we need to be globally unique | 09:40 |
| TheMue | fwereade: eh, btw, as slice there's no problem. really strange. | 09:40 |
| rogpeppe | TheMue: your Copy and Raw code is a bit dubious BTW | 09:40 |
| rogpeppe | TheMue: both of them do exactly the same thing | 09:41 |
| fwereade | rogpeppe, if we're dealing with lots of environments, we'll be identifying them by uuid | 09:41 |
| fwereade | rogpeppe, surely? | 09:41 |
| rogpeppe | fwereade: yes, but if there are lots of uuids flying around, it would be nice to know which ones refer to juju environments | 09:41 |
| rogpeppe | fwereade: surely what? | 09:42 |
| TheMue | rogpeppe: only different return types. | 09:42 |
| rogpeppe | TheMue: Copy is redundant. | 09:42 |
| rogpeppe | TheMue: uuid1 := uuid | 09:42 |
| rogpeppe | TheMue: does the same | 09:42 |
| fwereade | rogpeppe, ha, hadn't spotted that | 09:42 |
| rogpeppe | TheMue: Raw can be just return [16]byte(uuid) | 09:42 |
| TheMue | rogpeppe: came from a uuid being a slice first and indeed has to be changed, yes. thanks. | 09:43 |
| fwereade | rogpeppe, TheMue: weren't we just going to drop the type and return a string? | 09:43 |
| rogpeppe | fwereade: yeah, just saying for future reference. | 09:43 |
| fwereade | rogpeppe, TheMue: heh, I didn't know you could just "cat /proc/sys/kernel/random/uuid" | 09:44 |
| TheMue | fwereade: any problem with keeping the type but adding a function NewUUIDString() string? | 09:44 |
| rogpeppe | i'd prefer to see something like juju-24e5f46753 | 09:44 |
| rogpeppe | fwereade: cool | 09:44 |
| TheMue | fwereade: there are many ways. | 09:44 |
| rogpeppe | fwereade: that's a bit bigger than our 16 bytes :-) | 09:45 |
| fwereade | rogpeppe, what sort of context are you concerned about? | 09:45 |
| TheMue | rogpeppe: how would the juju-prefix help? | 09:45 |
| rogpeppe | TheMue: it would say "this string of random hex bytes means something in the context of juju" | 09:45 |
| fwereade | rogpeppe, huh? it just gives you a string representation, like we're discussing | 09:46 |
| fwereade | rogpeppe, I don't see the use case there | 09:46 |
| * TheMue neither | 09:46 | |
| rogpeppe | fwereade: we're talking about a name for something | 09:46 |
| rogpeppe | fwereade: it's nice if names have some meaningful information in them, i think | 09:46 |
| TheMue | rogpeppe: no, the name is the name, the uuid is simply an identifier. | 09:47 |
| fwereade | rogpeppe, what TheMue says | 09:47 |
| rogpeppe | TheMue: what is an identifier if not a name? | 09:47 |
| fwereade | rogpeppe, I don't want to denormalize name out into the uuid -- what if names become changeable? | 09:47 |
| fwereade | rogpeppe, a name is a property of an environment identifies by a UUID | 09:48 |
| TheMue | rogpeppe: it's a simple reference for something identifying it in a given context and not especially used by human beings. | 09:48 |
| rogpeppe | fwereade: we already use the name as a key into the user's environment | 09:48 |
| rogpeppe | TheMue: human beings will see these things all the time | 09:48 |
| TheMue | rogpeppe: they will see the name of the environment, not the id | 09:49 |
| rogpeppe | fwereade: i think there are probably sound reasons for not including the environment name actually (in particular it's nice to have a fixed-length key) | 09:49 |
| rogpeppe | fwereade: but i still think our string representation should identify itself as a juju environment identifier | 09:50 |
| fwereade | rogpeppe, yeah, and using plainly non-unique things as keys is rarely very sensible, it's going to be a problem for us | 09:50 |
| rogpeppe | fwereade: it's a level of sanity checking apart from anything else | 09:50 |
| rogpeppe | fwereade: it's only part of a key. uuids often contain non-unique sequence numbers too | 09:51 |
| fwereade | rogpeppe, obviously not every bit of a uuid has a unique value :/ | 09:51 |
| fwereade | rogpeppe, look, it's a UUID | 09:51 |
| rogpeppe | fwereade: indeed. | 09:51 |
| fwereade | rogpeppe, a UUID looks like X | 09:51 |
| * TheMue just references http://en.wikipedia.org/wiki/Universally_unique_identifier | 09:51 | |
| fwereade | rogpeppe, not like juju-X | 09:52 |
| fwereade | rogpeppe, I'm not going to tell people "we decided to improve on UUIDs" | 09:52 |
| fwereade | rogpeppe, even if they need improvement, now is not the time | 09:52 |
| rogpeppe | fwereade: it's not "improving on". it's adding some more information so we can easily say "this cannot possibly be a juju uuid" | 09:53 |
| rogpeppe | fwereade: there is absolutely nothing special about a UUID | 09:53 |
| TheMue | rogpeppe: where do you expect we need to answer this question? | 09:53 |
| rogpeppe | TheMue: UUIDs come from outside. whenever they do, we ask this question. | 09:53 |
| fwereade | rogpeppe, why do we care about the answer? | 09:54 |
| TheMue | rogpeppe: where do they come from outside? | 09:54 |
| fwereade | rogpeppe, "here's the env" or "env not found" | 09:54 |
| rogpeppe | fwereade: or "bogus environment identifier" - would be more helpful. | 09:54 |
| TheMue | rogpeppe: if the code asks the db "hey, i wonna have the env with the id 1234" and it finds it it's ok. | 09:55 |
| rogpeppe | fwereade: if UUIDs were so special, there wouldn't be so many different versions of them. | 09:55 |
| fwereade | rogpeppe, how so? who to? in what way does it pay for 3 engineers at $X/hr when there's a clear implementation out there already that we can just match? | 09:55 |
| TheMue | rogpeppe: only 5 | 09:55 |
| fwereade | rogpeppe, so, you're saying we should improve on them... | 09:55 |
| rogpeppe | fwereade: i'm saying they're just 16 random bytes in hex. job done. | 09:56 |
| TheMue | rogpeppe: and those 5 version differen in the way they are generated | 09:56 |
| TheMue | rogpeppe: nothing else | 09:56 |
| rogpeppe | TheMue: and in their string representations | 09:56 |
| TheMue | rogpeppe: that may be identifiers, but they aren't uuids. | 09:56 |
| rogpeppe | TheMue: why not? | 09:56 |
| rogpeppe | TheMue: they're ids and they're universally unique. | 09:57 |
| fwereade | rogpeppe, that is not the same thing as a UUID | 09:57 |
| TheMue | rogpeppe: there is only one standard in represent those 16 octets as string, no more | 09:57 |
| fwereade | rogpeppe, we need a UUID | 09:57 |
| dimitern | looking for a second review on https://codereview.appspot.com/8247045/ | 09:57 |
| fwereade | rogpeppe, that is what we will be implementing | 09:57 |
| fwereade | rogpeppe, not an I-decided-this-was-better-than-a-UUID | 09:58 |
| TheMue | fwereade: +1 | 09:58 |
| rogpeppe | fwereade: it's trivially *exactly the same* as a UUID | 09:58 |
| fwereade | rogpeppe, the bikeshade is puce, and I'm sticking to it | 09:58 |
| fwereade | rogpeppe, words have meanings | 09:58 |
| TheMue | rogpeppe: not the same, only similar | 09:58 |
| TheMue | rogpeppe: and JUJ_ENV_UUID contains the term UUID where people expect it to be one | 09:59 |
| * rogpeppe never understood why the form of a set of random bytes mattered | 09:59 | |
| dimitern | rogpeppe: maybe due to parsing something expected | 10:00 |
| rogpeppe | dimitern: it's a string... | 10:00 |
| TheMue | rogpeppe: you're discussing a design decision has been done a long time ago. would the variable has been introduced as JUJU_ENV_ID it would be more open. | 10:00 |
| TheMue | rogpeppe: but the decision has already been made. | 10:00 |
| dimitern | rogpeppe: btw and easy quick review? https://codereview.appspot.com/8247045/ | 10:01 |
| rogpeppe | dimitern: i'll swap you https://codereview.appspot.com/8510043/ | 10:01 |
| dimitern | rogpeppe: already did yours ;) | 10:01 |
| * rogpeppe refreshes his mail and sees it | 10:02 | |
| rogpeppe | dimitern: ta! | 10:02 |
| rogpeppe | dimitern: "what happens if somehow an invalid value ends up here?" | 10:03 |
| rogpeppe | dimitern: isn't it just the same as it was before? | 10:03 |
| rogpeppe | dimitern: i'm not sure i see how things are any different now. | 10:04 |
| dimitern | rogpeppe: well, before Status was typed, now it isn't | 10:04 |
| rogpeppe | dimitern: i don't think that makes any difference | 10:04 |
| rogpeppe | dimitern: each one could be read into the other before, as now | 10:04 |
| dimitern | rogpeppe: it does until you cast it explictly i guess | 10:05 |
| rogpeppe | dimitern: if you used a machine id to fetch a unit status doc before, you'd get exactly the same results as you get now | 10:05 |
| dimitern | rogpeppe: but anyway it's internally accessible only, so it'll be all right | 10:05 |
| rogpeppe | dimitern: yeah | 10:05 |
| rogpeppe | dimitern: we do no checking of valid statuses currently | 10:06 |
| rogpeppe | dimitern: anyone could do m.SetStatus("fdvdsfvfdsvfdsv", "") | 10:06 |
| rogpeppe | dimitern: with no repercussions | 10:06 |
| dimitern | rogpeppe: not sure - it must be params.MachineStatus value, isn't it? | 10:07 |
| rogpeppe | dimitern: no | 10:07 |
| rogpeppe | dimitern: a constant string is assignable to a typed string | 10:07 |
| rogpeppe | dimitern: you even do it yourself | 10:07 |
| dimitern | rogpeppe: ha! didn't know that | 10:07 |
| rogpeppe | dimitern: in Status you return "" for MachineStatus | 10:07 |
| rogpeppe | dimitern: constants in Go are untyped | 10:08 |
| dimitern | rogpeppe: :) cool, point taken | 10:08 |
| dimitern | can someone tell what do I need to setup to run ec2 live tests? | 10:21 |
| danilos | heya, anybody seen this problem with juju-core and golang from raring: http://pastebin.ubuntu.com/5688989/? I am sure I am doing something wrong, but I wonder what (and I couldn't find any reference web page for the package net/http/cookiejar) | 10:23 |
| mgz | dimitern: just source your ec2 creds and run in the environ/ec2 dir with -live I think | 10:24 |
| mgz | though you may also have some other flags now as well | 10:24 |
| dimitern | mgz: I don't have the same creds file as novarc for canonistack | 10:24 |
| dimitern | danilos: you need to call "go build ./..." and then possibly "go test ./..." (note the dot and the slash) | 10:25 |
| danilos | dimitern, ah, lovely syntax, thanks :) | 10:25 |
| mgz | you don't? I'm pretty sure john or I emailed you the bzr creds | 10:26 |
| dimitern | mgz: ha! let me look | 10:30 |
| mgz | look for gpg encrypted junk :) | 10:30 |
| dimitern | mgz: can't seem to find them; anyway I just created an account with aws anyway | 10:32 |
| dimitern | mgz: is there a wiki page with a similar setup for ec2, like for canonistack? | 10:33 |
| mgz | there's a docs page | 10:33 |
| mgz | but, I didn't re-edit the ec2 one, so it might not be as useful as the openstack one.... but you should work it out | 10:34 |
| mgz | I think there's a wrinkle with juju-core in that it doesn't look for the ecuatools form of the envvars | 10:34 |
| dimitern | so do I need anything else beside AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars? | 10:36 |
| mgz | ...I really want to have a session with evilnick at some point about what we need to make the docs sane for juju-core | 10:37 |
| mgz | dimitern: only the other normal bits. you can set some things like the region to something other than us east in your environment if you want | 10:38 |
| dimitern | mgz: ok | 10:39 |
| rogpeppe | dimitern: you have a review https://codereview.appspot.com/8247045/ | 10:41 |
| dimitern | rogpeppe: cheers! | 10:41 |
| rogpeppe | fwereade: any chance of a second opinion? https://codereview.appspot.com/8510043/ | 10:41 |
| dimitern | rogpeppe: any idea why i'm getting this error http://paste.ubuntu.com/5689043/ while running the ec2 live tests? | 10:52 |
| rogpeppe | dimitern: are you getting it every time? | 10:54 |
| dimitern | rogpeppe: that was the first run, but then I got "your account is being verified for the next 2h...", weird though - some tests pass, I can see instances running in the dashboard | 10:55 |
| dimitern | rogpeppe: will try later, I just registered the account 30m ago | 10:55 |
| rogpeppe | dimitern: with this kind of problem, i recommend ssh'ing to the machine as it's bootstrapping (as soon as the test logging prints its DNS name) and tail -f the cloud-init-output.log on the machine | 10:55 |
| dimitern | rogpeppe: will do, thanks | 10:56 |
| rogpeppe | dimitern: it looks like you've started the machine ok, but the mongo init has failed | 10:56 |
| jamespage | bigjools, (or anyone else): are you still seeing SSL issues with the MongoDB in raring? I upload 2.2.4 on Friday which contained some SSL related fixes | 10:57 |
| dimitern | rogpeppe: maybe it's something related to the account being not fully verified yet | 10:57 |
| rogpeppe | dimitern: there is a race between the connecting client and the init process, but the code logic *should* deal with that | 10:57 |
| rogpeppe | dimitern: i don't see anything ec2-related there | 10:57 |
| rogpeppe | dimitern: unauthorizedError comes from mongo, i think | 10:57 |
| dimitern | rogpeppe: I didn't paste the whole thing | 10:57 |
| rogpeppe | dimitern: it managed to make the connection to the mongo on the new machine | 10:58 |
| rogpeppe | dimitern: which indicates that your ec2 credentials worked fine | 10:58 |
| dimitern | rogpeppe: that error was reported a few times: http://paste.ubuntu.com/5689057/ | 10:58 |
| rogpeppe | dimitern: that's different | 10:58 |
| dimitern | probably only 1 instance at a time is allowed during these 2h | 11:00 |
| rogpeppe | dimitern: perhaps | 11:00 |
| rogpeppe | dimitern: i don't think your problem that you pasted first is to do with that though | 11:00 |
| TheMue | lunchtime | 11:00 |
| rogpeppe | dimitern: have you still got an instance running from that account? | 11:01 |
| dimitern | rogpeppe: how can I pause the test to inspect the log before it shuts down the instance/ | 11:01 |
| dimitern | rogpeppe: not anymore after the tests | 11:01 |
| rogpeppe | dimitern: i generally ssh in while the test is running | 11:01 |
| rogpeppe | dimitern: so you can see the log as it's being produced | 11:01 |
| rogpeppe | dimitern: alternatively, just ^C the test | 11:02 |
| dimitern | rogpeppe: I'll try just that test again, while sshing | 11:02 |
| rogpeppe | dimitern: good plan | 11:02 |
| rogpeppe | dimitern: one other thing | 11:02 |
| dimitern | FAIL: live_test.go:136: LiveTests.TestInstanceGroups - that's the one | 11:02 |
| rogpeppe | dimitern: i'd add a log statement | 11:02 |
| rogpeppe | dimitern: in juju.NewConn | 11:02 |
| rogpeppe | dimitern: after the "if state.IsUnauthorizedError" test | 11:03 |
| rogpeppe | dimitern: so that we can be sure that logic is being triggered | 11:03 |
| rogpeppe | dimitern: (if it gets an unauthorized error, it should continue trying to connect for a minute) | 11:03 |
| rogpeppe | dimitern: and i recommend running only TestBootstrapAndDeploy to start with | 11:04 |
| dimitern | rogpeppe: now it passed | 11:04 |
| dimitern | rogpeppe: ok, I'll add the log stmt | 11:04 |
| rogpeppe | dimitern: i don't think TestInstanceGroups was the one that failed for you, BTW | 11:05 |
| dimitern | rogpeppe: but for the bootstrap+deploy to work, i need to be able to run more than 1 instance, right? | 11:05 |
| rogpeppe | dimitern: yeah, but you'll see that error when it tries to initially connect to the state | 11:05 |
| dimitern | rogpeppe: add log.Warningf("juju: unauthorized error while connecting to state server; retrying") ? | 11:08 |
| rogpeppe | dimitern: sounds good | 11:08 |
| dimitern | rogpeppe: in the "if IsUnauth()" block? | 11:08 |
| rogpeppe | dimitern: actually, i think it's more a Notice | 11:08 |
| rogpeppe | dimitern: because it can happen in the normal course of events | 11:08 |
| rogpeppe | dimitern: yeah | 11:09 |
| rogpeppe | dimitern: i'm just wondering about name of the newly factored-out allWatcher | 11:11 |
| rogpeppe | dimitern: it's no longer inherently an all-watcher - it just watches a collection of stuff | 11:11 |
| rogpeppe | dimitern: i'm wondering about "combiWatcher" as a name | 11:11 |
| rogpeppe | fwereade: thoughts? ^ | 11:11 |
| dimitern | rogpeppe: combinedWatcher? | 11:12 |
| * fwereade reads back | 11:12 | |
| rogpeppe | dimitern: i'd really like something shorter | 11:12 |
| rogpeppe | fwereade: i've factored the allWatcher code into its own package | 11:13 |
| fwereade | rogpeppe, maybe multiWatcher? | 11:13 |
| rogpeppe | fwereade: i wondered about that | 11:13 |
| fwereade | rogpeppe, panopticon ;) | 11:13 |
| fwereade | rogpeppe, (ok, not "pan") | 11:13 |
| rogpeppe | fwereade: but several other things are actually "multi-watchers" | 11:13 |
| dimitern | rogpeppe: bootstrap and deploy failed again, this time the notice is there | 11:13 |
| rogpeppe | dimitern: did you ssh to the instance when it was bootstrapping? | 11:13 |
| fwereade | rogpeppe, no more so than other things are combi-watchers, surely? | 11:14 |
| rogpeppe | fwereade: yeah, i was thinking that | 11:14 |
| dimitern | rogpeppe: no, because i'm figuring out how to setup my .ssh/config to allow me to use my newly generated keypair | 11:14 |
| rogpeppe | dimitern: i do: ssh -i $home/.ec2/rog.pem ubuntu@$1 | 11:14 |
| rogpeppe | dimitern: in a script that i call "ec2ssh" | 11:15 |
| rogpeppe | dimitern: is this against trunk? | 11:15 |
| fwereade | dimitern, just `ssh ubuntu@` seems to work for me, I just have a standard id_rsa in ~/.ssh | 11:15 |
| rogpeppe | fwereade: it depends if you generated an ssh key pair or not | 11:16 |
| fwereade | rogpeppe, it was to having done that that I was alluding | 11:16 |
| dimitern | I added Host *.amazonaws.com + the key | 11:17 |
| rogpeppe | fwereade: ah yes, that will probably work with the usual authorized keys logic | 11:17 |
| dimitern | rogpeppe: ssh-ing and tailing cloud-init-output.log shows no errors (just host key generated; cloudinit finished) | 11:23 |
| rogpeppe | dimitern: hmm | 11:23 |
| dimitern | running again | 11:24 |
| rogpeppe | dimitern: can you bootstrap and run status ok? | 11:24 |
| rogpeppe | dimitern: could you paste the log of the test run? | 11:24 |
| dimitern | still running | 11:26 |
| rogpeppe | dimitern: i mean the one that just failed | 11:26 |
| rogpeppe | fwereade: i'm also looking for another name | 11:27 |
| rogpeppe | fwereade: there are two types exported by multiwatcher | 11:27 |
| rogpeppe | fwereade: one is the actual watcher used by clients | 11:27 |
| rogpeppe | fwereade: which was called StateWatcher, but now is (provisionally) multiwatcher.Watcher | 11:28 |
| rogpeppe | fwereade: the other is the type that's shared between several Watcher instances, that holds the record of everything that's currently around | 11:28 |
| rogpeppe | fwereade: it's only there to be used by state | 11:29 |
| rogpeppe | fwereade: i'm thinking multiwatcher.Store | 11:29 |
| rogpeppe | fwereade: but i dunno | 11:29 |
| dimitern | rogpeppe: cloud-init-output.log: http://paste.ubuntu.com/5689114/ | 11:29 |
| dimitern | rogpeppe: test log: http://paste.ubuntu.com/5689116/ | 11:29 |
| dimitern | rogpeppe: that's the one | 11:29 |
| fwereade | rogpeppe, Store sgtm | 11:30 |
| rogpeppe | dimitern: ah, so it did fail | 11:30 |
| rogpeppe | dimitern: see line 131 of the cloud-init output | 11:30 |
| rogpeppe | dimitern: it failed to download the tools | 11:30 |
| dimitern | rogpeppe: yeah, I saw that - when I was tailing it before it was too late probably | 11:31 |
| rogpeppe | dimitern: perhaps you're not authorized to push to s3 | 11:31 |
| dimitern | rogpeppe: could be, that's why I'll try in an hour or so, after verification | 11:32 |
| rogpeppe | dimitern: i'd be interested in exploring this failure mode actually | 11:32 |
| rogpeppe | dimitern, fwereade: i wonder if we shouldn't pipeline wget straight into tar xz | 11:33 |
| rogpeppe | we should probably download the tools, check the sha1sum and *then* untar them | 11:34 |
| fwereade | rogpeppe, +1 in spirit although I would prefer that they were actually signed | 11:35 |
| rogpeppe | fwereade: what would signing give us that an sha1sum doesn't? | 11:35 |
| rogpeppe | fwereade: (after all, signing is usually just signing a hash of the content anyway, right?) | 11:35 |
| fwereade | rogpeppe, requires compromise of the actual key used to sign, rather than just compromise of the hash and binary delivery channels | 11:36 |
| rogpeppe | fwereade: really? | 11:37 |
| fwereade | rogpeppe, isn't that the difference? what it takes to fake it? | 11:37 |
| rogpeppe | fwereade: isn't the key delivered through the same channel? | 11:37 |
| rogpeppe | fwereade: if someone can compromise your cloudinit, it doesn't matter what key you used to sign | 11:37 |
| fwereade | rogpeppe, I'm just talking about how the binaries/hashes get to juju | 11:38 |
| rogpeppe | fwereade: yeah - through cloudinit, right? | 11:38 |
| rogpeppe | fwereade: well, the hashes anyway | 11:38 |
| rogpeppe | fwereade: i think we have no choice but to trust the integrity of the cloud-init script | 11:39 |
| fwereade | rogpeppe, I wasn't concerned about cloud-init | 11:39 |
| rogpeppe | fwereade: in which case, a secure hash is as good as a signed binary, i think | 11:39 |
| rogpeppe | fwereade: it's a different matter for the mongo binary though | 11:39 |
| fwereade | rogpeppe, who generates the hash, and how do we trust them? | 11:39 |
| rogpeppe | fwereade: Bootstrap generates the hash | 11:40 |
| rogpeppe | fwereade: ah... doh! | 11:40 |
| rogpeppe | fwereade: public tools, sorry | 11:40 |
| rogpeppe | fwereade: i was thinking of upload-tools | 11:40 |
| fwereade | rogpeppe, yeah, I had the same realisation just now | 11:40 |
| rogpeppe | fwereade: yeah, we need signing | 11:40 |
| rogpeppe | fwereade: and for the public key to be embedded in the juju source. | 11:41 |
| fwereade | rogpeppe, exactly | 11:41 |
| fwereade | rogpeppe, ah, hmm | 11:41 |
| rogpeppe | fwereade: well, possibly with an override | 11:41 |
| fwereade | rogpeppe, we can't let a potentially-evil binary verify its own integrity | 11:42 |
| rogpeppe | fwereade: i'm sure there's any alternative | 11:43 |
| fwereade | rogpeppe, the pubkey goes in the client, pushed up to cloudinit, verify signature of downloaded tools inside cloudinit | 11:43 |
| fwereade | rogpeppe, untrusted client = game over anyway | 11:43 |
| rogpeppe | fwereade: exactly | 11:43 |
| rogpeppe | fwereade: we do need an override though, so that sync-tools can work | 11:44 |
| rogpeppe | sync-tools --public, that is | 11:44 |
| fwereade | rogpeppe, upload-tools? | 11:44 |
| rogpeppe | fwereade: that too | 11:44 |
| fwereade | rogpeppe, for sync-tools they're just the same files in a different location, though, right? | 11:44 |
| fwereade | rogpeppe, upload-tools involves either overriding or just disabling the checks in development mode | 11:45 |
| fwereade | rogpeppe, however I would rather have the override just so we're always exercising that code path | 11:45 |
| rogpeppe | fwereade: sync-tools --public is different, because other juju environments will use that public bucket | 11:51 |
| fwereade | rogpeppe, I'm not following | 11:51 |
| rogpeppe | fwereade: so we need to provide a env config way of specifying the tools/mongo(/either?) public key, i think | 11:51 |
| fwereade | rogpeppe, I agree that's the way to do it | 11:52 |
| rogpeppe | fwereade: bootstrap --upload-tools is {generate key; generate binaries; upload binaries signed with new key; bootstrap with cloudinit holding new key} | 11:52 |
| rogpeppe | fwereade: normal bootstrap is {get key from somewhere (defaulting to our public key); bootstrap with cloudinit holding that key} | 11:53 |
| fwereade | rogpeppe, yeah, sgtm | 11:53 |
| rogpeppe | s/somewhere/environment config/ | 11:53 |
| fwereade | rogpeppe, yep | 11:53 |
| rogpeppe | fwereade: i guess we want to allow sync-tools to generate a key too | 11:54 |
| mgz | fwereade: have we got any good starter bugs for danilo in juju-core? | 12:05 |
| === gary_poster|away is now known as gary_poster | ||
| fwereade | mgz, ooh, let me take a look, just a sec | 12:14 |
| fwereade | mgz, hmm, how about keyauth support for goose? you'd know better than I | 12:16 |
| fwereade | mgz, it's the card that looks most obviously bitesize to me | 12:16 |
| mgz | ah, that would be good | 12:17 |
| fwereade | mgz, alternatively, if he wants to hit core, then "hook execution serialization" might be a good one -- it should be relatively simple code in a single location | 12:18 |
| mgz | danilo: bug 1135335 | 12:18 |
| _mup_ | Bug #1135335: Keyauth support not available for Openstack providers <Go OpenStack Exchange:Triaged> <juju-core:New> < https://launchpad.net/bugs/1135335 > | 12:18 |
| fwereade | danilos, sorry, don;t know why I'm talking about you instead of to you | 12:18 |
| danilos | fwereade, hi, let me read up :) | 12:18 |
| fwereade | danilos, keyauth for openstack is probably better because it demands a bit less context, I think | 12:18 |
| danilos | mgz, fwereade: ok, I'll start with the keyauth and then after I am done I'll take a look at hook execution serialization (I assume that's bug 1121968) | 12:20 |
| _mup_ | Bug #1121968: hook serialization per-system <juju-core:New> < https://launchpad.net/bugs/1121968 > | 12:20 |
| fwereade | danilos, perfect, thanks | 12:20 |
| fwereade | danilos, I'm going to eat in a mo but feel free to ping me if yu have any questions, I shouldn't be long | 12:21 |
| mgz | so, the trick with keyauth is to look at the current docs, and python implementation, then fixup the goose code | 12:21 |
| mgz | https://juju.ubuntu.com/docs/provider-configuration-openstack.html | 12:21 |
| danilos | fwereade, thanks, sounds good | 12:21 |
| mgz | lp:juju juju/provider/openstack/credentials.py and ./client.py and tests | 12:22 |
| mgz | then lp:goose identity/ | 12:23 |
| fwereade | danilos, incidentally, before you do work on core, you might find it helpful to read the developer docs (most of the doc/ dir) | 12:23 |
| mgz | I'm happy to be bugged with questions or pair if you'd find that helpful | 12:23 |
| danilos | fwereade, yeah, started on that already, thanks | 12:23 |
| mgz | and yeah, the docs directory in juju-core is very useful for background on the design and implementation | 12:24 |
| fwereade | danilos, and I would be most grateful for criticisms from your POV, if there's anything unclear | 12:24 |
| danilos | mgz, sure, I'll take a look around first and will ping you as needed | 12:24 |
| danilos | fwereade, ack | 12:25 |
| TheMue | fwereade: another ping | 12:30 |
| dimitern | fwereade: updated https://codereview.appspot.com/8429044/ PTAL | 12:34 |
| dimitern | rogpeppe: also you please? ^^ | 12:34 |
| TheMue | dimitern: MachineNonce, my translator tells me that a nonce is a paedophile. i hope there are other meanings too. ;) | 12:36 |
| dimitern | TheMue: :D - see here http://en.wikipedia.org/wiki/Cryptographic_nonce | 12:37 |
| * dimitern bbi30m | 12:37 | |
| TheMue | dimitern: ah, not http://en.wikipedia.org/wiki/Nonce_(slang) | 12:38 |
| rogpeppe | dimitern: why do we need a special value for the bootstrap nonce? | 12:42 |
| rogpeppe | TheMue: that's new to me. the other meaning i know for nonce is "homosexual". | 12:43 |
| === teknico_ is now known as teknico | ||
| TheMue | rogpeppe: reminds me of the Mitsubishi Pajero, a word with a special meaning in South America :) | 12:45 |
| TheMue | rogpeppe: always interesting when terms have so different or multiple meanings | 12:46 |
| rogpeppe | dimitern: you have a review | 12:46 |
| === marcoceppi_ is now known as marcoceppi | ||
| * dimitern is back | 13:19 | |
| dimitern | rogpeppe: tyvm | 13:19 |
| dimitern | rogpeppe: because it's not generated by the provisioner | 13:20 |
| dimitern | fwereade: ping | 13:21 |
| fwereade | dimitern, pong | 13:21 |
| dimitern | fwereade: https://codereview.appspot.com/8429044/ :) | 13:21 |
| fwereade | dimitern, cool | 13:21 |
| rogpeppe | dimitern: that's true, but i'm not sure i see what it needs to be a particular special value | 13:21 |
| dimitern | rogpeppe: well, it has to have some value, and it's already special, so why not? | 13:22 |
| rogpeppe | dimitern: giving it a special constant makes it seems like it *has* to be that value | 13:23 |
| dimitern | rogpeppe: i don't understand what's your point, sorry, expand a bit more on why this is a bad idea? | 13:24 |
| rogpeppe | dimitern: i'm not sure it is. | 13:24 |
| TheMue | fwereade: a ping by me too ;) | 13:24 |
| dimitern | rogpeppe: what you rather have there instead? | 13:25 |
| rogpeppe | dimitern: i'd probably just have the provisioners pass in "" | 13:25 |
| fwereade | rogpeppe, it does have to be that value | 13:26 |
| dimitern | rogpeppe: the provisioner will never see that | 13:27 |
| dimitern | rogpeppe: it'll be already there at bootstrap time | 13:27 |
| rogpeppe | dimitern: oops, i meant the provider | 13:27 |
| rogpeppe | fwereade: oh? | 13:27 |
| fwereade | rogpeppe, that will be done in jujud bootstrap-state, I think, by passing it into InjectMachine (IIRC)? | 13:27 |
| dimitern | rogpeppe: ah, well I don't like "", it could be generated at bootstrap time, like in the provisioner though, so it's not fixed | 13:28 |
| rogpeppe | dimitern: i don't think that would help | 13:28 |
| fwereade | dimitern, I don't think there's much payoff to making it configurable | 13:28 |
| TheMue | fwereade: may i reserve the next ping-timeslot? ;) | 13:28 |
| fwereade | TheMue, sorry, pong | 13:29 |
| * rogpeppe quite likes the zero value as a default | 13:29 | |
| TheMue | fwereade: hehe | 13:29 |
| TheMue | fwereade: e'thing is now green, only one thing is open | 13:29 |
| dimitern | rogpeppe: well, what's not to like about "user-admin:bootstrap" ? :) | 13:29 |
| rogpeppe | dimitern: it makes it look like there's more structure there than there actually is | 13:29 |
| TheMue | fwereade: i changed the operation order when creating the env and co after Dimiters review. | 13:29 |
| fwereade | TheMue, yeah, you changed it the wrong way, it was right before | 13:30 |
| dimitern | rogpeppe: that's because you don't yet know the format what the PA will generate | 13:30 |
| TheMue | fwereade: you say that this order is wrong. could you explain why and which kind of error you expect here? | 13:30 |
| fwereade | TheMue, if a settings document exists without a matching entity, no big deal | 13:30 |
| dimitern | rogpeppe: it'll be similar "machine-<id>:<random hex token of (possibly) fixed length> | 13:31 |
| rogpeppe | dimitern: why not just a uuid? :-) | 13:31 |
| benji | I can't bootstrap, I'm getting "error: cannot log in to admin database: auth fails" | 13:31 |
| fwereade | rogpeppe, because the story is not specified to require a UUID? | 13:31 |
| dimitern | rogpeppe: it's too heavy perhaps.. | 13:32 |
| TheMue | fwereade: but doesn't the txn ensures that all is created or nothing? | 13:32 |
| rogpeppe | fwereade: i'd have thought that just a random hex token would be enough | 13:32 |
| rogpeppe | fwereade: but if we think we want an extra prefix, then who am i to argue? :-) | 13:32 |
| dimitern | rogpeppe: it has to be unique across the environment | 13:32 |
| rogpeppe | dimitern: sure. that's what randomness gives you. | 13:32 |
| fwereade | TheMue, yes, but with some subtleties | 13:33 |
| dimitern | rogpeppe: so even a counter should do | 13:33 |
| benji | I have run go get -u launchpad.net/... and done a build -a ./... and still have the problem. I have also switched S3 buckets (which has fixes similar issues in the past) | 13:33 |
| rogpeppe | dimitern: sure. | 13:33 |
| fwereade | TheMue, txn execution might be interrupted and not resumed for a while | 13:34 |
| TheMue | fwereade: ok, that's an argument | 13:34 |
| dimitern | benji: ec2? | 13:34 |
| fwereade | TheMue, we would like to use the existence of the entity documents as guarantees that certain other documents exist | 13:34 |
| benji | dimitern: yep | 13:34 |
| rogpeppe | dimitern: i just like the simplicity of "bootstrap" - it suggests a simple starting point. | 13:34 |
| * TheMue likes real dbms transactions ;) | 13:34 | |
| dimitern | benji: I had the same issue - are you using a newly created ec2 account? | 13:34 |
| * fwereade has become quite fond of mgo/txn | 13:34 | |
| TheMue | fwereade: so the order is constraints, settings, environment | 13:35 |
| benji | nope; this one has been active for a few years | 13:35 |
| rogpeppe | dimitern: and it's a really special value, so it doesn't matter that it's a different format. in fact that might even be better. | 13:35 |
| rogpeppe | dimitern: anyway, i don't wanna push any more. i just wanted to raise the question. | 13:35 |
| fwereade | TheMue, there's no relationship between constraints and settings, but both must come before the environment doc itself | 13:35 |
| TheMue | fwereade: ok, then the CL will flow in in a few seconds | 13:35 |
| dimitern | rogpeppe: well, I think we should keep it simple and use a const, what exact value to choose doesn't bother me that much | 13:35 |
| dimitern | fwereade: perhaps you can chip in on your idea behind "user-admin:bootstrap" meaning? | 13:36 |
| fwereade | benji, would you try pointing your public-bucket to an empty one? | 13:36 |
| benji | fwereade: control-bucket? | 13:37 |
| dimitern | fwereade: I had the same issue earlier, with a new bucket (well, haven't created it, just picked juju-askfjasljgfjgljfg) | 13:37 |
| fwereade | benji, public-bucket | 13:38 |
| dimitern | but I did set control-bucket, no public | 13:38 |
| benji | fwereade: I don't have a config setting with that name. Should I add one? | 13:38 |
| fwereade | benji, actually, simpler: would you check the current version number in version/version.go? | 13:38 |
| benji | fwereade: const version = "1.9.14" | 13:39 |
| fwereade | benji, if you were to add one we could eliminate the possibility of inappropriate tools being picked up for some reason | 13:40 |
| dimitern | fwereade, rogpeppe: I got it - bootstrap nonce is badged with the tag of the responsible entity | 13:40 |
| benji | fwereade: will do | 13:40 |
| fwereade | benji, we have surprising fallback behaviour across buckets that I'm working on | 13:40 |
| fwereade | benji, it's not certain to be the cause but at least it eliminates one avenue of ugliness | 13:40 |
| benji | fwereade: do I need to make that bucket public in S3? | 13:46 |
| fwereade | benji, not at all | 13:46 |
| benji | k | 13:46 |
| fwereade | benji, it defaults to "juju-dist" and gets the released tools | 13:46 |
| fwereade | benji, but if you point it somewhere empty, it'll work fine so long as you have sensible tools in the control-bucket | 13:47 |
| fwereade | benji, (well, maybe it will: there may be more going on, but that's how to get a definitely-clean environment) | 13:47 |
| benji | fwereade: I'm bootstrapping now with new public and control buckets | 13:48 |
| fwereade | benji, thanks -- if it's weird again, please paste me /var/log/cloud-init-output.log | 13:48 |
| benji | k | 13:49 |
| TheMue | Sh**, forgot to remove a comment. | 13:49 |
| rogpeppe | fwereade: here's an interesting thing | 13:49 |
| rogpeppe | fwereade: the API server does need to use JujuHomePath | 13:49 |
| rogpeppe | fwereade: because it gets charms | 13:49 |
| rogpeppe | fwereade: and therefore needs a charm cache | 13:49 |
| rogpeppe | fwereade: and that's how the charm cache works | 13:50 |
| fwereade | rogpeppe, that's an argument for parameterising the charm cache, I think | 13:50 |
| rogpeppe | fwereade: perhaps we should divorce the charm cache from JUJU_HOME | 13:50 |
| fwereade | rogpeppe, +1 | 13:50 |
| rogpeppe | dimitern: here's your allwatcher refactoring branch. it's a lot of lines but no logic changes: https://codereview.appspot.com/8458044/ | 13:52 |
| dimitern | rogpeppe: cheers, will look shortly | 13:53 |
| rogpeppe | dimitern: thanks | 13:53 |
| * dimitern hates this error already! => 2013/04/08 15:53:59 ERROR JUJU:juju:status state: connection failed, paused for 2s: dial tcp 23.21.7.175:37017: connection refused | 13:53 | |
| dimitern | it's arguably even an error | 13:53 |
| dimitern | so, practically I cannot do anything live on ec2, because there are no charms for quantal and no tools can be found without --upload-tools (or they fail to unpack during cloudinit) | 13:55 |
| rogpeppe | dimitern: yup | 13:58 |
| rogpeppe | dimitern: you can always download charms and rename them to quantal :-) | 13:58 |
| rogpeppe | dimitern: it's not an error | 13:58 |
| dimitern | I had to resort to juju deploy cs:~charmers/quantal/glance-4 as the easiest :) | 13:58 |
| rogpeppe | dimitern: it's a Notice | 13:58 |
| rogpeppe | dimitern: oh, hold on! | 13:59 |
| rogpeppe | dimitern: you can use fake-tools | 13:59 |
| rogpeppe | dimitern: or whatever it's called | 13:59 |
| dimitern | rogpeppe: eh? | 13:59 |
| dimitern | rogpeppe: --upload-tools --fake-tools ? | 13:59 |
| rogpeppe | dimitern: juju bootstrap --upload-tools -fake-series precise | 14:00 |
| rogpeppe | dimitern: it's in trunk | 14:00 |
| rogpeppe | fwereade: the help message should say that the series are comma-separate (assuming they are) | 14:00 |
| niemeyer | Hullah | 14:00 |
| rogpeppe | niemeyer: yo! | 14:01 |
| rogpeppe | niemeyer: good news, eh?! | 14:01 |
| niemeyer | rogpeppe: indeed! | 14:01 |
| dimitern | rogpeppe: cool, i'll try that next | 14:01 |
| rogpeppe | niemeyer: hopefully it'll be ultra-stable now :-) | 14:01 |
| niemeyer | rogpeppe: Let's hope so :) | 14:02 |
| dimitern | mramm: you around? | 14:02 |
| * dimitern yes! fake_nonce and provisioner works still | 14:03 | |
| benji | fwereade: same error; however, I don't see my new public bucket listed in S3; is the config setting simply "public-bucket" under the environment name? like so: | 14:05 |
| benji | environments: | 14:05 |
| benji | ec2: | 14:05 |
| benji | type: ec2 | 14:05 |
| benji | public-bucket: foo | 14:05 |
| fwereade | benji, yeah | 14:06 |
| benji | I wonder why it isn't listed in s3 then | 14:06 |
| * dimitern lunch, finally | 14:06 | |
| fwereade | benji, ok, I guess that wasn't it | 14:06 |
| fwereade | benji, we don't try to create it | 14:06 |
| benji | oh! I'll create it and try again | 14:07 |
| fwereade | rogpeppe, offhand, will we list an empty bucket without error? I *think* we do | 14:07 |
| rogpeppe | fwereade: i think so too | 14:07 |
| fwereade | benji, that shouldn't matter | 14:07 |
| fwereade | rogpeppe, I have been up to the elbows in a not-quite-up-to-date branch, haven't actually run tip lately | 14:08 |
| fwereade | rogpeppe, have you? | 14:08 |
| rogpeppe | fwereade: i think so. | 14:08 |
| rogpeppe | fwereade: actually, maybe not | 14:08 |
| rogpeppe | fwereade: i'll check again | 14:08 |
| dimitern | fwereade: it does create it, just tried | 14:09 |
| fwereade | dimitern, all the better then | 14:09 |
| mattyw | where do all the charm files in a unit get installed under juju-core? In pyju it was /var/juju/.... | 14:10 |
| benji | fwereade: I get the same error with a newly-created public-bucket | 14:16 |
| fwereade | benji, sorry, I clearly didn't communicate that it wouldn't make any difference -- would you paste me cloud-init-output.log please? | 14:17 |
| benji | fwereade: you communicated fine; I tried it anyway ;) | 14:17 |
| rvba | fwereade: Hi… in MAAS we don't have a shared storage to upload the tools once and for all… would it be reasonnable to get the provider to always upload the tools as part of the Bootstrap process? | 14:22 |
| fwereade | rvba, I'd recommend that people sync-tools before bootstrap | 14:23 |
| mattyw | mattyw, ^^ I'm an idiot :( | 14:23 |
| rvba | fwereade: so we don't do anything special in the provider itself, but we encourage people to use 'juju --upload-tools' ? | 14:23 |
| fwereade | rvba, I'd prefer to avoid that | 14:24 |
| rvba | fwereade: you mean avoid uploading the tools in the provider when Bootstrap() is called? | 14:25 |
| fwereade | rvba, jam recently added the juju sync-tools command | 14:25 |
| rvba | Ok, seems sane to me to keep the providers as similar as possible. | 14:26 |
| fwereade | rvba, if you have ec2 credentials in your env it will copy the latest ones form the official juju-dist bucket | 14:26 |
| fwereade | rvba, it's an extra step but not too painful | 14:27 |
| fwereade | rvba, I hope | 14:27 |
| rvba | fwereade: sounds good to me. | 14:27 |
| rvba | I'll cleanup the MAAS' provider code now. | 14:27 |
| rvba | fwereade: thanks! | 14:27 |
| mattyw | rogpeppe, ping? | 14:38 |
| benji | fwereade: I had to re-bootstrap so it took a while, but now I am confused as to how to fetch cloud-init-output.log if I can't ssh into the machine | 14:47 |
| fwereade | benji, can you not just ssh ubuntu@dns-name? | 14:47 |
| benji | fwereade: I'll try that | 14:48 |
| benji | fwereade: https://pastebin.canonical.com/88664/ | 14:51 |
| fwereade | benji, hmm, how about /var/lib/juju/... um, poke around for an agent.conf somewhere inside a dir called "bootstrap"? | 14:54 |
| rogpeppe | mattyw: pong | 14:54 |
| rogpeppe | mattyw: (sorry, was in a call) | 14:54 |
| mattyw | rogpeppe, no problem? can I borrow you in cloud-green? | 14:55 |
| rogpeppe | mattyw: sure | 14:55 |
| benji | fwereade: /var/lib/juju/agents/machine-0/agent.conf perhaps? | 14:55 |
| fwereade | benji, damn, sorry, I got completely distracted by test failures | 15:38 |
| fwereade | benji, I *think* there should be another one for bootstrap stuff | 15:39 |
| fwereade | rogpeppe, can you confirm how that one works ^^ | 15:39 |
| rogpeppe | fwereade: sorry, how what works? | 15:39 |
| benji | failing tests can have that effect on people :) | 15:39 |
| fwereade | rogpeppe, the agent conf for bootstrap-state | 15:40 |
| fwereade | rogpeppe, does it get it by pretending to be an agent called "bootstrap" or something? | 15:40 |
| rogpeppe | fwereade: something like that, yes | 15:40 |
| rogpeppe | fwereade: and the agent conf gets removed immediately | 15:40 |
| benji | fwereade: I have completely rebuilt the world (as best I understand how in go) and it seems to be working now. | 15:40 |
| rogpeppe | fwereade: after bootstrap-state has run | 15:40 |
| benji | boundless confidence | 15:41 |
| fwereade | rogpeppe, ah, ok -- funny, it seemed like benji was seeing bootstrap-state falling over | 15:41 |
| rogpeppe | fwereade: it's a very short-lived agent :-) | 15:41 |
| fwereade | rogpeppe, I'd expect the conf to be somewhere still around | 15:41 |
| rogpeppe | fwereade: no, i'm fairly sure it gets removed after use | 15:41 |
| fwereade | rogpeppe, that's a bit annoying if it happens even on failure | 15:41 |
| fwereade | benji, heh :( | 15:42 |
| rogpeppe | fwereade: yeah. tbh, we should probably do a set -e at the top of cloudinit | 15:42 |
| fwereade | benji, my current intention is not to leave this desk until I have sane tools | 15:42 |
| rogpeppe | fwereade: i've thought that a few times before but never actually done it | 15:42 |
| niemeyer | I'm getting a failure on CmdSuite.TestDestroyEnvironmentCommand | 15:42 |
| niemeyer | Is that known? | 15:42 |
| fwereade | niemeyer, no, I don't think so; bug please :) | 15:43 |
| niemeyer | [LOG] 51.40394 DEBUG api: <- error: read tcp 127.0.0.1:59023: use of closed network connection | 15:43 |
| niemeyer | [LOG] 51.40395 ERROR api: error receiving request: read tcp 127.0.0.1:59023: use of closed network connection | 15:43 |
| niemeyer | [LOG] 51.41987 ERROR rpc: client protocol error: unexpected EOF | 15:43 |
| niemeyer | fwereade: Cool | 15:43 |
| benji | fwereade: stay hydrated | 15:43 |
| fwereade | niemeyer, it's usually the bit just above that's important | 15:43 |
| fwereade | benji, cheers :) | 15:43 |
| niemeyer | fwereade: I don't see anything obvious | 15:44 |
| fwereade | niemeyer, but if nothing failed before that rogpeppe will be interested ;) | 15:44 |
| rogpeppe | he will indeed :-) | 15:44 |
| niemeyer | :) | 15:45 |
| niemeyer | Opening a ubg | 15:45 |
| niemeyer | bug | 15:45 |
| niemeyer | Ah, hold on | 15:45 |
| niemeyer | ... Panic: unauthorized (PC=0x42ED71) | 15:45 |
| rogpeppe | niemeyer: trunk tests pass for me | 15:45 |
| niemeyer | That's the issue | 15:46 |
| rogpeppe | niemeyer: that *might* have something to do with it :-) | 15:46 |
| niemeyer | /home/niemeyer/src/launchpad.net/juju-core/testing/mgo.go:205 | 15:46 |
| niemeyer | in MgoReset | 15:46 |
| rogpeppe | niemeyer: ah, i think i know what the issue is | 15:46 |
| rogpeppe | niemeyer: i've been thinking i could put it off, as it didn't seem to raise its head in normal tests | 15:46 |
| rogpeppe | niemeyer: the problem, i *think*, is that in the tests the API server runs as the same mongo user that the client connects as | 15:47 |
| rogpeppe | niemeyer: and the client changes its password immediately after connecting | 15:48 |
| rogpeppe | niemeyer: which invalidates the API server connection | 15:48 |
| niemeyer | rogpeppe: I see | 15:49 |
| rogpeppe | niemeyer: the answer is to have the API server connect as a different user (for instance, by creating machine 0 and setting the mongo password for the machine-0 entity) | 15:49 |
| rogpeppe | niemeyer: but that buggers up lots of tests | 15:49 |
| rogpeppe | niemeyer: so i left it on the back burner until i had a bit more time | 15:49 |
| niemeyer | rogpeppe: So a race.. okay | 15:50 |
| rogpeppe | niemeyer: yeah | 15:50 |
| rogpeppe | niemeyer: i saw the issue when i lowered the state/watcher refresh interval | 15:50 |
| niemeyer | fwereade: Done your suggestions | 15:50 |
| niemeyer | fwereade: On the publish command | 15:50 |
| niemeyer | fwereade: I also ended up just fixing InferURL so it handles the no-series case properly | 15:51 |
| fwereade | niemeyer, lovely, thanks, I'll try to take a look tonight | 15:51 |
| fwereade | niemeyer, <3 | 15:51 |
| niemeyer | fwereade: Rather than risking a change in behavior later | 15:51 |
| niemeyer | fwereade: Thanks | 15:51 |
| fwereade | niemeyer, yeah, +1 | 15:51 |
| rogpeppe | fwereade: there's one time that i don't have the _id to hand | 16:09 |
| fwereade | rogpeppe, oh yes? | 16:10 |
| rogpeppe | fwereade: which is when i fetch everything at the beginning | 16:10 |
| rogpeppe | fwereade: i guess i'll just duplicate the entity docs to give myself an id | 16:10 |
| fwereade | rogpeppe, can't you just fetch all the other stuff after fetching the entities that use them? | 16:11 |
| rogpeppe | fwereade: i'd prefer to avoid n round trips | 16:12 |
| rogpeppe | fwereade: although actually, now you come to mention it | 16:12 |
| rogpeppe | fwereade: hmm no | 16:13 |
| rogpeppe | fwereade: we really *should* avoid all those round trips if we can | 16:13 |
| rogpeppe | fwereade: i guess i'll just leave it as a todo | 16:13 |
| fwereade | rogpeppe, ah! yes, I see... sorry about that then | 16:13 |
| fwereade | rogpeppe, embed the doc in a wrapper with _id? | 16:13 |
| fwereade | rogpeppe, when getting all at once I mean | 16:13 |
| rogpeppe | fwereade: depends whether bson embedded types work properly or not, i suppose | 16:14 |
| rogpeppe | fwereade: unfortunately it doesn't work | 16:19 |
| fwereade | rogpeppe, bah | 16:19 |
| fwereade | rogpeppe, very well, do as you must | 16:20 |
| rogpeppe | fwereade: i'll go with the round trips for now | 16:20 |
| TheMue | Anyone interested in spending me a second LGTM: https://codereview.appspot.com/8322043 | 16:29 |
| fwereade | niemeyer, does http://paste.ubuntu.com/5689862/ look like something you'd know about? | 16:31 |
| niemeyer | fwereade: Looking | 17:00 |
| niemeyer | fwereade: Hmm | 17:01 |
| niemeyer | fwereade: I can see the issue, but I don't know why it's happening | 17:02 |
| niemeyer | fwereade: If I run "bzr log -v --long" here | 17:02 |
| niemeyer | fwereade: i get stuff like this: bzr/bzr.go bzr.go-20130403210030-zt48wpftmd160ox3-2 | 17:02 |
| niemeyer | fwereade: IOW, there's a digest after the filename | 17:03 |
| niemeyer | fwereade: The output you're observing doesn't have the digest | 17:03 |
| niemeyer | fwereade: It's easy to fix the test by dropping the empty space | 17:03 |
| niemeyer | fwereade: Slightly curious about why bzr is showing different results for that, though | 17:04 |
| fwereade | niemeyer, it's what I see when I do `bzr log -v --long` here | 17:04 |
| niemeyer | fwereade: It doesn't matter in this specific test, either way | 17:04 |
| fwereade | niemeyer, cool | 17:04 |
| niemeyer | fwereade: Right, so it's a mystery why the output string in that test doesn't show it | 17:04 |
| niemeyer | fwereade: But again, it doesn't matter.. the test is juts checking that the given file was added | 17:05 |
| fwereade | niemeyer, no, the weird version is what I see | 17:05 |
| niemeyer | fwereade: To verify that the commit behavior was basically sane | 17:05 |
| fwereade | niemeyer, yeah -- the other bits of the test look like they do that ok | 17:05 |
| niemeyer | fwereade: I suggest just dropping the space, on the basis that we don' care | 17:05 |
| niemeyer | don't | 17:05 |
| fwereade | niemeyer, ok, I'll bug it and assign it to myself, I don't want to get myself too distracted :) | 17:06 |
| niemeyer | fwereade: Btw, these multiple line outputs are handy.. I haven't seen it working in practice very often :) | 17:06 |
| niemeyer | fwereade: I can quickly shoot a one-liner | 17:06 |
| niemeyer | fwereade: Hold on | 17:06 |
| fwereade | niemeyer, tyvm | 17:07 |
| fwereade | niemeyer, I've found them pretty hendy in general | 17:07 |
| fwereade | niemeyer, er, handy | 17:07 |
| niemeyer | fwereade: https://codereview.appspot.com/8521043/ | 17:24 |
| fwereade | niemeyer, sorry, but I don't see the revision-id in that output | 17:25 |
| fwereade | niemeyer, that's also a (surprising) part of the problem | 17:26 |
| niemeyer | fwereade: Oh, indeed.. I missed that | 17:26 |
| fwereade | niemeyer, maybe I have a hideously outdated bzr? | 17:26 |
| niemeyer | fwereade: I have no idea then | 17:26 |
| niemeyer | fwereade: It looks like --long was ignored entirely | 17:26 |
| niemeyer | fwereade: Oh, hold on | 17:26 |
| niemeyer | fwereade: I probably mixed the options.. I may some defaults locally.. just a sec | 17:27 |
| niemeyer | fwereade: Yep | 17:27 |
| niemeyer | fwereade: --show-ids | 17:27 |
| niemeyer | fwereade: Can you please run log with --show-ids there and see if it helps? | 17:27 |
| fwereade | niemeyer, bingo | 17:27 |
| niemeyer | fwereade: Okay, so.. | 17:28 |
| fwereade | niemeyer, revision-id: fwereade@gmail.com-20130408082602-zu4ypfo9xoexns33 | 17:28 |
| niemeyer | fwereade: The test already had --show-ids.. :) | 17:28 |
| === deryck is now known as deryck[afk] | ||
| niemeyer | fwereade: Does it show the id next to the file as well? | 17:28 |
| fwereade | niemeyer, yeah | 17:28 |
| niemeyer | fwereade: So there's something funny going on there | 17:29 |
| niemeyer | fwereade: Why isn't that working in the test? | 17:29 |
| niemeyer | fwereade: It already uses -v --long --show-ids | 17:29 |
| fwereade | niemeyer, oh crap, my branch isn't up to date | 17:30 |
| niemeyer | fwereade: Hah. Tim fixed it | 17:30 |
| niemeyer | fwereade: Mystery solved | 17:30 |
| fwereade | niemeyer, heh | 17:30 |
| fwereade | niemeyer, thanks, sorry to distract | 17:30 |
| niemeyer | fwereade: np | 17:31 |
| rogpeppe | next CL in pipeline, if anyone cares to have a look: https://codereview.appspot.com/8487044/ | 17:38 |
| === BradCrittenden is now known as bac | ||
| rogpeppe | fwereade: ping | 18:57 |
| fwereade | rogpeppe, pong | 19:20 |
| rogpeppe | fwereade: i just noticed that the testing charm name contained the series, and wondered why | 19:20 |
| rogpeppe | fwereade: like cs:series/series-wordpress | 19:20 |
| rogpeppe | fwereade: it looked redundant, but i imagine there's a good reason | 19:21 |
| rogpeppe | fwereade: it confused me for a while - i thought i'd mucked something up | 19:21 |
| fwereade | rogpeppe, convenience somewhere... possibly getting an easy and unique ident string? | 19:21 |
| rogpeppe | fwereade: i'd've thought the charm name would be enough | 19:21 |
| rogpeppe | fwereade: (within the series, of course) | 19:22 |
| fwereade | rogpeppe, IIRC it came up when we were adding series support somewhere | 19:22 |
| fwereade | rogpeppe, exact provenance blurs slightly | 19:22 |
| rogpeppe | fwereade: yeah, it's quite a recent change, so i thought you might remember | 19:22 |
| rogpeppe | fwereade: (bzr ascribes credit to you :-]) | 19:23 |
| fwereade | rogpeppe, that's as close as I can get without hunting down the revision | 19:23 |
| rogpeppe | fwereade: ok, np | 19:23 |
| bac | hi rogpeppe, i know its late for you but can i bug you for a second? | 20:10 |
| rogpeppe | bac: sure | 20:10 |
| bac | rogpeppe: cool. so i've had to change one of the API return structs to change one of the existing entry names and to add another field. tests all updated and pass. | 20:11 |
| rogpeppe | fwereade: if you're still around, i could really do with a second review of https://codereview.appspot.com/8510043/ (i'm about to need it as a second dependency). it's pretty trivial. | 20:11 |
| rogpeppe | bac: ok | 20:11 |
| bac | rogpeppe: i rebuilt and reinstalled everything. multiple times | 20:11 |
| rogpeppe | bac: ok | 20:11 |
| bac | rogpeppe: but when i get the data back on the client side it looks like the old version | 20:12 |
| bac | rogpeppe: i've blown away $GOPATH/bin and pkg. rebuilt, reinstalled, killed my S3 bucket | 20:12 |
| rogpeppe | bac: you are bootstrapping with --upload-tools --fake-series precise, right? | 20:12 |
| bac | i'm at wits end | 20:12 |
| bac | no | 20:12 |
| bac | just --upload-tools | 20:12 |
| bac | juju bootstrap --upload-tools | 20:12 |
| rogpeppe | bac: what series are you deploying from? | 20:12 |
| bac | precise | 20:13 |
| bac | er, wait | 20:13 |
| bac | rogpeppe: my host is quantal. default-series in environments.yaml is precise | 20:13 |
| rogpeppe | bac: what API field have you changed? | 20:14 |
| bac | rogpeppe: ServiceGetResults s | 20:14 |
| rogpeppe | bac: perhaps you could push the branch, and i'll have a look | 20:15 |
| bac | rogpeppe: here's a diff: http://paste.ubuntu.com/5690437/ | 20:15 |
| rogpeppe | bac: in general though, it's *really* worthwhile bootstrapping with --fake-series precise --upload-tools | 20:16 |
| === deryck[afk] is now known as deryck | ||
| rogpeppe | bac: otherwise when you deploy a precise charm, it will fall back to using the old version of the tools | 20:16 |
| bac | rogpeppe: i'll try that. it smells environmental | 20:16 |
| bac | rogpeppe: ok, but like i said i changed buckets | 20:16 |
| rogpeppe | bac: yeah, but this is *within* an environment | 20:17 |
| bac | rogpeppe: right, but where would it get an old version of the tools if not from the bucket? | 20:17 |
| bac | unless i misunderstand | 20:17 |
| rogpeppe | bac: from the public bucket | 20:17 |
| bac | er | 20:18 |
| rogpeppe | bac: the one that gets used even if you don't use --upload-tools | 20:18 |
| bac | oh | 20:18 |
| rogpeppe | bac: that shouldn't be used on the bootstrap node though | 20:18 |
| rogpeppe | bac: but will be used on any other nodes that don't match the bootstrapped node's series | 20:19 |
| bac | rogpeppe: ok, i'm trying again with fake-seriese | 20:19 |
| rogpeppe | bac: ok, crossed fingers :-) | 20:19 |
| fwereade | rogpeppe, LGTM | 20:26 |
| rogpeppe | fwereade: ta! | 20:26 |
| bac | rogpeppe: --fake-series worked. thanks. | 20:32 |
| rogpeppe | bac: yay | 20:32 |
| rogpeppe | ! | 20:32 |
| bac | rogpeppe: is that indicative of a problem that should be investigated? | 20:32 |
| rogpeppe | bac: no | 20:33 |
| rogpeppe | bac: it's the solution to a problem that was :-) | 20:33 |
| rogpeppe | bac: and fwereade is working on a way to make it less easy to muck up that way | 20:33 |
| rogpeppe | bac: please share in juju-gui the fact that everyone should use --fake-series | 20:34 |
| bac | rogpeppe: your comments above made it sound like it shouldn't be required. fine by me...i can proceed! | 20:34 |
| * thumper settles down to read email | 21:05 | |
| fwereade | thumper, hell, I have not yet done my self-promised email burst today | 21:22 |
| thumper | :) | 21:22 |
| * thumper is replying to the placement thread... | 21:22 | |
| rogpeppe | thumper: hiya | 21:35 |
| thumper | hi rogpeppe | 21:35 |
| thumper | rogpeppe: still up I see | 21:35 |
| rogpeppe | thumper: yeah, trying to unblock the gui folks | 21:36 |
| fwereade | rogpeppe, I'm thinking I really should rename that -- we may be faking it up now, but cross-compiling should not actually be too far out of reach | 21:42 |
| rogpeppe | fwereade: i'm not sure. it might be an elusive goal unfortunately | 21:42 |
| fwereade | rogpeppe, meh, probably not worth it then | 21:44 |
| rogpeppe | fwereade: i'd prefer to have a wildcard tools fallback actually | 21:44 |
| rogpeppe | fwereade: if matching against the series directly fails, try "linux" | 21:44 |
| rogpeppe | fwereade: then make upload-tools upload to series==linux | 21:45 |
| rogpeppe | fwereade: i mean, we do have cross-compilation currently *almost* | 21:46 |
| fwereade | rogpeppe, it is just a dev tool anyway, I guess, we can be a bit freer about changing things | 21:51 |
| rogpeppe | fwereade: yeah | 21:51 |
| thumper | what is the purpose of the machine nonce? | 21:53 |
| fwereade | thumper, there's a window between provisioning a machine and recording it as provisioned in state | 21:54 |
| fwereade | thumper, if the provisioner goes down in that window, it will start a new machine | 21:55 |
| fwereade | thumper, and we'll end up with two instances running the "same" machine agent | 21:55 |
| fwereade | thumper, the nonce allows the machine agent to be sure that it's the official one before it starts messing around changing passwords and deploying units and stuff | 21:56 |
| thumper | so what happens when it isn't the official one/ | 21:56 |
| thumper | ? | 21:56 |
| fwereade | thumper, it stops immediately and waits for the provisioner to reap the instance | 21:58 |
| * thumper nods | 21:58 | |
| * thumper still thinks there is a problem with the hook logger | 21:58 | |
| thumper | rogpeppe: did you want to talk about it, or should I just keep it on the list | 21:59 |
| * fwereade is not entirely comfortable with it but doesn't quite have the headspace | 21:59 | |
| * fwereade will watch conversations with interest though | 21:59 | |
| rogpeppe | thumper: let's talk about it | 21:59 |
| thumper | rogpeppe: ok, hangout? | 22:00 |
| rogpeppe | thumper: ok | 22:00 |
| thumper | it'll make it hard for fwereade to watch :) | 22:00 |
| * thumper starts one | 22:00 | |
| rogpeppe | fwereade: feel free to join the fun | 22:00 |
| thumper | https://plus.google.com/hangouts/_/8078c0dcc36c791886bcd025be7df7b497f49c00?authuser=0&hl=en | 22:00 |
| rogpeppe | thumper: one little question, if i'm using bzr pipes, can i rename a branch in the pipeline without breaking the pipe links? | 22:37 |
| thumper | rogpeppe: not really | 22:37 |
| rogpeppe | thumper: ok, thought so, but thought i'd check. | 22:37 |
| rogpeppe | thumper: another thing: how can i link an existing branch into a pipeline? | 22:38 |
| thumper | rogpeppe: add-pipe referencing the existing branch | 22:38 |
| rogpeppe | thumper: ah, ok | 22:38 |
| rogpeppe | right that's me done for the day | 22:46 |
| rogpeppe | i've got quite a few reviews out if anyone cares to look | 22:47 |
| rogpeppe | g'night all | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!