[00:01] davecheney: yeah [00:03] thumper: merged your packaging fixes [00:03] thank you very much [00:03] davecheney: awesome, ta [00:03] davecheney: lp hasn't noticed, have you pushed your packaging branch back up? [00:03] it has [00:03] it's sending me all sorts of email [00:04] sppokey [00:05] davecheney: ah, I see it now, the MP is marked as merged. [00:05] davecheney: I wrote that magic :) [00:06] how does it work ? [00:06] smell your branch in my push ? [00:06] (ewww) [00:07] kinda... [00:07] it notices a push from your branch. [00:07] it then looks for any pending merge proposals targetting your branch [00:07] it then looks at the tip revision id for each of those merge proposals [00:07] and if the tip revision of the source branch is in your branches ancestry, it gets marked merged [00:08] and it also works out which revision number on your branch it was merged at and saves that too [00:16] very nice [00:20] * bigjools appreciates thumper's work there too [00:21] the branch also gets its state changed to "merged" too [00:21] so it drops off the various branch listing pages [00:21] * thumper fires off the can of worms email before going to lunch [00:26] so... lunch [00:26] * davecheney reads [00:27] davecheney: did you say that there were bugs around this pipe closing behaviour? [00:27] davecheney: or were you referring to the hook serialisation bugs? [00:27] oh, that [00:27] that is fine [00:27] you are sending EOF to stdin on the child process [00:27] then waiting for it to exit [00:27] the race is actaully the line after that [00:27] were we close the logger [00:28] ah... no, I don't think that is write [00:28] we aren't closing stdin of the child [00:28] the outWriter is only set for stdout and stderr [00:29] so the process writes to the pipe [00:29] that is crack, if you close the stdout of a child process, it'll get EPIPE [00:29] this code is really subtle [00:29] * davecheney goes to reread [00:31] * thumper goes to lunch, and to drop stuff in at the 2nd hand shop [00:38] 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] [LOG] 24.71999 ERROR api: error receiving request: read tcp 127.0.0.1:57535: use of closed network connection [00:38] I've no idea what's different locally, how can I work this out? [00:41] also, constraints_test.go:283: is failing on raring, it claims that lp:1132537 is fixed [00:42] bigjools: i think that isn't the error [00:42] just a symptom of the TearDownTest running after a failure [00:42] almost certainly [00:42] bigjools: got a larger paste ? [00:43] I'll re-run, the output is massive [00:44] give it its due - this is the first test suite that brought my 4-core to its knees [00:45] that we do [00:46] the disk is gettng hammered [00:46] blame mongo [00:46] i put /tmp on a /tmpfs [00:47] heh [00:47] I used to do that for Launchpad tests [00:48] didn't make a lot of difference [00:48] on the bright side, the mongo in raring works out of the box with juju-core [00:50] excellent [00:50] that is good news [00:50] davecheney: http://paste.ubuntu.com/5688064/ [00:51] bigjools: turns out [00:51] it doens't [00:51] PANIC: addrelation.go:0: ConstraintsCommandsSuite.TearDownTest [00:51] ... Panic: local error: bad record MAC (PC=0x4117A4) [00:51] /build/buildd/golang-1.0.2/src/pkg/runtime/proc.c:1443 in panic [00:51] /home/ed/canonical/GO/src/launchpad.net/juju-core/testing/mgo.go:178 [00:51] ^ your mongo does not speak TLS [00:52] davecheney: wtf, the same mongo is installed on the VM, which works [00:52] ldd $(which mongod) [00:52] (from memory) [00:52] yeah [00:52] ssl is linked [00:52] better, mongod -h [00:52] shows ssl options at bottom [00:58] * bigjools is stumped [01:00] got several mongos installed ? [01:00] not that I can see [01:00] but looking for stray ones as we speak [01:00] well, waiting for updatedb :) [01:06] bigjools: I'm running raring, and tests passing [01:06] bigjools: apart from an intermittant one this morning [01:13] thumper: ta [01:49] 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:51] seroiusly fellas, can you please create a new channel for bitching about Go [01:55] will that make Go better? [02:00] it'll make me feel better [02:00] Go is what it is [02:00] it's not going to change [02:00] not in a timeframe that is relevent to the problem at hand [02:01] so all this bitching just gives me heartburn [02:02] "it's not going to change" ... then it'll die [02:02] davecheney: can you remind me what it means to do a case <- some_channel in a select? [02:02] davecheney: under what situations does it wait? [02:02] davecheney: if it is a closed channel, it skips it? [02:03] bigjools: not everyone cares about whitespace changes [02:03] 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] bigjools: better tools can help that [02:03] ready [02:03] thumper: that's my point [02:03] bigjools: what I mean is that it is not necessarily gofmt that is at fault, but the diff checking tools [02:04] thumper: arguably, yes. Although whitespace is important in some places of course (Python) [02:04] davecheney: so for example: cmd/jujud/machine.go:80 will wait for both channels to close before moving on [02:05] bigjools: sure, but not really go [02:05] yes, that will block until one of those conditions is true [02:05] got I hate the name tomb [02:06] it doesn't explain what it does at all [02:06] thumper: the trick is that it then nils out the channel reference, so it can never be satisfyable again [02:06] davecheney: sure, but it looks like if either one fails, the tomb sets to dying [02:07] yes, then it loops agian [02:07] davecheney: so <-nil is valid? [02:07] from a quick reading, it's waiting for both of those things to finish [02:07] then keeping the more important error of the two [02:08] moreImportant(err, err) may be a subjective judgement [02:33] WHO THE FUCK CHANGED THIS !!! [02:33] 2013/04/08 12:33:09 INFO JUJU:juju:bootstrap environs: searching for tools compatible with version: 1.9.13-precise-amd64 [02:33] 2013/04/08 12:33:09 DEBUG JUJU:juju:bootstrap listing tools in dir: tools/juju-1. [02:33] 2013/04/08 12:33:14 DEBUG JUJU:juju:bootstrap listing tools in dir: tools/juju-1. [02:33] 2013/04/08 12:33:15 ERROR JUJU:juju:bootstrap juju bootstrap command failed: cannot find tools: use of closed network connection [02:33] the directory that we look for public tools has changed [02:34] huh? [02:34] it should be tools/ [02:34] not tools/juju-1. [02:35] hmm... [02:36] I thought that listed tools starting with that, so only listed version 1 tools [02:36] maybe the listing hasn't change [02:36] changed [02:36] it just never failed before [02:36] odd, it works with the source version, even without using upload tools [02:37] maybe ec2 is having a lie down [02:37] maybe [02:37] yup, now it works [02:37] :) [02:38] panic over? [02:38] it's justifyable [02:38] almost every day I go to test the tool [02:38] panic expected? [02:38] it's borken [02:54] * thumper sighs... [02:54] why does go make me have a return statement at the end of the function if it just says "return" [02:54] that's dumb [02:54] thumper: do you get FAIL: constraints_test.go:276: ConstraintsSuite.TestGoyamlRoundtripBug1132537 [02:54] on raring? [02:54] bigjools: nope [02:54] bigjools: tests pass for me on raring [02:55] that's the only one I see failing [02:55] did you update goyaml lately? [02:56] nope [02:56] I am on revno 39 [02:57] * thumper looks [02:57] 36 [02:57] that'll be it then [02:58] * bigjools lunches, ttyl [02:58] 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] bbs [03:19] back [04:19] * thumper wondered why juju boostrap failed so often with error: cannot find tools: use of closed network connection [04:19] and then it suddenly worked [04:19] ?! [04:28] * thumper away, probably back later [06:30] mornin' all [07:07] dimitern: ping [07:08] rogpeppe: hey [07:08] dimitern: ho! [07:08] dimitern: i was just looking at status watching for the allWatcher [07:08] rogpeppe: yeah? [07:09] dimitern: and realised that there's no statusDoc - we have a different doc type for units and machines [07:09] dimitern: that makes things more awkward, and i was wondering if there's a compelling reason for it [07:09] rogpeppe: that's right [07:10] rogpeppe: because they're potentially different types of status information (units/machines) [07:11] 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:12] dimitern: because it makes my code considerably simpler if i can assume that each collection has a uniform schema [07:13] rogpeppe: what's the complication now? [07:15] 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] dimitern: and i think that the rest of the code becomes no more complex, to be honest [07:15] dimitern: in fact, it probably becomes a bit less magic [07:16] rogpeppe: i'm not convinced getting rid of typed UnitStatus + constants (and for machines as well) is a better solution [07:17] dimitern: i'm not suggesting that [07:17] dimitern: the external interface (Status and GetStatus) would remain exactly as is [07:18] rogpeppe: you're saying to save them in a single doc, casted as strings [07:18] dimitern: that's option 1, yes. [07:18] dimitern: it's statically type safe [07:18] dimitern: which the current scheme is not [07:18] rogpeppe: and the 2nd option? how's the field names important? [07:19] dimitern: you'd have type statusDoc struct {UnitStatus params.UnitStatus `bson:",omitempty"; MachineStatus params.MachineStatus `bson:"omitempty"`; Info string} [07:20] rogpeppe: so it's like a union [07:20] dimitern: yeah [07:21] dimitern: which is kinda what's happening now anyway [07:21] rogpeppe: hmm... yeah, although it's explicit [07:22] rogpeppe: so what about the field names? [07:22] dimitern: what about them? [07:23] rogpeppe: ah, sorry - I though using the same names for the 2 different docs was confusing [07:23] dimitern: the point is i'd like there to be only one doc, same as we've got for every other collection [07:24] rogpeppe: both options seem fair enough [07:24] rogpeppe: i'd like to pass this through fwereade as well [07:24] dimitern: yeah [07:24] rogpeppe: I might be missing some subtleties [07:26] 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:27] 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] dimitern: thanks for the discussion. i'll pass it by william when he comes online [07:31] fwereade: hey [07:31] dimitern, hey dude [07:32] fwereade: having a bit of discussion with rogpeppe here, about having a single statusDoc to simplify the allwatcher [07:32] fwereade: morning! [07:32] rogpeppe, heyhey [07:32] * fwereade raises at least half an eyebrow but would like to hear more [07:32] fwereade: yeah - status is the only place (i think!) where we have more than one schema doc for a collection [07:33] rogpeppe, ah, yes [07:33] fwereade: it doesn't look like the gains are worth that much to me [07:33] 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] rogpeppe, well, it's really down to "are the unit status constants the same as the machine ones" [07:34] rogpeppe, I am not unsympathetic to arguments that, yes, they are [07:34] fwereade: in my mind it's down to "can they both be represented by a string?" [07:34] fwereade: but there's an alternative approach if we think they might grow bigger [07:35] * fwereade is listening [07:35] fwereade: we could have a different field for the different kinds of status [07:35] fwereade: type statusDoc struct {UnitStatus params.UnitStatus `bson:",omitempty"; MachineStatus params.MachineStatus `bson:"omitempty"`; Info string} [07:35] rogpeppe, mm, not so awfully keen there [07:35] fwereade: (which is actually the go standard approach to "unions" when marshalling) [07:35] rogpeppe, interesting [07:36] fwereade: but tbh at the moment i'm leaning towards type statusDoc struct {Status string; Info string} [07:37] fwereade: and (static) type-convert when returning from the Status function and calling SetStatus [07:38] moin [07:38] TheMue: hiya! [07:38] rogpeppe, that does sound reasonable, I think [07:38] fwereade: cool [07:40] TheMue, heyhey [07:46] rogpeppe: I have to finish nonced provisioning branches first, then I'll propose the change to status [07:46] dimitern: i'm happy to do it if you like [07:46] dimitern: it's on the critical path for me [07:46] rogpeppe: that'll be awesome [07:46] rogpeppe: thanks [08:10] fwereade: did we agree not to make MachineNonce required in the first CL (agent.Conf / MachineConfig)? [08:11] dimitern, I think we planned to require it and pass a non-empty fake [08:11] dimitern, but as you prefer [08:11] fwereade: yeah, so I recall correctly [08:13] 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] fwereade: hmm.. no actually - see here: https://codereview.appspot.com/8247045/diff/1/environs/agent/agent_test.go#newcode226 [08:13] dimitern: how does omitting _id allow that? [08:14] rogpeppe: it allows you to do statusDoc{status, info}, rather than statusDoc{x.globalKey(), status, info} [08:14] 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] ? [08:14] dimitern: so we're just trying to save one function call? [08:15] rogpeppe: no, we're still calling it, when we need to pass Id: of the txn.Op [08:15] dimitern: so is the comment misleading? [08:15] dimitern: is it actually "allowing" something, or is it just a convenience? [08:16] rogpeppe: maybe it should've been "allows you to avoid specifying an explicit key for the document" or something [08:16] dimitern: i'm only saying because i'd find it useful to have it there [08:16] dimitern: and i'm wondering if there's a particular reason to avoid it [08:16] rogpeppe: have the _id key? [08:16] dimitern: yeah [08:17] dimitern: it means a status doc can know its own id [08:17] rogpeppe: well, for settingsRefDoc{1} works better than for the statusDoc{x, y} perhaps [08:18] rogpeppe: is this that useful? [08:18] rogpeppe, sorry, which docs with _ids do we use in updates? [08:18] rogpeppe, I see a statusDoc as a dumb transport mechanism essentially -- to get one, you have to have a globalKey [08:19] fwereade: looking at the comment link I posted above, istm for that test to be valid, nonce shouldn't be required [08:19] rogpeppe, but in your case I can see how it would be useful [08:20] dimitern, ah, sorry [08:20] dimitern, we agreed required in MachineConfig [08:20] rogpeppe: but not it agent.Conf? [08:20] dimitern, every MC refers to a machine; not every Conf does [08:20] fwereade: yeah, the only other place is constraintsDoc, i see [08:20] fwereade: which equally doesn't have an id field [08:20] fwereade: ok [08:21] rogpeppe, I was asking about the otherway round actually [08:21] dimitern: yeah, agent.Conf is used by all agents [08:21] rogpeppe, how often do we update whole docs? [08:21] dimitern: but the nonce is only used by the machine agent [08:22] fwereade: constraints is the only place [08:23] hey guys, meet danilos - newest member of blue squad! [08:23] fwereade: and i'm going to have the same issue there [08:23] danilos: welcome! [08:24] danilos, heyhey [08:24] rogpeppe, I am having trouble figuring out the problem though [08:24] rogpeppe, you get events which have the _id of the changed document [08:24] rogpeppe, that tells you everything you need to know, right? [08:25] fwereade: yeah, you're right, there's no problem. [08:25] rogpeppe, what's the situation where you need an _id and don;t have one available? [08:25] rogpeppe, ah ok [08:26] fwereade: i now understand that comment :-) [08:27] rogpeppe: care to explain what you understood for me? :) [08:27] dimitern: i'd thought that other docs were used in update transactions [08:28] dimitern: but actually they're not (and presumably you'll get an error if you do) [08:28] rogpeppe, yeah, IIRC it complains about setting _id even if it matches [08:28] rogpeppe: what other docs? they're only 2 of them [08:28] dimitern: unitDoc, machineDoc, etc [08:28] rogpeppe: ah, right! [08:28] fwereade: you could probably use omitempty, but yeah. [08:36] * dimitern needs to dash to the bank before it closes, bbiab [08:37] rogpeppe, fwereade: hi, thanks :) [08:45] 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:48] mattyw: you'll need to know the address of the api server [08:48] rogpeppe, ok, we can grab that from a file - the same as the gui does [08:49] mattyw: and... it might be best if you don't give that unit the keys to the whole environment [08:49] mattyw: but it'll be ok for the time being if you do [08:50] mattyw: actually, you don't use that anyway, so there's no problem [08:51] mattyw: you'll have to store the admin secret in a file too [08:51] mattyw: rather than grabbing it from environments.yaml [08:52] mattyw: or... you could just do exactly the same thing and put bogus provider keys in the environments.yaml file [08:52] mattyw: although tbh it would be better not to - that way your unit can be portable across providers [08:55] rogpeppe, at the moment we can probably just send the admin-secret up to the uint via config setting in the charm [08:56] mattyw: seems reasonable [08:56] mattyw: not very "secret" though :-) [08:57] rogpeppe, yeah - it's not very long term [09:12] fwereade: ping [09:12] TheMue, pong [09:12] fwereade: i'm a bit trapped ;) [09:13] TheMue, I'm sorry about that, how can I help? [09:13] 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:14] dimitern: https://codereview.appspot.com/8510043 [09:14] fwereade: so i changed, just for testing, uuid back into a slice instead an array. and hey, it works. [09:14] TheMue, then the complications of the array are too much hassle, I guess [09:14] TheMue, although, embedded? [09:14] fwereade: so next step, set bson:_id on the uuid field. and oh no, it is not hashable. *sigh* [09:15] TheMue, I meant to say a "doc" field [09:15] TheMue: i'd use string for the uuid [09:15] fwereade: eh, not embedded, as a regular field, like in the other entities. wrong word, sorry. [09:15] TheMue: simpler all round [09:15] rogpeppe, +1 [09:15] TheMue, cool, just checking [09:16] rogpeppe, TheMue, I would be fine even if trivial.NewUUID returned a string [09:16] fwereade: sounds good to me [09:16] rogpeppe, TheMue, we don't really seem to get a lot of value out of the type itself [09:16] 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:17] fwereade: but it shall be ok here. [09:17] TheMue, understood, but I'm fine with and data representation which is (1) unambiguous and (2) convenient [09:17] TheMue: i think there's no good reason why we need to tie ourselves to UUID "standards" [09:19] rogpeppe: i would prefer a database client not having troubles with it. ;) [09:19] TheMue: i'm not sure what you mean [09:20] TheMue: what db client is going to have a problem with an arbitrary string key? [09:20] rogpeppe: and it's no "standards", it's an OSF/DCE standard. [09:21] rogpeppe: not with a string, but the client should be able to handle a simple array of bytes. [09:21] rogpeppe: using the string representation here is just a compromise, but hey, it's ok. [09:21] TheMue: can you name a single advantage that we get from adhering to the OSF/DCE standard? [09:23] TheMue: there's at least one disadvantage that i can think of [09:24] 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:26] rogpeppe: and we also have no real reason to not follow the standard, only the problem of mgo. [09:26] 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] TheMue: if i'm seeing lots of juju env UUIDs flying around, that's very useful information [09:27] 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] TheMue: yes [09:27] TheMue: that's what we need [09:27] rogpeppe: that's a totally different discussion, even it is a fine one :) [09:27] TheMue: a universally unique environment identifier [09:27] rogpeppe: hehe [09:28] rogpeppe: would not have any problem with it. how would you ensure that it "speaks" and is also unique? [09:29] fwereade: what do you say about it? don't use a UUID but an own invention? [09:29] TheMue: "speaks"? [09:30] TheMue: we ensure that it's unique in exactly the same way as you're doing currently - by using random bytes. [09:30] TheMue, is there some problem with using a string representation of a UUID as you've already implemented it? [09:30] rogpeppe: yeah, i don't have a better word. just a direct translation. ;) an identifier that contains useful informations. [09:31] fwereade: see my comments above. i think it would be nice if our environment identifiers at least identified themselves as environments [09:31] fwereade: please see the discussion above. not technologically, but rogpeppe correctly mentioned, that a regular one doesn't contain helpful informations. [09:32] fwereade: BTW it would be wrong, i think to use the UUID as the key in the environment collection. [09:33] 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] (5) that came from a UUID in the "standard" way [09:33] (6) unless there's some concern about ambiguity [09:33] rogpeppe, expand please [09:34] fwereade: it means that only way to find out the uuid is by listing all items in that collection. [09:34] fwereade: which may in the future contain more items [09:34] 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] rogpeppe, if it contains more items, you'll be accessing it via an environment-specific state connection, won't you? [09:35] TheMue, some charms want to use it, I'm afraid I don't know the detailed use case [09:35] fwereade: it seems odd to use a key that you can't know in advance. [09:35] TheMue, also, landscape wants to be able to identify environments [09:36] fwereade: ok, and today it is a v4 uuid (in th epy code). [09:36] TheMue, and that is a fine thing, and it's convenient to represent it as a string in our case [09:36] TheMue, do they not store it as a string in python? [09:36] TheMue, *surely* that's the convenient representation for yaml-in-zk? [09:37] 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] fwereade: have to look, the generate it with an external package imho. [09:37] TheMue, python is irrelevant really anyway [09:37] fwereade: i think an "environment uuid" can reasonably look different from other kinds of uuid [09:38] 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] 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:39] fwereade: and that an env-uuid would be a very useful thing to see in log files. [09:39] TheMue, ISTM that we are doing it when needed ;) [09:40] fwereade: due to database client reasons, but ok. :D [09:40] fwereade: it's really an *environment id* we're talking about here [09:40] rogpeppe, agreed -- but the UUID is unique, and no other aspect of an environment necessarily is [09:40] fwereade: which we need to be globally unique [09:40] fwereade: eh, btw, as slice there's no problem. really strange. [09:40] TheMue: your Copy and Raw code is a bit dubious BTW [09:41] TheMue: both of them do exactly the same thing [09:41] rogpeppe, if we're dealing with lots of environments, we'll be identifying them by uuid [09:41] rogpeppe, surely? [09:41] fwereade: yes, but if there are lots of uuids flying around, it would be nice to know which ones refer to juju environments [09:42] fwereade: surely what? [09:42] rogpeppe: only different return types. [09:42] TheMue: Copy is redundant. [09:42] TheMue: uuid1 := uuid [09:42] TheMue: does the same [09:42] rogpeppe, ha, hadn't spotted that [09:42] TheMue: Raw can be just return [16]byte(uuid) [09:43] rogpeppe: came from a uuid being a slice first and indeed has to be changed, yes. thanks. [09:43] rogpeppe, TheMue: weren't we just going to drop the type and return a string? [09:43] fwereade: yeah, just saying for future reference. [09:44] rogpeppe, TheMue: heh, I didn't know you could just "cat /proc/sys/kernel/random/uuid" [09:44] fwereade: any problem with keeping the type but adding a function NewUUIDString() string? [09:44] i'd prefer to see something like juju-24e5f46753 [09:44] fwereade: cool [09:44] fwereade: there are many ways. [09:45] fwereade: that's a bit bigger than our 16 bytes :-) [09:45] rogpeppe, what sort of context are you concerned about? [09:45] rogpeppe: how would the juju-prefix help? [09:45] TheMue: it would say "this string of random hex bytes means something in the context of juju" [09:46] rogpeppe, huh? it just gives you a string representation, like we're discussing [09:46] rogpeppe, I don't see the use case there [09:46] * TheMue neither [09:46] fwereade: we're talking about a name for something [09:46] fwereade: it's nice if names have some meaningful information in them, i think [09:47] rogpeppe: no, the name is the name, the uuid is simply an identifier. [09:47]