| bodie_ | if anyone can give me some insight here, it would be really helpful | 00:16 |
|---|---|---|
| bodie_ | http://paste.ubuntu.com/7569460/ | 00:16 |
| bodie_ | the value is being retrieved from the db, after being serialized into it from a nested map[interface{}]interface{} | 00:17 |
| 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:20 |
| 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? | 00:24 |
| === vladk|offline is now known as vladk | ||
| jam | morning all | 05:54 |
| wallyworld | hi | 05:55 |
| wallyworld | quiet today with nz folks missing and andrew | 05:56 |
| 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:57 |
| 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:58 |
| wallyworld | the github cutover has been on my mind - i need to catch up with martin a bit later | 05:59 |
| 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:00 |
| vladk | jam: morning | 06:03 |
| jam | morning vladk, just switching to the hangout now | 06:03 |
| dimitern | morning all | 06:18 |
| wallyworld | morning | 06:23 |
| 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:57 |
| 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:58 |
| 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? | 06:59 |
| dimitern | jam, i'm here, we can finish earlier as well | 07:06 |
| === rogpeppe1 is now known as rogpeppe | ||
| wallyworld | jam: sorry, was dealing with a crisis at home. there were no plans o do 1.18 as well, just trunk onwards | 07:41 |
| === vladk is now known as vladk|offline | ||
| 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:42 |
| 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 | 07:46 |
| 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:10 |
| wallyworld | bloody capslock | 08:11 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === vladk|offline is now known as vladk | ||
| voidspace | morning all | 08:39 |
| TheMue | voidspace: morning | 08:47 |
| jam | morning voidspace | 08:56 |
| 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:00 |
| mgz | was worried you might be ill in bed till I saw you chatting with jam earlier :) | 09:01 |
| dimitern | WTF is github.com/binary132/gojsonschema ?? | 09:02 |
| dimitern | are we adding random github dependencies now just like that? | 09:02 |
| dimitern | I though we're supposed to bring/fork third parties into github.com/juju/ when using them? | 09:03 |
| 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:04 |
| 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:12 |
| dimitern | jam, and fork if the upstream breaks our stuff? | 09:14 |
| 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:15 |
| dimitern | ah, right | 09:19 |
| 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:23 |
| dimitern | jam, modern technology hey :) | 09:27 |
| 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:30 |
| 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:32 |
| dimitern | jam, mgz, can you rename a branch and repropose it as new? | 09:35 |
| mgz | dimitern: you caaan... | 09:37 |
| mgz | easiest just to push from old location to new | 09:37 |
| dimitern | mgz, but how about the working dir? what bzr commands to use? | 09:38 |
| 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:39 |
| 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:40 |
| voidspace | I'd love a go debugger right now | 09:53 |
| dimitern | voidspace, have you checked this http://golang.org/doc/gdb ? | 09:56 |
| voidspace | dimitern: I haven't | 09:58 |
| voidspace | dimitern: hmmm | 09:59 |
| === vladk is now known as vladk|offline | ||
| jam | vladk|offline: standup? | 10:46 |
| === vladk|offline is now known as vladk | ||
| 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:47 |
| jam | voidspace: ah, because it is driven by "jujud bootstrap-state" ? | 10:48 |
| 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:49 |
| 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:50 |
| perrito666 | good morning everyone | 10:56 |
| voidspace | perrito666: morning | 10:56 |
| jam | morning perrito666 | 10:56 |
| voidspace | so, on my local machine it is 9 seconds after Initiate that replSetStatus is able to return a successful status | 11:06 |
| perrito666 | jam: so you made my sunday interesting with your email :p | 11:10 |
| jam | might as well keep every day exciting, why should weekends be different | 11:12 |
| 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:13 |
| === vladk is now known as vladk|offline | ||
| 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:14 |
| fwereade | dimitern, I think I can do that now if you're free | 11:15 |
| 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:17 |
| fwereade | dimitern, nonetheless I think what we need to store is "all *accessible* networks" | 11:18 |
| jam | dimitern: vladk|offline: care to join us? | 11:20 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| 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:29 |
| 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:31 |
| jam | perrito666: I seem to have abit of time while this meeting comes together | 11:34 |
| jam | what's up? | 11:34 |
| 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:35 |
| jam | right | 11:36 |
| 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:37 |
| 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:38 |
| * perrito666 thinks | 11:40 | |
| 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:41 |
| 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:43 |
| 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:44 |
| natefinch | with different ports? Shouldn't be | 11:45 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| voidspace | natefinch: all tests pass with this change | 11:54 |
| 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:55 |
| voidspace | perrito666: well, didn't break anything covered by tests anyway | 11:56 |
| * voidspace lunch | 12:03 | |
| jam | natefinch: did you want to do a catchup 1:1 now? | 12:18 |
| dimitern | fwereade, cheers, thanks | 12:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| rogpeppe | jam: ok, TEST_LOGGING_CONFIG it is | 12:29 |
| === vladk is now known as vladk|offline | ||
| 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:35 |
| fwereade | jam, dimitern: +1 to that | 12:36 |
| dimitern | jam, i'm reading the wiki today as i code | 12:43 |
| dimitern | jam, sgtm, i'll have more insight tomorrow i guess | 12:43 |
| === vladk|offline is now known as vladk | ||
| 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:36 |
| jam | rogpeppe: rev 9 of golxc has "Replace LoggingSuite with IsolationSuite" | 13:37 |
| rogpeppe | jam: oh | 13:38 |
| rogpeppe | jam: i guess i didn't try bzr pull | 13:38 |
| rogpeppe | jam: thanks | 13:40 |
| 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:43 |
| voidspace | further complicated by the fact that *all* replicaset tests Initiate already | 13:44 |
| voidspace | but I can workaround that | 13:44 |
| 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:01 |
| 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:02 |
| dimitern | vladk, reviewed | 14:17 |
| 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:18 |
| dimitern | fwereade, ok, sure | 14:19 |
| dimitern | perrito666, PTAL then ^^ :) | 14:19 |
| perrito666 | dimitern: looking | 14:20 |
| === andreas__ is now known as ahasenack | ||
| dimitern | perrito666, thanks | 14:24 |
| perrito666 | dimitern: I am sure you have a very good reason for it, but why ^? :) | 14:24 |
| dimitern | perrito666, ;) | 14:25 |
| dimitern | perrito666, for the CL or for the "thanks" ? | 14:25 |
| perrito666 | dimitern: for the use of "^" | 14:25 |
| dimitern | perrito666, ah, sorry - I meant "look at the previous lines" | 14:26 |
| 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:27 |
| === vladk is now known as vladk|offline | ||
| perrito666 | dimitern: I think the ideal would be "-" but that would break anything most likely | 14:30 |
| dimitern | perrito666, yes, we use "-" in tags | 14:34 |
| 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:37 |
| bodie_ | er, for use with mongo | 14:38 |
| 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:39 |
| natefinch | bodie_: not sure why it's not serializing correctly. However, I'm wondering why you have a map with interface{} as keys? | 14:41 |
| 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:42 |
| bodie_ | you end up with a map[i{}]i{} | 14:43 |
| natefinch | I sort of understand....sort of | 14:45 |
| bodie_ | natefinch, the actionspecs key here has a list of values, which are themselves keys | 14:46 |
| bodie_ | https://codereview.appspot.com/94540044 | 14:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| jcw4 | no, the value would be a map[string]interface{} | 14:53 |
| jcw4 | not a list of keys | 14:53 |
| bodie_ | right | 14:53 |
| jcw4 | bodie_: there's never a time that there will be a value of type map[interface{}]interface{} | 14:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:02 |
| natefinch | if other people jumped off a bridge, would you? ;) | 15:04 |
| bodie_ | hehe | 15:04 |
| bodie_ | here we are | 15:05 |
| bodie_ | http://paste.ubuntu.com/7573584/ | 15:05 |
| bodie_ | so, "outfile" is a map[string]interface{} | 15:05 |
| bodie_ | I conformed my test to the obtained result, but maybe that's where I need to look closer | 15:06 |
| bodie_ | http://paste.ubuntu.com/7573598/ | 15:07 |
| 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:08 |
| 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:09 |
| sinzui | The unit tests are not affected by this, just the substrate and function tests | 15:10 |
| jcw4 | bodie_: is this code all pushed up to your branch? | 15:11 |
| bodie_ | yeah | 15:11 |
| 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:12 |
| 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:14 |
| jcw4 | bodie_: before it hit the DB? | 15:15 |
| bodie_ | right, my issue was that I was retrieving an unexpected <Value: ...> from the database | 15:16 |
| bodie_ | instead of a map | 15:16 |
| jcw4 | bodie_: hmm, I didn't see any mongo access in that MR, do you mean Charm YAML? | 15:17 |
| 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:18 |
| jcw4 | bodie_: hmm, not in the MR then okay.. I was looking there while I was waiting for the branch | 15:19 |
| 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:20 |
| bodie_ | no biggie | 15:21 |
| bodie_ | anyway, I think I can catch it before that in charm_test | 15:21 |
| 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:22 |
| jcw4 | bodie_: (doh) forgot to switch branches | 15:23 |
| 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:24 |
| 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:27 |
| bodie_ | state/charm_test/TestCharm line 53 | 15:28 |
| bodie_ | 54* | 15:29 |
| 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:33 |
| 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:40 |
| jcw4 | bodie_: yeah, that's an mgz and fwereade discussion. | 15:41 |
| bodie_ | yep | 15:41 |
| voidspace | fwereade: natefinch: mp updated | 16:03 |
| voidspace | https://code.launchpad.net/~mfoord/juju-core/slow-replset/+merge/221709 | 16:03 |
| 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:04 |
| voidspace | and CL updated too | 16:07 |
| voidspace | https://codereview.appspot.com/104800043 | 16:07 |
| === hatch__ is now known as hatch | ||
| natefinch | voidspace: LGTM | 16:24 |
| 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:28 |
| === vladk|offline is now known as vladk | ||
| perrito666 | back | 16:36 |
| voidspace | natefinch: I'm hoping this change makes replicasets more reliable for tests too | 16:37 |
| voidspace | natefinch: trying it now | 16:37 |
| voidspace | natefinch: hmmm... well, a bit more reliable | 16:38 |
| voidspace | natefinch: still some panics | 16:38 |
| mgz | fwereade: do you have github permissions to creat juju/core? | 16:39 |
| mgz | I seem not to. | 16:39 |
| fwereade | huh, I think you should | 16:40 |
| fwereade | mgz, what description would you like? :) | 16:40 |
| mgz | "Preliminary version, do not use yet" (I assume we can change that tomorrow :) | 16:41 |
| fwereade | mgz, created :) | 16:42 |
| mgz | thanks! | 16:42 |
| * fwereade has to go to the shops, bbiab, maybe | 16:42 | |
| 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:50 |
| 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:51 |
| 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:52 |
| sinzui | voidspace, I have talked to a few devs, but no one has a clue | 16:53 |
| * sinzui ponders the consequences of hacking the juju version just before the tarball is built | 16:54 | |
| * sinzui think unit tests fail (good), but substrate tests will run | 16:55 | |
| natefinch | mgz: can we just call it "juju"? | 16:58 |
| 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:03 |
| mgz | I was told core. There was a thread a while back and I thought that was the outcome of it. | 17:04 |
| natefinch | mgz: hmm, I must have missed that thread | 17:19 |
| 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:40 |
| 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:41 |
| jcw4 | bodie_: so bson (mgo\bson) doesn't know how to serialize map[interface{}]interface{} | 17:49 |
| bodie_ | I figured that was it | 17:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| mgz | well, taking that then | 17:53 |
| bodie_ | mgz, do you know offhand whether encoding/json can? | 17:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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) | 17:59 |
| bodie_ | his account has also been inactive for at least a year or so | 18:00 |
| bodie_ | make that 4 years | 18:00 |
| 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:01 |
| bodie_ | someone is parked on github.com/canonical, but his account has been inactive for 4 years | 18:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| jcw4 | bodie_: #jujuskunkworks? | 18:11 |
| bodie_ | yeah | 18:11 |
| natefinch | perrito666: haha | 18:12 |
| natefinch | perrito666: sometimes I juju push... which works about as well | 18:24 |
| perrito666 | I am so tempted to create plugin for git and bzr that are forgiving on my brain short circuits | 18:25 |
| perrito666 | sweet, natefinch did you see https://codereview.appspot.com/99670044/ ? | 18:26 |
| 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:28 |
| 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:49 |
| 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:57 | |
| natefinch | perrito666: heh.... it's fall in like october | 18:58 |
| perrito666 | bu | 18:58 |
| 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 | 18:59 |
| perrito666 | natefinch: but no, the ability to answer phone calls and use sms on the computer | 19:00 |
| natefinch | oh, neat | 19:00 |
| 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:01 |
| natefinch | haha | 19:05 |
| perrito666 | mm /testing/base.go:26: undefined: "github.com/juju/testing".LoggingSuite | 20:05 |
| perrito666 | what makes the dependencies go unclean? | 20:08 |
| 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:17 |
| perrito666 | strange | 20:20 |
| perrito666 | godeps ux is.... nil | 20:26 |
| natefinch | yeah | 20:28 |
| natefinch | I wish we'd drop it in favor of versioned branches | 20:29 |
| perrito666 | natefinch: I would be fine if it just did git/bzr pull by itself | 20:30 |
| 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:32 |
| 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:33 |
| natefinch | perrito666: you should send a patch in for godeps | 20:34 |
| thumper | fwereade: morning | 20:58 |
| thumper | fwereade: around? | 20:58 |
| thumper | oh for the love of all things... | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| thumper | just had a mind blank on my own home phone number | 21:04 |
| perrito666 | home phone, are you from the past? | 21:04 |
| * perrito666 misses having a home phone, but is not willing to wait 3-6 months for it | 21:05 | |
| thumper | perrito666: will localhost ever be in the list more than once? | 21:06 |
| waigani | thunderbird just crashed with the amount of emails I have to catch up on | 21:07 |
| waigani | morning menn0, thumper :) | 21:08 |
| thumper | waigani: morning | 21:08 |
| menn0 | morning waigani | 21:08 |
| 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:09 |
| waigani | thumper: display name hand? what is that? | 21:16 |
| thumper | s/hand/and/ | 21:16 |
| thumper | typo | 21:16 |
| === vladk is now known as vladk|offline | ||
| thumper | menn0: did you have a branch changing --password on user add? | 21:35 |
| menn0 | thumper: yes. that was merged some time ago | 21:42 |
| thumper | menn0: ta | 21:43 |
| 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:48 |
| * 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:49 |
| 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:50 |
| voidspace | sinzui: I don't think so - the session is *immediately* saying it has already been closed | 21:51 |
| 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:52 |
| 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:53 |
| voidspace | I've voted from my twitter accounts | 21:54 |
| sinzui | alexisb, damn, I will find axwalk later and ask about his plans | 21:58 |
| jcw4 | alexisb: well, six is about all I can comfortably inflict on my twitter friends | 21:59 |
| voidspace | naturally bootstrap succeeds on my precise machine | 22:00 |
| 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:01 |
| 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:02 |
| mwhudson | also i mostly got that way from talking to jml, so blame him! | 22:03 |
| voidspace | anyone know what sort of time axw is likely to be around? | 22:16 |
| 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:21 |
| mwhudson | oh no, utc+8 | 22:22 |
| voidspace | heh, yeah - 6:21am | 22:22 |
| mwhudson | oh heh, WA stopped doing dst in 2009 | 22:22 |
| 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:31 |
| wallyworld | sinzui: i am fixing backporting the fix fromtrunk now | 22:44 |
| wallyworld | should be done real soon now | 22:44 |
| mgz | wallyworld: do you have admin on github.com/juju ? | 22:53 |
| wallyworld | mgz: let me check | 22:54 |
| mgz | I need to push my import up there to switch the bot over | 22:54 |
| wallyworld | mgz: i added you as an owner of juju | 22:58 |
| wallyworld | mgz: what do you think about it being juju/juju ? | 22:58 |
| 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 | 22:59 |
| 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:02 |
| 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:03 |
| 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:04 |
| sebas5384 | cmars: ping | 23:06 |
| cmars | hi sebas5384 | 23:07 |
| cmars | what's up? | 23:07 |
| sebas5384 | hey! | 23:07 |
| 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:08 |
| 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:09 |
| sebas5384 | cmars: yes! | 23:10 |
| sebas5384 | cmars: when its there i notice you | 23:11 |
| sebas5384 | cmars: https://github.com/sebas5384/juju-nat/tree/local-provider-support | 23:20 |
| * cmars takes a look | 23:21 | |
| sinzui | The windows builder and test has gone tits up | 23:24 |
| sinzui | I need to build a new one before to retest 1.18.4 for release tonight | 23:25 |
| perrito666 | thumper: ping me when you are back plz | 23:32 |
| 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:33 |
| * 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:34 |
| perrito666 | I see, thank you | 23:37 |
| cmars | sebas5384, commented | 23:38 |
| sebas5384 | cmars: yeah! i sow thanks | 23:39 |
| sebas5384 | cmars: but can you help me on how to test it? | 23:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| cmars | sebas5384, i'll note the pull req | 23:43 |
| cmars | or the branch, rathetr | 23:43 |
| sebas5384 | thanks cmars o/ | 23:45 |
| 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:51 |
| * 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:52 | |
| sinzui | hmm. CI now take 2h10m to test everything | 23:55 |
| * sinzui ponders parallel builds in ci3.5 | 23:55 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!