[00:16] if anyone can give me some insight here, it would be really helpful [00:16] http://paste.ubuntu.com/7569460/ [00:17] the value is being retrieved from the db, after being serialized into it from a nested map[interface{}]interface{} [00:20] the bit responsible for writing it to the db is here: http://bazaar.launchpad.net/~binary132/juju-core/charm-interface-actions/view/head:/state/state.go#L511 [00:24] this bit in particular threw me for a loop: [00:24] map[string]interface {}{"":"foo.bz2"} [00:24] it seems like perhaps it needs to be coerced to a map[interface{}]interface{} when being serialized? === vladk|offline is now known as vladk [05:54] morning all [05:55] hi [05:56] quiet today with nz folks missing and andrew [05:57] wallyworld: I thought you were sick [05:57] I mean, I know you're always *sick*, but I thought you were sick-sick today :) [05:58] jam: i am. so i'm a little slower [05:58] I just didn't expect you to be hanging out in IRC during your recovery [05:58] well, there's lots to get done [05:59] the github cutover has been on my mind - i need to catch up with martin a bit later [06:00] wallyworld: did I miss the doc which describes how we're actually going to land things? [06:00] jam: no, still wip, will be out today [06:03] jam: morning [06:03] morning vladk, just switching to the hangout now [06:18] morning all [06:23] morning [06:57] wallyworld: just thinking about it, is the intent to get 1.18 into github as well? [06:57] or are we just doing trunk and future releases? [06:58] dimitern: morning. I'm around if you're up for starting our 1:1 a bit early [06:58] jam: sec, otp will talk soon [06:59] wallyworld: also, just to queue up things, we are failing to just bump the version to 1.19.4, https://code.launchpad.net/~sinzui/juju-core/inc-1.19.4/+merge/221570 [06:59] any ideas there? [07:06] jam, i'm here, we can finish earlier as well === rogpeppe1 is now known as rogpeppe [07:41] jam: sorry, was dealing with a crisis at home. there were no plans o do 1.18 as well, just trunk onwards === vladk is now known as vladk|offline [07:42] jam: saw the 1.19.4 bug. there were 2 raised, one about tools on utopic and failing tests. i fixed that one but was delaying the 1.19.4 one till i talked to tim [07:46] jam: with the ec2 root disk fix, i was hoping that since 1.20 was out soon, we could not worry about 1.18. but can do 1.18 if needed [08:10] wallyworld: I believe 1.18 is going to be the version we can get into trusty for quite some time [08:10] so it is stays quite relevant [08:10] jam: ok, i'll bACKPORT [08:11] bloody capslock === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === vladk|offline is now known as vladk [08:39] morning all [08:47] voidspace: morning [08:56] morning voidspace [09:00] wallyworld: are you feeling up to standup? [09:00] sure [09:00] sorry, was just finishing dinner :-) [09:00] mgz, wallyworld: as long as he can do it laying flat on his back [09:01] was worried you might be ill in bed till I saw you chatting with jam earlier :) [09:02] WTF is github.com/binary132/gojsonschema ?? [09:02] are we adding random github dependencies now just like that? [09:03] I though we're supposed to bring/fork third parties into github.com/juju/ when using them? [09:04] dimitern: we can move it into juju [09:04] mgz, there should be some agreement and a policy how to deal with these [09:12] dimitern: mgz: fwiw, I'd rather link upstream as much as we can and use dependencies.tsv to ensure their correctness, rather than fork things and not give "credit" to upstream authors. [09:14] jam, and fork if the upstream breaks our stuff? [09:15] dimitern: well again, we're pinned to an exact rev [09:15] with deps [09:15] but yes, if they are egregious, then we fork [09:19] ah, right [09:23] dimitern: we all have actual copies of the history because of how git works, so if they ever just get deleted, we can always recreate them [09:27] jam, modern technology hey :) [09:30] so, this is already an our-fork of the project as bodie needed to fix stuff, but I'm also happy with it being in his namespace due to the wonders of dvcs [09:32] fwereade, jam, vladk, networks= constraint only https://codereview.appspot.com/93670046 as requested (cmd/juju changes in a follow-up) [09:32] please take a look [09:35] jam, mgz, can you rename a branch and repropose it as new? [09:37] dimitern: you caaan... [09:37] easiest just to push from old location to new [09:38] mgz, but how about the working dir? what bzr commands to use? [09:39] dimitern: which of the methods are you using? [09:39] probably just when on that branch, `bzr switch -b new_name; bzr rmbranch old_name` [09:39] mgz, hmm.. will it keep my pipeline intact? [09:40] dimitern: that is a good question I am not willing to answer :) [09:40] find aaron :) [09:40] mgz, ok, i'll just stick with the obsolete name then :) too much trouble [09:53] I'd love a go debugger right now [09:56] voidspace, have you checked this http://golang.org/doc/gdb ? [09:58] dimitern: I haven't [09:59] dimitern: hmmm === vladk is now known as vladk|offline [10:46] vladk|offline: standup? === vladk|offline is now known as vladk [10:47] vladk: welcome back. Standup? [10:47] ah, that foxed me - replicaset Initiate logging is going to cloud-init.log not all-machines.log [10:48] voidspace: ah, because it is driven by "jujud bootstrap-state" ? [10:49] jam: something like that (I wasn't aware of bootstrap-state specifically) [10:49] jam: it's setting up the mongo server, so I guess it's needed before jujud can do *anything useful* [10:49] yeah, though I wouldn't be terribly miffed if it also logged to machine-0.log which would get it into all-machines.log [10:50] right [10:50] it would have saved me twenty minutes of working out why my logging didn't appear to do anything :-) [10:56] good morning everyone [10:56] perrito666: morning [10:56] morning perrito666 [11:06] so, on my local machine it is 9 seconds after Initiate that replSetStatus is able to return a successful status [11:10] jam: so you made my sunday interesting with your email :p [11:12] might as well keep every day exciting, why should weekends be different [11:13] perrito666: ^^ :) [11:13] whereas asking for the config returns immediately even if initiate is still in process - I wonder if that can still be slower on some machines === vladk is now known as vladk|offline [11:14] jam: I was reasonably far from a computer irc-able :p I had my head on that the rest of the day :p [11:14] fwereade, when you have 15m today me and vladk (possibly jam as well) want to have a quick g+ with you re what networking-related stuff to add to hardwareCharateristics (if any) [11:15] dimitern, I think I can do that now if you're free [11:17] dimitern, I'm not sure if it's going to be the hc *document* itself -- mainly because I worry that network capabilities are potentially mutable, or at least more so than "normal" hc, although what happens when someone hot-swaps hardware? [11:17] https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ? [11:18] dimitern, nonetheless I think what we need to store is "all *accessible* networks" [11:20] dimitern: vladk|offline: care to join us? === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [11:29] jam: lemme know when you are free for a moment please, so we can have a chat re the issue of localhost bein priorized [11:31] anyone care to do a fairly trivial review, factoring some logsuite functionality out of juju-core? https://github.com/juju/testing/pull/8/files [11:34] perrito666: I seem to have abit of time while this meeting comes together [11:34] what's up? [11:35] well, I read all of your comments, your main concern seems to be that I might (and most likely will) break the order of the addresses which are not localhost, right?ç [11:36] right [11:37] seems like the answer is not to sort, just extract localhost from the slice if it exists and connect there first [11:37] since sort.sort is not stable [11:37] yeah [11:38] the fun thing here is, I had done just that to begin, but it looked uglier than sorting .. :) [11:38] I feel a little bit that if localhost is in the list, you shouldn't actually try to connect to anythingelse. [11:38] is there a reason we allow fallbacks ? [11:40] * perrito666 thinks [11:41] It made sense to me because I am the one adding localhost there in the first place (actually I might) but I see no reason why localhost should not work in that case, since I am using the set up port [11:43] it's a good point... we should probably only connect to localhost if it exists. [11:43] natefinch: it seems like just a good way to accidentally connect to something not localhost and then think that you're also a master, etc. [11:44] that's a very good point [11:44] I wonder, is it possible for that list to contain more than one localhost? [11:44] localhost address that is [11:45] with different ports? Shouldn't be [11:47] ok then, refactor it is... how do I handle re-proposing someting? [11:47] perrito666: don't, start a new branch [11:47] jam: ok [11:47] have you merged it already? [11:49] natefinch: yup, I fixed your and waynes suggestions and that gave me a couple of lgtms [11:49] natefinch: morning [11:49] natefinch: care to take a look at this [11:50] natefinch: https://codereview.appspot.com/104800043 [11:50] this waits for *up to* five seconds for a successful replicaset config - even if the Initiate call errors out [11:50] perrito666: that's totally fine... just was going to say that if you hadn't merged it, you could edit on the branch, but since you have, just make a new branch with the fix [11:50] natefinch: on my machine it can take 9 seconds before we get a successful *status* after calling Initiate [11:51] which is why I went with config - because waiting for status would slow down cloud-init on all machines [11:51] (state servers) [11:51] on the other hand they can't do anything useful until the replica set is fully initiatlized, so maybe it doesn't matter [11:51] *wouldn't matter [11:52] voidspace: won't this only wait a max of 5 seconds, though? [11:52] natefinch: I'm waiting for config not for status [11:52] natefinch: I didn't wait for status because that would take longer [11:52] oh right, ok [11:52] if this doesn't work then maybe we need to wait for status [11:52] and if that doesn't work I suggest giving up for now... [11:54] natefinch: all tests pass with this change [11:55] voidspace: didnt all test pass without it too? (in machines other than CI) [11:55] perrito666: yes... what I mean is that I have run all the tests to check I didn't break anything... [11:56] perrito666: well, didn't break anything covered by tests anyway [12:03] * voidspace lunch [12:18] natefinch: did you want to do a catchup 1:1 now? [12:19] fwereade, cheers, thanks [12:20] jam: I'm probably going to get interrupted any minute, so probably not. We should probably reschedule this in general to a couple hours earlier when I'm more likely to be baby free [12:20] dimitern, voidspace, natefinch, jam, fwereade: any chance of a review of this, please? i've got a juju-core branch waiting on it. https://github.com/juju/testing/pull/8/files [12:21] well, I had 1hr ago free, but you weren't online yet, (after our standup, so not guaranteed), but I also have a gap 2 hours earlier if you can make that time [12:21] 2 hours earlier is fine, I'm usually online then, just sometimes hiding ;) [12:22] rogpeppe: I thought splitting something out into juju/$PACKAGE meant that it should actually be independent of juju core stuff [12:22] it feels odd to have JUJU_LOGGING_CONFIG in there [12:22] jam: i wondered about that [12:23] jam: i figured JUJU doesn't necessarily imply juju-core [12:23] jam: and it is in juju/testing [12:23] jam: but i'm happy to rename it anything you choose :-) [12:24] So at least, my understanding was that stuff under "github.com/juju/*" should hopefully be applicable to 3rd parties that want to use them, otherwise why split it out [12:24] though I realize the new store changes will be something that is still very Juju related that wants a separate copy [12:24] TEST_LOGGING_CONFIG seems a good fit, though. [12:29] jam: ok, TEST_LOGGING_CONFIG it is === vladk is now known as vladk|offline [12:35] dimitern: have you had any chance to think about ipv6 stuff ? [12:35] that sounds like work that we need to be scoping early this week. [12:36] jam, dimitern: +1 to that [12:43] jam, i'm reading the wiki today as i code [12:43] jam, sgtm, i'll have more insight tomorrow i guess === vladk|offline is now known as vladk [13:36] another fairly trivial review, please; update golxc to avoid using the (now deleted) testing/logging package: https://codereview.appspot.com/103780043 [13:36] dimitern, jam, voidspace, fwereade: ^ [13:36] I thought golxc already had thta [13:37] rogpeppe: rev 9 of golxc has "Replace LoggingSuite with IsolationSuite" [13:38] jam: oh [13:38] jam: i guess i didn't try bzr pull [13:40] jam: thanks [13:43] fwereade: so mocking CurrentConfig directly isn't possible [13:43] fwereade: I assume you want me to add an extra level of indirection to make it testable [13:44] further complicated by the fact that *all* replicaset tests Initiate already [13:44] but I can workaround that [14:01] fwereade: replicaset_test.go is already a whitebox test (in the replicaset package) [14:01] fwereade: so ok to just use: var getCurrentConfig = CurrentConfig [14:01] fwereade: to permit mocking? [14:01] voidspace, works for me [14:02] fwereade: cool, reproprosing shortly [14:02] voidspace: yeah (you'll find most of my tests are in the same package as the stuff they're testing) [14:02] voidspace: standup [14:02] voidspace: omw [14:17] vladk, reviewed [14:18] fwereade, a quick look at https://codereview.appspot.com/93670046/ - network constraints? [14:18] dimitern, I'm in meeting mode for the rest of the pm, make sure perrito666 takes a look, I will try to swing by and add my opinions in the evening [14:19] fwereade, ok, sure [14:19] perrito666, PTAL then ^^ :) [14:20] dimitern: looking === andreas__ is now known as ahasenack [14:24] perrito666, thanks [14:24] dimitern: I am sure you have a very good reason for it, but why ^? :) [14:25] perrito666, ;) [14:25] perrito666, for the CL or for the "thanks" ? [14:25] dimitern: for the use of "^" [14:26] perrito666, ah, sorry - I meant "look at the previous lines" [14:27] dimitern: I meant for the ^ as the "exclude" prefix [14:27] perrito666, or you mean in constraints? someone suggested to use it instead of "!" to play nice with bash === vladk is now known as vladk|offline [14:30] dimitern: I think the ideal would be "-" but that would break anything most likely [14:34] perrito666, yes, we use "-" in tags [14:37] anyone have some input on how to properly serialize a nested map[interface{}]interface{}? [14:37] I think it's serializing as {"":"foo.bz2"} instead of the full map, though I could be retrieving it wrong [14:38] er, for use with mongo [14:39] if not, I'll just head to the documentation, but if there's a quick answer to short-circuit that, it would be much appreciated [14:41] bodie_: not sure why it's not serializing correctly. However, I'm wondering why you have a map with interface{} as keys? [14:42] well, the top level is a map[string]interface{} -- however, the depth of that map is unknown until runtime, at which point it's deserialized from YAML [14:42] therefore, since the values (of type interface{}) can themselves be keys of a deeper map... [14:43] you end up with a map[i{}]i{} [14:45] I sort of understand....sort of [14:46] natefinch, the actionspecs key here has a list of values, which are themselves keys [14:46] https://codereview.appspot.com/94540044 [14:47] I mean uhh... maps [14:47] the values are maps [14:47] which contain keys with maps as values [14:47] so it's not as complicated looking as it sounds [14:48] but, I'm not seeing how to coerce it into a usable format for bson serialization [14:48] dimitern: I reviewed your patch, sorry if the commends sound harsh, I lack a bit of polite English, read them as if I was saying them with a smile [14:48] bbiab [14:49] bodie_: I'm just worried that if you make map[interface{}] then people can put stuff in the value that isn't a valid map key.... like another map [14:49] which will only blow up at runtime [14:49] yeah, that's probably why it doesn't work, heh [14:49] http://play.golang.org/p/mk3tZ4NCUF [14:49] I've been pushing for us to make it a map[string]JsonSchemaDoc or simply map[string]string and serialize to JSON-Schema at runtime [14:50] because, we DO know that the values are serializable to J-S-docs, we check that at time of deserialization [14:50] bodie_, natefinch even without that, I still don't see any place where the key has to be an interface{} [14:50] (so that probably also answers your question -- we do a validity check immediately after deserializing from YAML) [14:50] the keys, AFAICT, are always string [14:51] the keys are, yes, but the values themselves can be maps [14:51] with string keys [14:51] right, but that means you should have map[string]interface{} [14:51] right, so where does map[interface{}]interface{} come from? [14:51] the top level is map[string]interface{} because it could have values which are themselves maps [14:52] right, [14:52] so, those are of type interface{} as far as we know [14:52] any value with a map type would still be map[string]interace{} [14:52] but they could be the keys of maps [14:52] okay [14:52] but if they're a key, they're a string, so you can convert them to a string first [14:53] no, the value would be a map[string]interface{} [14:53] not a list of keys [14:53] right [14:54] bodie_: there's never a time that there will be a value of type map[interface{}]interface{} [14:55] bodie_: it will be an interface{} until you figure out if its a map, in which case you'd cast it to a map[string]interface{} [14:57] okay, which means that when I serialize it, I need to step through the top-level map recursively re-casting its children into map[string]interface{}'s if they are such? [14:57] and then iterating into them [14:58] bodie_: hmm, actually I think when you serialize them it takes care of that... [14:58] that's what I thought, too.... :) [14:58] most of this stuff should be taken care of for you [14:59] right, I'm sure I'm just missing some detail [14:59] perrito666, thanks [14:59] bodie_: looking at that MR I would first change all your map[interface{}]interface{} lines to map[string]interface{} [14:59] can anyone remember the usual dance for updating a dependency in the 'bot? [14:59] bodie_: then starting from there we can figure out other serialization issues [15:02] looks like this technique (map[interface{}]interface{}) is already being used in several other place [15:02] s* [15:02] charm/meta [15:04] if other people jumped off a bridge, would you? ;) [15:04] hehe [15:05] here we are [15:05] http://paste.ubuntu.com/7573584/ [15:05] so, "outfile" is a map[string]interface{} [15:06] I conformed my test to the obtained result, but maybe that's where I need to look closer [15:07] http://paste.ubuntu.com/7573598/ [15:08] so, this is being deserialized by goyaml in this function: http://bazaar.launchpad.net/~binary132/juju-core/charm-interface-actions/view/head:/charm/actions.go#L37 [15:08] "ReadActionsYaml" [15:08] natefinch, jam, fwereade : CI is blocked by https://bugs.launchpad.net/juju-core/+bug/1325074 [15:08] <_mup_> Bug #1325074: Juju version cannot be set to 1.19.4

[15:09] ^ the test suite knows we cannot replace a published version of juju. So when devel gets updates, 1.19.3 is built, it is rejected because 1.19.3 really exists. [15:10] The unit tests are not affected by this, just the substrate and function tests [15:11] bodie_: is this code all pushed up to your branch? [15:11] yeah [15:12] lp:binary132/juju-core/charm-interface-actions [15:12] bodie_: so, you're seeing that the goyaml deserializer is returning a type map[interface{}]interface{} ? [15:12] that appears to be what's happening, yeah [15:14] I think I should have caught this before it hit the DB -- I think adding an extra check to charm_test might help, here [15:15] bodie_: before it hit the DB? [15:16] right, my issue was that I was retrieving an unexpected from the database [15:16] instead of a map [15:17] bodie_: hmm, I didn't see any mongo access in that MR, do you mean Charm YAML? [15:18] I added some stuff to state/State.AddCharm [15:18] just a minor bit for including ch.Actions() in the cdoc [15:18] bodie_: oh, in a previous MR? [15:18] no, in charm-interface-actions [15:18] http://bazaar.launchpad.net/~binary132/juju-core/charm-interface-actions/view/head:/state/state.go#L511 [15:19] bodie_: hmm, not in the MR then okay.. I was looking there while I was waiting for the branch [15:20] https://code.launchpad.net/~binary132/juju-core/charm-interface-actions/+merge/221595 line 351? [15:20] or uh, right, the MR [15:20] https://codereview.appspot.com/99640044/patch/20001/30015 [15:21] no biggie [15:21] anyway, I think I can catch it before that in charm_test [15:22] pushing up a change [15:22] bodie_: yeah. Which test is failing in your branch though... I'm not seeing the error you pasted [15:23] bodie_: (doh) forgot to switch branches [15:24] that revision probably has its own problems, I just pushed the test breakage back into the charm package [15:24] https://codereview.appspot.com/99640044 [15:27] bodie_: so when you use map[interface{}]interface{} in the test it passes... [15:27] right [15:27] bodie_: where is the issue outside the test when you use that? [15:28] state/charm_test/TestCharm line 53 [15:29] 54* [15:33] the error is now charm/charm_test.go:77: invalid operation: f.Actions().ActionSpecs["snapshot"].Params["outfile"]["description"] (index of type interface {}) [15:33] Params is a map[string]interface{} [15:33] bodie_: i see [15:33] so, I need to cast it before checking, I suppose [15:40] Panic: interface conversion: interface is map[interface {}]interface {}, not map[string]interface {} [15:40] I'm still of the opinion that storing the JsonSchemaDocs as raw strings would be much simpler [15:41] bodie_: yeah, that's an mgz and fwereade discussion. [15:41] yep [16:03] fwereade: natefinch: mp updated [16:03] https://code.launchpad.net/~mfoord/juju-core/slow-replset/+merge/221709 [16:04] fwereade: natefinch: still waiting for lbox to do it's thing for the CL to update [16:04] fwereade: note that after discussion with natefinch we switched to waiting for a successful replicaset status check rather than a config check [16:04] this is slightly slower, but safer and more likely to actually fix the CI problem [16:07] and CL updated too [16:07] https://codereview.appspot.com/104800043 === hatch__ is now known as hatch [16:24] voidspace: LGTM [16:28] natefinch: cool, let's land it and see if it fixes the problem [16:28] natefinch: if not I suggest we back it out because of the extra slowdown it causes === vladk|offline is now known as vladk [16:36] back [16:37] natefinch: I'm hoping this change makes replicasets more reliable for tests too [16:37] natefinch: trying it now [16:38] natefinch: hmmm... well, a bit more reliable [16:38] natefinch: still some panics [16:39] fwereade: do you have github permissions to creat juju/core? [16:39] I seem not to. [16:40] huh, I think you should [16:40] mgz, what description would you like? :) [16:41] "Preliminary version, do not use yet" (I assume we can change that tomorrow :) [16:42] mgz, created :) [16:42] thanks! [16:42] * fwereade has to go to the shops, bbiab, maybe [16:50] sinzui: can you kick of a precise-amd64 bootstrap test [16:50] sinzui: the last run was revision 2814 [16:50] http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/ [16:50] voidspace, no [16:50] sinzui: is this the build problem you emailed about? [16:51] voidspace, since the juju version was not updated to 1.19.4, it is not possible to test new revisions [16:51] sinzui: right :-/ [16:51] wohttps://bugs.launchpad.net/juju-core/+bug/1325074 [16:51] <_mup_> Bug #1325074: Juju version cannot be set to 1.19.4

[16:51] sinzui: we think we might have fixed the precise problem, we'll have to wait to see I guess [16:51] voidspace, I honstley have been trying. I in in a utopic instance right now forcing the build steps to give me something to test [16:52] sinzui: :-( [16:52] is anyone looking at this? [16:52] I'm ten minutes before EOD I'm afraid [16:52] and it's krav maga tonight [16:52] voidspace, I don't think anyone is, sorry [16:53] voidspace, I have talked to a few devs, but no one has a clue [16:54] * sinzui ponders the consequences of hacking the juju version just before the tarball is built [16:55] * sinzui think unit tests fail (good), but substrate tests will run [16:58] mgz: can we just call it "juju"? [17:03] right, off to krav maga [17:03] probably back on later though [17:03] see you all [17:03] EOD [17:03] natefinch: wha? [17:04] I was told core. There was a thread a while back and I thought that was the outcome of it. [17:19] mgz: hmm, I must have missed that thread [17:40] hazmat, jam I'm going to tackle LP: #1183309, per https://bugs.launchpad.net/juju-core/+bug/1183309/comments/7. sound good? [17:40] <_mup_> Bug #1183309: destroy-service should have a force option

[17:40] <_mup_> Bug #1183309: destroy-service should have a force option

[17:41] cmars: make sure you sync with fwereade because he felt destroy-service —force was a Won't Fix [17:41] jam, will do, thanks [17:49] bodie_: so bson (mgo\bson) doesn't know how to serialize map[interface{}]interface{} [17:49] I figured that was it [17:50] so I guess we need to look at how gojsonschema is representing it in memory [17:50] I think it does a recursion [17:50] in fact I'm certain it does [17:50] well our tests indicated it was map[interface{}]interface{}... we know that Params will be a map[string](map[string]string) [17:51] that's not necessarily true [17:51] first of all, Params can definitely have simple string values [17:51] http://paste.ubuntu.com/7574011/ [17:51] jcw4: it seems like you should be able to write a pretty simple function that takes your map[string]interface{} and gives back usable bson [17:52] secondly, it could have more deeply nested maps [17:52] bodie_: so Params is 100% free form, constrained only by a jsonschema? [17:52] mgz: map[string]interface{} is okay with bson [17:52] it's map[interface{}]interface{} that bson chokes on [17:53] well, taking that then [17:53] mgz, do you know offhand whether encoding/json can? [17:54] cause if we can encode it as a JSON literal, it should be simple to transform that into a bson literal suitable for direct storage [17:54] without having to store the raw string [17:55] but, I guess jcw4 is on the money with the assessment that the interface{} keys are the issue [17:55] play.golang.org can't do imports... [17:56] william mentioned we could use juju/schema to enforce String or MapString types [17:56] s/MapString/stringMap [17:56] http://paste.ubunut.com/7574595 [17:56] http://paste.ubuntu.com/7574595 damnig [17:57] perrito666: thanks for the review [17:57]