[00:16] <bodie_> if anyone can give me some insight here, it would be really helpful
[00:16] <bodie_> http://paste.ubuntu.com/7569460/
[00:17] <bodie_> the value is being retrieved from the db, after being serialized into it from a nested map[interface{}]interface{}
[00:20] <bodie_> 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] <bodie_> this bit in particular threw me for a loop:
[00:24] <bodie_> map[string]interface {}{"<interface {} Value>":"foo.bz2"}
[00:24] <bodie_> it seems like perhaps it needs to be coerced to a map[interface{}]interface{} when being serialized?
[05:54] <jam> morning all
[05:55] <wallyworld> hi
[05:56] <wallyworld> quiet today with nz folks missing and andrew
[05:57] <jam> wallyworld: I thought you were sick
[05:57] <jam> I mean, I know you're always *sick*, but I thought you were sick-sick today :)
[05:58] <wallyworld> jam: i am. so i'm a little slower
[05:58] <jam> I just didn't expect you to be hanging out in IRC during your recovery
[05:58] <wallyworld> well, there's lots to get done
[05:59] <wallyworld> the github cutover has been on my mind  - i need to catch up with martin a bit later
[06:00] <jam> wallyworld: did I miss the doc which describes how we're actually going to land things?
[06:00] <wallyworld> jam: no, still wip, will be out today
[06:03] <vladk> jam: morning
[06:03] <jam> morning vladk, just switching to the hangout now
[06:18] <dimitern> morning all
[06:23] <wallyworld> morning
[06:57] <jam> wallyworld: just thinking about it, is the intent to get 1.18 into github as well?
[06:57] <jam> or are we just doing trunk and future releases?
[06:58] <jam> dimitern: morning. I'm around if you're up for starting our 1:1 a bit early
[06:58] <wallyworld> jam: sec, otp will talk soon
[06:59] <jam> 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] <jam> any ideas there?
[07:06] <dimitern> jam, i'm here, we can finish earlier as well
[07:41] <wallyworld> jam: sorry, was dealing with a crisis at home. there were no plans o do 1.18 as well, just trunk onwards
[07:42] <wallyworld> 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] <wallyworld> 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] <jam> wallyworld: I believe 1.18 is going to be the version we can get into trusty for quite some time
[08:10] <jam> so it is stays quite relevant
[08:10] <wallyworld> jam: ok, i'll bACKPORT
[08:11] <wallyworld> bloody capslock
[08:39] <voidspace> morning all
[08:47] <TheMue> voidspace: morning
[08:56] <jam> morning voidspace
[09:00] <mgz> wallyworld: are you feeling up to standup?
[09:00] <wallyworld> sure
[09:00] <wallyworld> sorry, was just finishing dinner :-)
[09:00] <jam> mgz, wallyworld: as long as he can do it laying flat on his back
[09:01] <mgz> was worried you might be ill in bed till I saw you chatting with jam earlier :)
[09:02] <dimitern> WTF is github.com/binary132/gojsonschema ??
[09:02] <dimitern> are we adding random github dependencies now just like that?
[09:03] <dimitern> I though we're supposed to bring/fork third parties into github.com/juju/ when using them?
[09:04] <mgz> dimitern: we can move it into juju
[09:04] <dimitern> mgz, there should be some agreement and a policy how to deal with these
[09:12] <jam> 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] <dimitern> jam, and fork if the upstream breaks our stuff?
[09:15] <jam> dimitern: well again, we're pinned to an exact rev
[09:15] <jam> with deps
[09:15] <jam> but yes, if they are egregious, then we fork
[09:19] <dimitern> ah, right
[09:23] <jam> 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] <dimitern> jam, modern technology hey :)
[09:30] <mgz> 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] <dimitern> fwereade, jam, vladk, networks= constraint only https://codereview.appspot.com/93670046 as requested (cmd/juju changes in a follow-up)
[09:32] <dimitern> please take a look
[09:35] <dimitern> jam, mgz, can you rename a branch and repropose it as new?
[09:37] <mgz> dimitern: you caaan...
[09:37] <mgz> easiest just to push from old location to new
[09:38] <dimitern> mgz, but how about the working dir? what bzr commands to use?
[09:39] <mgz> dimitern: which of the methods are you using?
[09:39] <mgz> probably just when on that branch, `bzr switch -b new_name; bzr rmbranch old_name`
[09:39] <dimitern> mgz, hmm.. will it keep my pipeline intact?
[09:40] <mgz> dimitern: that is a good question I am not willing to answer :)
[09:40] <mgz> find aaron :)
[09:40] <dimitern> mgz, ok, i'll just stick with the obsolete name then :) too much trouble
[09:53] <voidspace> I'd love a go debugger right now
[09:56] <dimitern> voidspace, have you checked this http://golang.org/doc/gdb ?
[09:58] <voidspace> dimitern: I haven't
[09:59] <voidspace> dimitern: hmmm
[10:46] <jam> vladk|offline: standup?
[10:47] <jam> vladk: welcome back. Standup?
[10:47] <voidspace> ah, that foxed me - replicaset Initiate logging is going to cloud-init.log not all-machines.log
[10:48] <jam> voidspace: ah, because it is driven by "jujud bootstrap-state" ?
[10:49] <voidspace> jam: something like that (I wasn't aware of bootstrap-state specifically)
[10:49] <voidspace> jam: it's setting up the mongo server, so I guess it's needed before jujud can do *anything useful*
[10:49] <jam> 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] <voidspace> right
[10:50] <voidspace> it would have saved me twenty minutes of working out why my logging didn't appear to do anything :-)
[10:56] <perrito666> good morning everyone
[10:56] <voidspace> perrito666: morning
[10:56] <jam> morning perrito666
[11:06] <voidspace> so, on my local machine it is 9 seconds after Initiate that replSetStatus is able to return a successful status
[11:10] <perrito666> jam: so you made my sunday interesting with your email :p
[11:12] <jam> might as well keep every day exciting, why should weekends be different
[11:13] <jam> perrito666: ^^ :)
[11:13] <voidspace> 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
[11:14] <perrito666> 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] <dimitern> 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] <fwereade> dimitern, I think I can do that now if you're free
[11:17] <fwereade> 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] <jam> https://plus.google.com/hangouts/_/canonical.com/juju-sapphire ?
[11:18] <fwereade> dimitern, nonetheless I think what we need to store is "all *accessible* networks"
[11:20] <jam> dimitern: vladk|offline: care to join us?
[11:29] <perrito666> 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] <rogpeppe> 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] <jam> perrito666: I seem to have abit of time while this meeting comes together
[11:34] <jam> what's up?
[11:35] <perrito666> 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] <jam> right
[11:37] <natefinch> seems like the answer is not to sort, just extract localhost from the slice if it exists and connect there first
[11:37] <jam> since sort.sort is not stable
[11:37] <jam> yeah
[11:38] <perrito666> the fun thing here is, I had done just that to begin, but it looked uglier than sorting .. :)
[11:38] <jam> I feel a little bit that if localhost is in the list, you shouldn't actually try to connect to anythingelse.
[11:38] <jam> is there a reason we allow fallbacks ?
[11:40]  * perrito666 thinks
[11:41] <perrito666> 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] <natefinch> it's a good point... we should probably only connect to localhost if it exists.
[11:43] <jam> 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] <natefinch> that's a very good point
[11:44] <perrito666> I wonder, is it possible for that list to contain more than one localhost?
[11:44] <perrito666> localhost address that is
[11:45] <natefinch> with different ports?   Shouldn't be
[11:47] <perrito666> ok then, refactor it is... how do I handle re-proposing someting?
[11:47] <jam> perrito666: don't, start a new branch
[11:47] <perrito666> jam: ok
[11:47] <natefinch> have you merged it already?
[11:49] <perrito666> natefinch: yup, I fixed your and waynes suggestions and that gave me a couple of lgtms
[11:49] <voidspace> natefinch: morning
[11:49] <voidspace> natefinch: care to take a look at this
[11:50] <voidspace> natefinch: https://codereview.appspot.com/104800043
[11:50] <voidspace> this waits for *up to* five seconds for a successful replicaset config - even if the Initiate call errors out
[11:50] <natefinch> 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] <voidspace> natefinch: on my machine it can take 9 seconds before we get a successful *status* after calling Initiate
[11:51] <voidspace> which is why I went with config - because waiting for status would slow down cloud-init on all machines
[11:51] <voidspace> (state servers)
[11:51] <voidspace> 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] <voidspace> *wouldn't matter
[11:52] <natefinch> voidspace: won't this only wait a max of 5 seconds, though?
[11:52] <voidspace> natefinch: I'm waiting for config not for status
[11:52] <voidspace> natefinch: I didn't wait for status because that would take longer
[11:52] <natefinch> oh right, ok
[11:52] <voidspace> if this doesn't work then maybe we need to wait for status
[11:52] <voidspace> and if that doesn't work I suggest giving up for now...
[11:54] <voidspace> natefinch: all tests pass with this change
[11:55] <perrito666> voidspace: didnt all test pass without it too? (in machines other than CI)
[11:55] <voidspace> perrito666: yes... what I mean is that I have run all the tests to check I didn't break anything...
[11:56] <voidspace> perrito666: well, didn't break anything covered by tests anyway
[12:03]  * voidspace lunch
[12:18] <jam> natefinch: did you want to do a catchup 1:1 now?
[12:19] <dimitern> fwereade, cheers, thanks
[12:20] <natefinch> 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] <rogpeppe> 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] <jam> 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] <natefinch> 2 hours earlier is fine, I'm usually online then, just sometimes hiding ;)
[12:22] <jam> rogpeppe: I thought splitting something out into juju/$PACKAGE meant that it should actually be independent of juju core stuff
[12:22] <jam> it feels odd to have JUJU_LOGGING_CONFIG in there
[12:22] <rogpeppe> jam: i wondered about that
[12:23] <rogpeppe> jam: i figured JUJU doesn't necessarily imply juju-core
[12:23] <rogpeppe> jam: and it is in juju/testing
[12:23] <rogpeppe>  jam: but i'm happy to rename it anything you choose :-)
[12:24] <jam> 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] <jam> though I realize the new store changes will be something that is still very Juju related that wants a separate copy
[12:24] <jam> TEST_LOGGING_CONFIG seems a good fit, though.
[12:29] <rogpeppe> jam: ok, TEST_LOGGING_CONFIG it is
[12:35] <jam> dimitern: have you had any chance to think about ipv6 stuff ?
[12:35] <jam> that sounds like work that we need to be scoping early this week.
[12:36] <fwereade> jam, dimitern: +1 to that
[12:43] <dimitern> jam, i'm reading the wiki today as i code
[12:43] <dimitern> jam, sgtm, i'll have more insight tomorrow i guess
[13:36] <rogpeppe> another fairly trivial review, please; update golxc to avoid using the (now deleted) testing/logging package: https://codereview.appspot.com/103780043
[13:36] <rogpeppe> dimitern, jam, voidspace, fwereade: ^
[13:36] <jam> I thought golxc already had thta
[13:37] <jam> rogpeppe: rev 9 of golxc has "Replace LoggingSuite with IsolationSuite"
[13:38] <rogpeppe> jam: oh
[13:38] <rogpeppe> jam: i guess i didn't try bzr pull
[13:40] <rogpeppe> jam: thanks
[13:43] <voidspace> fwereade: so mocking CurrentConfig directly isn't possible
[13:43] <voidspace> fwereade: I assume you want me to add an extra level of indirection to make it testable
[13:44] <voidspace> further complicated by the fact that *all* replicaset tests Initiate already
[13:44] <voidspace> but I can workaround that
[14:01] <voidspace> fwereade: replicaset_test.go is already a whitebox test (in the replicaset package)
[14:01] <voidspace> fwereade: so ok to just use: var getCurrentConfig = CurrentConfig
[14:01] <voidspace> fwereade: to permit mocking?
[14:01] <fwereade> voidspace, works for me
[14:02] <voidspace> fwereade: cool, reproprosing shortly
[14:02] <natefinch> voidspace: yeah  (you'll find most of my tests are in the same package as the stuff they're testing)
[14:02] <natefinch> voidspace: standup
[14:02] <voidspace> voidspace: omw
[14:17] <dimitern> vladk, reviewed
[14:18] <dimitern> fwereade, a quick look at https://codereview.appspot.com/93670046/ - network constraints?
[14:18] <fwereade> 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] <dimitern> fwereade, ok, sure
[14:19] <dimitern> perrito666, PTAL then ^^ :)
[14:20] <perrito666> dimitern: looking
[14:24] <dimitern> perrito666, thanks
[14:24] <perrito666> dimitern: I am sure you have a very good reason for it, but why ^? :)
[14:25] <dimitern> perrito666, ;)
[14:25] <dimitern> perrito666, for the CL or for the "thanks" ?
[14:25] <perrito666> dimitern: for the use of "^"
[14:26] <dimitern> perrito666, ah, sorry - I meant "look at the previous lines"
[14:27] <perrito666> dimitern: I meant for the ^ as the "exclude" prefix
[14:27] <dimitern> perrito666, or you mean in constraints? someone suggested to use it instead of "!" to play nice with bash
[14:30] <perrito666> dimitern: I think the ideal would be "-" but that would break anything most likely
[14:34] <dimitern> perrito666, yes, we use "-" in tags
[14:37] <bodie_> anyone have some input on how to properly serialize a nested map[interface{}]interface{}?
[14:37] <bodie_> I think it's serializing as {"<interface {} Value>":"foo.bz2"} instead of the full map, though I could be retrieving it wrong
[14:38] <bodie_> er, for use with mongo
[14:39] <bodie_> 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] <natefinch> bodie_: not sure why it's not serializing correctly. However, I'm wondering why you have a map with interface{} as keys?
[14:42] <bodie_> 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] <bodie_> therefore, since the values (of type interface{}) can themselves be keys of a deeper map...
[14:43] <bodie_> you end up with a map[i{}]i{}
[14:45] <natefinch> I sort of understand....sort of
[14:46] <bodie_> natefinch, the actionspecs key here has a list of values, which are themselves keys
[14:46] <bodie_> https://codereview.appspot.com/94540044
[14:47] <bodie_> I mean uhh... maps
[14:47] <bodie_> the values are maps
[14:47] <bodie_> which contain keys with maps as values
[14:47] <bodie_> so it's not as complicated looking as it sounds
[14:48] <bodie_> but, I'm not seeing how to coerce it into a usable format for bson serialization
[14:48] <perrito666> 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] <perrito666> bbiab
[14:49] <natefinch> 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] <natefinch> which will only blow up at runtime
[14:49] <bodie_> yeah, that's probably why it doesn't work, heh
[14:49] <natefinch> http://play.golang.org/p/mk3tZ4NCUF
[14:49] <bodie_> 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] <bodie_> because, we DO know that the values are serializable to J-S-docs, we check that at time of deserialization
[14:50] <jcw4> bodie_, natefinch even without that, I still don't see any place where the key has to be an interface{}
[14:50] <bodie_> (so that probably also answers your question -- we do a validity check immediately after deserializing from YAML)
[14:50] <jcw4> the keys, AFAICT, are always string
[14:51] <bodie_> the keys are, yes, but the values themselves can be maps
[14:51] <bodie_> with string keys
[14:51] <natefinch> right, but that means you should have map[string]interface{}
[14:51] <jcw4> right, so where does map[interface{}]interface{} come from?
[14:51] <bodie_> the top level is map[string]interface{} because it could have values which are themselves maps
[14:52] <jcw4> right,
[14:52] <bodie_> so, those are of type interface{} as far as we know
[14:52] <jcw4> any value with a map type would still be map[string]interace{}
[14:52] <bodie_> but they could be the keys of maps
[14:52] <bodie_> okay
[14:52] <natefinch> but if they're a key, they're a string, so you can convert them to a string first
[14:53] <jcw4> no, the value would be a map[string]interface{}
[14:53] <jcw4> not a list of keys
[14:53] <bodie_> right
[14:54] <jcw4> bodie_: there's never a time that there will be a value of type map[interface{}]interface{}
[14:55] <jcw4> 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] <bodie_> 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] <bodie_> and then iterating into them
[14:58] <jcw4> bodie_: hmm, actually I think when you serialize them it takes care of that...
[14:58] <bodie_> that's what I thought, too.... :)
[14:58] <natefinch> most of this stuff should be taken care of for you
[14:59] <bodie_> right, I'm sure I'm just missing some detail
[14:59] <dimitern> perrito666, thanks
[14:59] <jcw4> bodie_: looking at that MR I would first change all your map[interface{}]interface{} lines to map[string]interface{}
[14:59] <rogpeppe> can anyone remember the usual dance for updating a dependency in the 'bot?
[14:59] <jcw4> bodie_: then starting from there we can figure out other serialization issues
[15:02] <bodie_> looks like this technique (map[interface{}]interface{}) is already being used in several other place
[15:02] <bodie_> s*
[15:02] <bodie_> charm/meta
[15:04] <natefinch> if other people jumped off a bridge, would you? ;)
[15:04] <bodie_> hehe
[15:05] <bodie_> here we are
[15:05] <bodie_> http://paste.ubuntu.com/7573584/
[15:05] <bodie_> so, "outfile" is a map[string]interface{}
[15:06] <bodie_> I conformed my test to the obtained result, but maybe that's where I need to look closer
[15:07] <bodie_> http://paste.ubuntu.com/7573598/
[15:08] <bodie_> 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] <bodie_> "ReadActionsYaml"
[15:08] <sinzui> 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 <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1325074>
[15:09] <sinzui> ^ 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] <sinzui> The unit tests are not affected by this, just the substrate and function tests
[15:11] <jcw4> bodie_: is this code all pushed up to your branch?
[15:11] <bodie_> yeah
[15:12] <bodie_> lp:binary132/juju-core/charm-interface-actions
[15:12] <jcw4> bodie_: so, you're seeing that the goyaml deserializer is returning a type map[interface{}]interface{} ?
[15:12] <bodie_> that appears to be what's happening, yeah
[15:14] <bodie_> 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] <jcw4> bodie_: before it hit the DB?
[15:16] <bodie_> right, my issue was that I was retrieving an unexpected <Value: ...> from the database
[15:16] <bodie_> instead of a map
[15:17] <jcw4> bodie_: hmm, I didn't see any mongo access in that MR, do you mean Charm YAML?
[15:18] <bodie_> I added some stuff to state/State.AddCharm
[15:18] <bodie_> just a minor bit for including ch.Actions() in the cdoc
[15:18] <jcw4> bodie_: oh, in a previous MR?
[15:18] <bodie_> no, in charm-interface-actions
[15:18] <bodie_> http://bazaar.launchpad.net/~binary132/juju-core/charm-interface-actions/view/head:/state/state.go#L511
[15:19] <jcw4> bodie_: hmm, not in the MR then okay..  I was looking there while I was waiting for the branch
[15:20] <bodie_> https://code.launchpad.net/~binary132/juju-core/charm-interface-actions/+merge/221595 line 351?
[15:20] <bodie_> or uh, right, the MR
[15:20] <bodie_> https://codereview.appspot.com/99640044/patch/20001/30015
[15:21] <bodie_> no biggie
[15:21] <bodie_> anyway, I think I can catch it before that in charm_test
[15:22] <bodie_> pushing up a change
[15:22] <jcw4> bodie_: yeah.  Which test is failing in your branch though... I'm not seeing the error you pasted
[15:23] <jcw4> bodie_: (doh) forgot to switch branches
[15:24] <bodie_> that revision probably has its own problems, I just pushed the test breakage back into the charm package
[15:24] <bodie_> https://codereview.appspot.com/99640044
[15:27] <jcw4> bodie_: so when you use map[interface{}]interface{} in the test it passes...
[15:27] <bodie_> right
[15:27] <jcw4> bodie_: where is the issue outside the test when you use that?
[15:28] <bodie_> state/charm_test/TestCharm line 53
[15:29] <bodie_> 54*
[15:33] <bodie_> the error is now charm/charm_test.go:77: invalid operation: f.Actions().ActionSpecs["snapshot"].Params["outfile"]["description"] (index of type interface {})
[15:33] <bodie_> Params is a map[string]interface{}
[15:33] <jcw4> bodie_: i see
[15:33] <bodie_> so, I need to cast it before checking, I suppose
[15:40] <bodie_> Panic: interface conversion: interface is map[interface {}]interface {}, not map[string]interface {}
[15:40] <bodie_> I'm still of the opinion that storing the JsonSchemaDocs as raw strings would be much simpler
[15:41] <jcw4> bodie_: yeah, that's an mgz and fwereade discussion.
[15:41] <bodie_> yep
[16:03] <voidspace> fwereade: natefinch: mp updated
[16:03] <voidspace> https://code.launchpad.net/~mfoord/juju-core/slow-replset/+merge/221709
[16:04] <voidspace> fwereade: natefinch: still waiting for lbox to do it's thing for the CL to update
[16:04] <voidspace> fwereade: note that after discussion with natefinch we switched to waiting for a successful replicaset status check rather than a config check
[16:04] <voidspace> this is slightly slower, but safer and more likely to actually fix the CI problem
[16:07] <voidspace> and CL updated too
[16:07] <voidspace> https://codereview.appspot.com/104800043
[16:24] <natefinch> voidspace: LGTM
[16:28] <voidspace> natefinch: cool, let's land it and see if it fixes the problem
[16:28] <voidspace> natefinch: if not I suggest we back it out because of the extra slowdown it causes
[16:36] <perrito666> back
[16:37] <voidspace> natefinch: I'm hoping this change makes replicasets more reliable for tests too
[16:37] <voidspace> natefinch: trying it now
[16:38] <voidspace> natefinch: hmmm... well, a bit more reliable
[16:38] <voidspace> natefinch: still some panics
[16:39] <mgz> fwereade: do you have github permissions to creat juju/core?
[16:39] <mgz> I seem not to.
[16:40] <fwereade> huh, I think you should
[16:40] <fwereade> mgz, what description would you like? :)
[16:41] <mgz> "Preliminary version, do not use yet" (I assume we can change that tomorrow :)
[16:42] <fwereade> mgz, created :)
[16:42] <mgz> thanks!
[16:42]  * fwereade has to go to the shops, bbiab, maybe
[16:50] <voidspace> sinzui: can you kick of a precise-amd64 bootstrap test
[16:50] <voidspace> sinzui: the last run was revision 2814
[16:50] <voidspace> http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/
[16:50] <sinzui> voidspace, no
[16:50] <voidspace> sinzui: is this the build problem you emailed about?
[16:51] <sinzui> voidspace, since the juju version was not updated to 1.19.4, it is not possible to test new revisions
[16:51] <voidspace> sinzui: right :-/
[16:51] <sinzui> wohttps://bugs.launchpad.net/juju-core/+bug/1325074
[16:51] <_mup_> Bug #1325074: Juju version cannot be set to 1.19.4 <packaging> <juju-core:Triaged> <https://launchpad.net/bugs/1325074>
[16:51] <voidspace> sinzui: we think we might have fixed the precise problem, we'll have to wait to see I guess
[16:51] <sinzui> 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] <voidspace> sinzui: :-(
[16:52] <voidspace> is anyone looking at this?
[16:52] <voidspace> I'm ten minutes before EOD I'm afraid
[16:52] <voidspace> and it's krav maga tonight
[16:52] <sinzui> voidspace, I don't think anyone is, sorry
[16:53] <sinzui> 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] <natefinch> mgz: can we just call it "juju"?
[17:03] <voidspace> right, off to krav maga
[17:03] <voidspace> probably back on later though
[17:03] <voidspace> see  you all
[17:03] <voidspace> EOD
[17:03] <mgz> natefinch: wha?
[17:04] <mgz> I was told core. There was a thread a while back and I thought that was the outcome of it.
[17:19] <natefinch> mgz: hmm, I must have missed that thread
[17:40] <cmars> 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 <destroy-service> <ui> <usability> <workflow> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1183309>
[17:40] <_mup_> Bug #1183309: destroy-service should have a force option <destroy-service> <ui> <usability> <workflow> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1183309>
[17:41] <jam> cmars: make sure you sync with fwereade because he felt destroy-service —force was a Won't Fix
[17:41] <cmars> jam, will do, thanks
[17:49] <jcw4> bodie_:  so bson (mgo\bson) doesn't know how to serialize map[interface{}]interface{}
[17:49] <bodie_> I figured that was it
[17:50] <bodie_> so I guess we need to look at how gojsonschema is representing it in memory
[17:50] <bodie_> I think it does a recursion
[17:50] <bodie_> in fact I'm certain it does
[17:50] <jcw4> well our tests indicated it was map[interface{}]interface{}... we know that Params will be a map[string](map[string]string)
[17:51] <bodie_> that's not necessarily true
[17:51] <bodie_> first of all, Params can definitely have simple string values
[17:51] <bodie_> http://paste.ubuntu.com/7574011/
[17:51] <mgz> 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] <bodie_> secondly, it could have more deeply nested maps
[17:52] <jcw4> bodie_: so Params is 100% free form, constrained only by a jsonschema?
[17:52] <jcw4> mgz: map[string]interface{} is okay with bson
[17:52] <jcw4> it's map[interface{}]interface{} that bson chokes on
[17:53] <mgz> well, taking that then
[17:53] <bodie_> mgz, do you know offhand whether encoding/json can?
[17:54] <bodie_> 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] <bodie_> without having to store the raw string
[17:55] <bodie_> but, I guess jcw4 is on the money with the assessment that the interface{} keys are the issue
[17:55] <jcw4> play.golang.org can't do imports...
[17:56] <bodie_> william mentioned we could use juju/schema to enforce String or MapString types
[17:56] <bodie_> s/MapString/stringMap
[17:56] <jcw4> http://paste.ubunut.com/7574595
[17:56] <jcw4> http://paste.ubuntu.com/7574595   damnig
[17:57] <wwitzel3> perrito666: thanks for the review
[17:57] <natefinch> mgz: I looked back at the thread where we talked about the name, I think we were hoping for canonical/juju, but couldn't get canonical.   I think otherwise, we didn't really come to a consensus.  There is definitely a lot of previous art for using github.com/team/project   .... when looking at our list of repos, you'll see "testing" "errgo" "loggo" ... and "core".  Except core is not a thing (arguably testing is a bad name
[17:57] <natefinch>  too).
[17:59] <perrito666> wwitzel3: my pleasure
[17:59] <bodie_> ha, that's so annoying that someone has already taken "canonical"
[17:59] <perrito666> (also my duty today :p)
[18:00] <bodie_> his account has also been inactive for at least a year or so
[18:00] <bodie_> make that 4 years
[18:01] <perrito666> bodie_: freenode?
[18:01] <bodie_> oh, my bad, I was thinking of Github.  I'll shut up now ^_^
[18:01] <bodie_> oh, since Nate had said github.com/team/project
[18:02] <bodie_> someone is parked on github.com/canonical, but his account has been inactive for 4 years
[18:03] <jcw4> bodie_: mgz, fwereade ... we know the params *passed in* when invoking an action can be arbitrary,  constrained by a jsonschema; but *declaring* the params in the actions.yaml seems like it will always be of a fixed structure?
[18:03] <bodie_> JSON-Schema is quite flexible
[18:04] <jcw4> bodie_: no disagreement there
[18:04] <bodie_> http://json-schema.org/example2.html
[18:04] <jcw4> bodie_: but actions.yaml is merely declaring the possible params, and providing a schema for what the value of those params could be
[18:04] <jcw4> but the name, description, and even default value isn't defined by that schema
[18:05] <jcw4> the schema we're referencing validates the value of the named parameter
[18:05] <bodie_> actions.yaml is being deserialized into a document which must be JSON-schema
[18:06] <bodie_> that's the only constraint as far as I'm aware
[18:06] <jcw4> bodie_: the point of json schema is to validate input to the api
[18:06] <jcw4> which 99% of the time is not from the actions.yaml file
[18:07] <jcw4> we're confusing declaring the action with invoking the action
[18:07] <bodie_> I'm not following your argument, actions.yaml does nothing but define the JSON-Schema which the Action arguments must be validated against
[18:07] <bodie_> Actions will therefore accept any JSON which conforms to the JSON-Schema defined in actions.yaml
[18:08] <jcw4> bodie_: you're saying that actions.yaml itself is the json schema?
[18:08] <bodie_> precisely
[18:08] <bodie_> of course, it doesn't have to itself be JSON, though it could since YAML can be constrained to conform to JSON
[18:08] <bodie_> it is simply deserialized into a JSON document which must conform to JSON-Schema v4
[18:09] <bodie_> or uh
[18:09] <jcw4> bodie_: so the "name", "description", and "default" keys are json schema keys?
[18:09] <bodie_> right, everything under params is JSON-schema
[18:09] <bodie_> so Actions could actually also have other Actions-related metadata
[18:09] <bodie_> whereas Actions.ActionSpecs is technically a map[string]JsonSchemaDoc
[18:09] <bodie_> or uh
[18:10] <bodie_> map[string]ActionSpec
[18:10] <bodie_> where ActionSpec contains potential metadata, AND a JSON-Schema document
[18:10] <bodie_> sorry, I'm sure that's very muddled in translation to english
[18:10] <perrito666> ok, my brain just segfaulted
[18:10] <perrito666> I just bzr git pushed
[18:11] <jcw4> bodie_: #jujuskunkworks?
[18:11] <bodie_> yeah
[18:12] <natefinch> perrito666: haha
[18:24] <natefinch> perrito666: sometimes I juju push... which works about as well
[18:25] <perrito666> I am so tempted to create plugin for git and bzr that are forgiving on my brain short circuits
[18:26] <perrito666> sweet, natefinch did you see https://codereview.appspot.com/99670044/ ?
[18:28] <natefinch> perrito666: yeah, I was trying to talk to fwereade about it.  I was wondering if we're really interested in writing bulk api calls for calls that can't be bulk right now.  I don't know what a bulk call for ensure availability would look like.  We don't have multiple environments on a state server currently.
[18:49] <bodie_> does anyone know offhand where an example of juju-schema usage would be found?  (I'll be doing a little looking myself starting now, but any pointers are appreciated :) )
[18:57] <perrito666> natefinch: when is it fall over there?
[18:57]  * perrito666 gets promissed a feature for his phone that he has been waiting for years
[18:58] <natefinch> perrito666: heh.... it's fall in like october
[18:58] <perrito666> bu
[18:59] <natefinch> perrito666: I take it you're watching the Apple stuff today?  Is it widgets or custom keyboard or something else?  those were the two that struck me as big
[18:59] <natefinch> (I'm just looking at a summary of a live blog, not actually paying that much attention)
[18:59] <perrito666> natefinch: I am listening to it, I had to get the mac with safari to get the vid to run so I just let it run on bg while I code
[18:59] <natefinch> haha
[19:00] <perrito666> natefinch: but no, the ability to answer phone calls and use sms on the computer
[19:00] <natefinch> oh, neat
[19:01] <perrito666> natefinch: since the first time I saw an iphone I wondered what was the goal of paying a fortune for a phone+computer that are made by the same manufacturer and cannot do anything more complex than copy music from one to the other
[19:05] <natefinch> haha
[20:05] <perrito666> mm /testing/base.go:26: undefined: "github.com/juju/testing".LoggingSuite
[20:08] <perrito666> what makes the dependencies go unclean?
[20:17] <natefinch> perrito666: generally it's that juju-core updates and the external repo doesn't, or vice versa
[20:17] <perrito666> natefinch: mm, apparently I have conflicts :|
[20:20] <perrito666> strange
[20:26] <perrito666> godeps ux is.... nil
[20:28] <natefinch> yeah
[20:29] <natefinch> I wish we'd drop it in favor of versioned branches
[20:30] <perrito666> natefinch: I would be fine if it just did git/bzr pull by itself
[20:32] <natefinch> perrito666: yeah, the problem is that in order to be fully functional, it would have to basically replicate the whole of go get
[20:33] <perrito666> natefinch: well, I could do another go lazytool in bash :p but you condemn bash tools for go
[20:33] <perrito666> :
[20:33] <perrito666> :p
[20:33] <natefinch> haha
[20:34] <natefinch> perrito666: you should send a patch in for godeps
[20:58] <thumper> fwereade: morning
[20:58] <thumper> fwereade: around?
[20:59] <thumper> oh for the love of all things...
[21:00] <thumper> why do people feel the need to write code where they have to repeat themselves
[21:00] <thumper> a lot...
[21:00] <perrito666> hey, hey would someone ptal https://codereview.appspot.com/103820044
[21:00] <perrito666> thumper: ?
[21:01] <thumper> hi perrito666
[21:01] <perrito666> thumper: good mornight
[21:01] <thumper> ah crap...
[21:01] <thumper> just remembered that I have to call the school to tell them daughter is at home...
[21:01] <perrito666> thumper: wont they notice? :p
[21:02] <thumper> perrito666: sure... but this is to say that I know ...
[21:02] <perrito666> heh, here they check every day and at the end of each month ask you if you where aware the days they where not there :p less than ideal
[21:04] <thumper> just had a mind blank on my own home phone number
[21:04] <perrito666> home phone, are you from the past?
[21:05]  * perrito666 misses having a home phone, but is not willing to wait 3-6 months for it
[21:06] <thumper> perrito666: will localhost ever be in the list more than once?
[21:07] <waigani>  thunderbird just crashed with the amount of emails I have to catch up on
[21:08] <waigani> morning menn0, thumper :)
[21:08] <thumper> waigani: morning
[21:08] <menn0> morning waigani
[21:09] <thumper> waigani, menn0: fyi, I'm working on adding display name hand doing more hacking elsewhere to make that happen than I was entirely comfortable with
[21:09] <thumper> I want you two to review it later
[21:09] <menn0> thumper: np
[21:16] <waigani> thumper: display name hand? what is that?
[21:16] <thumper> s/hand/and/
[21:16] <thumper> typo
[21:35] <thumper> menn0: did you have a branch changing --password on user add?
[21:42] <menn0> thumper: yes. that was merged some time ago
[21:43] <thumper> menn0: ta
[21:48] <sinzui> thumper, I fixed the bug
[21:48] <thumper> sinzui: yeah, I saw after I sent the email
[21:48] <sinzui> thumper, I found your constant in versions.go, I decide we can have upto 1.19.9 before we need to hack again
[21:49]  * thumper nods
[21:49] <voidspace> so my fix for precise-amd64 failed, but the error message is different
[21:49] <sinzui> thumper, It was obvious to fix when I had a break from the code. Friday was too chaotic for me
[21:49] <sinzui> voidspace, I think it has changed, yes
[21:50] <voidspace> sinzui: trying on my precise box now on the off chance I can reproduce, but I'll dig into it anyway
[21:50] <voidspace> sinzui: glad you managed to get CI working again, thanks
[21:50] <sinzui> voidspace, is this a timeout issue? Can I change a config to extend the timeout to 10 minutes?
[21:51] <voidspace> sinzui: I don't think so - the session is *immediately* saying it has already been closed
[21:52] <sinzui> wallyworld, CI has blessed 1.18.4 trunk. I will release it tomorrow unless you want me to delay. I see one bug in progress.
[21:52] <alexisb> alright folks, juju is last, if you have a twitter account and a few minutes vote! : http://ibmappthrowdown.tumblr.com/
[21:52] <alexisb> sinzui, fyi wallyworld is suppose to be out sick today
[21:52] <jcw4> alexisb: how many votes do you get... I already voted once
[21:53] <alexisb> 10 I think
[21:53] <jcw4> woo hoo
[21:53] <alexisb> you just have to change the first part of the message
[21:53] <sinzui> wallyworld, since 1.18.2 doesn't support utopic, I cloudn't deploy or provision a utopic slave to test. I had to manually install all the test resources to verify that utopic can be a deploy target. Oh the irony.
[21:54] <voidspace> I've voted from my twitter accounts
[21:58] <sinzui> alexisb, damn, I will find axwalk later and ask about his plans
[21:59] <jcw4> alexisb: well, six is about all I can comfortably inflict on my twitter friends
[22:00] <voidspace> naturally bootstrap succeeds on my precise machine
[22:01] <alexisb> :)
[22:01] <alexisb> far enough jcw4
[22:01] <alexisb> fair
[22:01] <jcw4> :)
[22:01] <sinzui> voidspace, is your machine lxc or vm?
[22:02] <voidspace> sinzui: it's a VM
[22:02] <thumper> mwhudson: I think you have spoiled me
[22:02] <thumper> mwhudson: now I get angry looking at terrible tests
[22:02] <mwhudson> thumper: happy to help!
[22:03] <mwhudson> also i mostly got that way from talking to jml, so blame him!
[22:16] <voidspace> anyone know what sort of time axw is likely to be around?
[22:21] <mwhudson> voidspace: he's perth, isn't he?
[22:21] <voidspace> mwhudson: I believe so
[22:21] <mwhudson> so utc+7 so it's only like 5 am for him now
[22:21] <mwhudson> so probably another 3-4 hours?
[22:22] <mwhudson> oh no, utc+8
[22:22] <voidspace> heh, yeah - 6:21am
[22:22] <mwhudson> oh heh, WA stopped doing dst in 2009
[22:31] <mgz> anyone know who's admin on the juju team on github? william was earlier, but I need someone to grant me rights so I can push a branch
[22:31] <mgz> alexisb: ^halp
[22:44] <wallyworld> sinzui: i am fixing backporting the fix fromtrunk now
[22:44] <wallyworld> should be done real soon now
[22:53] <mgz> wallyworld: do you have admin on github.com/juju ?
[22:54] <wallyworld> mgz: let me check
[22:54] <mgz> I need to push my import up there to switch the bot over
[22:58] <wallyworld> mgz: i added you as an owner of juju
[22:58] <wallyworld> mgz: what do you think about it being juju/juju ?
[22:59] <mgz> wallyworld: thanks, pushing
[22:59] <wallyworld> i can see the point
[22:59] <mgz> wallyworld: I don't really have an opinon, which is why I just did what was suggested
[22:59] <mgz> I'm fine with whichever name people want
[23:02] <wallyworld> thumper: do you have a strong opinion? github.com/juju/juju-core perhaps?
[23:02] <thumper> wallyworld: not especially
[23:02] <thumper> menn0, waigani: with  you in a minute
[23:03] <mgz> wallyworld, okay, repo up and job swaitched
[23:03] <menn0> thumper: np
[23:03] <mgz> emailing instructions
[23:03] <wallyworld> mgz: i can see that core may be suboptimal if people fork. can we make it juju-core?
[23:03] <wallyworld> mgz: awesome
[23:03] <wallyworld> did you get the tarmac integration sorted?
[23:04] <mgz> discussed using other non-ec2 clouds with sinzui, seems hp would be the best switch
[23:04] <mgz> but want to try a couple more things on ec2
[23:06] <sebas5384> cmars: ping
[23:07] <cmars> hi sebas5384
[23:07] <cmars> what's up?
[23:07] <sebas5384> hey!
[23:08] <sebas5384> i did the -i parameter to specify the interface (at least i think i did hehe)
[23:08] <sebas5384> but i don't know how to test
[23:08] <cmars> oh cool
[23:08] <sebas5384> i run the the make restore install
[23:08] <sebas5384> but it always get stuck in some build
[23:08] <sebas5384> if you can guide me to test it cmars :)
[23:09] <wallyworld> mgz: ok, so long as we get to the point where we migrate and the landing is reliable :-)
[23:09] <cmars> sebas5384, can you push your changes up to your branch, so i can try it?
[23:10] <sebas5384> cmars: yes!
[23:11] <sebas5384> cmars: when its there i notice you
[23:20] <sebas5384> cmars: https://github.com/sebas5384/juju-nat/tree/local-provider-support
[23:21]  * cmars takes a look
[23:24] <sinzui> The windows builder and test has gone tits up
[23:25] <sinzui> I need to build a new one before to retest 1.18.4 for release tonight
[23:32] <perrito666> thumper: ping me when you are back plz
[23:33] <thumper> perrito666: back and off calls now
[23:33] <perrito666> I saw your comment, how do you suggest that port to be set?
[23:33] <thumper> there are other examples in the code
[23:34]  * thumper looks for one
[23:34] <thumper> perrito666: launchpad.net/juju-core/charm/testing/mockstore.go:
[23:34] <thumper> perrito666: line 59
[23:34] <thumper> perrito666: effectively ask for port 0, and then look at what it gave you
[23:37] <perrito666> I see, thank you
[23:38] <cmars> sebas5384, commented
[23:39] <sebas5384> cmars: yeah! i sow thanks
[23:39] <sebas5384> cmars: but can you help me on how to test it?
[23:40] <wallyworld> sinzui: that 1.18.4 bug is now fix committed
[23:40] <sebas5384> i will make the changes cmars
[23:40] <cmars> sebas5384, sadly, i do not have unit tests. we're in the awkward position of manually testing the thing, unf
[23:41] <sinzui> wallyworld, fab, now I need to just build a replacement windows instance to test it
[23:41] <wallyworld> joy
[23:41] <cmars> sebas5384, shame on me... i'll add an issue to make some proper unit tests. juju-core has some nice testing infrastructure, which will help
[23:41] <cmars> in the meantime, manual testing will have to suffice
[23:42] <sebas5384> nice!
[23:42] <sebas5384> yeah!
[23:42] <sebas5384> but how?
[23:42] <sebas5384> hehe i don't know how to build it and use it
[23:43] <cmars> sebas5384, i'll note the pull req
[23:43] <cmars> or the branch, rathetr
[23:45] <sebas5384> thanks cmars o/
[23:51] <sinzui> wallyworld, I think 1.18.4 will have a good ride through CI. My new win machine works. It was the machine that failed to start and caused the curse of the last revision
[23:52]  * wallyworld crosses fingers
[23:52] <sinzui> wallyworld, CI won't get to the stable revision for about 90 minutes though
[23:52] <wallyworld> o
[23:52] <wallyworld> k
[23:52]  * thumper goes to hit some things...
[23:55] <sinzui> hmm. CI now take 2h10m to test everything
[23:55]  * sinzui ponders parallel builds in ci3.5