| davecheney | wallyworld: it sounds like you have a lot on your plate | 00:00 |
|---|---|---|
| davecheney | i'll look at testing ec2 and hp deployments today now that RT is closed | 00:00 |
| wallyworld | ido | 00:00 |
| wallyworld | awesome :-) | 00:00 |
| davecheney | wallyworld: fair warning, there are some remaining tools selectino bugs on ppc | 00:00 |
| wallyworld | ok | 00:00 |
| davecheney | mainly because precise/ppc64el is not a thing | 00:00 |
| davecheney | i'll do what I can to resolve them myself | 00:00 |
| wallyworld | davecheney: i'm happy to fix also | 00:01 |
| davecheney | wallyworld: lemmie figure out what they are first | 00:01 |
| wallyworld | ok | 00:01 |
| davecheney | all I can see at the moment is tests pass with gccgo/amd64 | 00:01 |
| davecheney | and fail with gccgo/ppc64el whinging that no tools are available | 00:01 |
| wallyworld | davecheney: is there simplestreams metadata for ppc64el? | 00:13 |
| wallyworld | that would be a likely cause | 00:13 |
| davecheney | wallyworld: in the test fixures ? | 00:34 |
| davecheney | sinzui: https://bugs.launchpad.net/juju-core/+bug/1298708 | 00:35 |
| _mup_ | Bug #1298708: bzr: bzr unit tests are not properly isolated <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1298708> | 00:35 |
| davecheney | this is sort of a big failure | 00:35 |
| davecheney | how does this pass in CI ? | 00:35 |
| wallyworld | davecheney: i think so. what tests are failing? | 00:35 |
| davecheney | wallyworld: hang on | 00:35 |
| davecheney | talking at cross purpises | 00:35 |
| davecheney | what are you talking about | 00:35 |
| wallyworld | the missing ppc64el tools metadata | 00:36 |
| davecheney | wallyworld: in that case I agree | 00:36 |
| davecheney | let me check quickly | 00:36 |
| * davecheney flails around a bit | 00:39 | |
| davecheney | wallyworld: where in the source are the test fixtures ? | 00:40 |
| wallyworld | depends on what tests are filing | 00:40 |
| davecheney | wallyworld: you mentioned that there was sample simples streams data | 00:41 |
| davecheney | where in the source are those fixtures kept ? | 00:41 |
| wallyworld | there's several tests with different sources | 00:41 |
| davecheney | sure | 00:42 |
| wallyworld | there's some in environs/simplestreams/testing | 00:42 |
| wallyworld | but each provider also sets up its own data | 00:42 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core/environs/simplestreams/testing$ ls | 00:42 |
| davecheney | testing.go | 00:42 |
| davecheney | ahh, rigth | 00:42 |
| davecheney | now I understand | 00:42 |
| davecheney | afk for a bit | 00:44 |
| perrito666 | eu1Ahloo | 01:36 |
| perrito666 | eu | 01:36 |
| perrito666 | ouch | 01:37 |
| perrito666 | :p | 01:37 |
| sarnold | not a bad password, as passwords go.. | 01:37 |
| perrito666 | sarnold: nah, altough I think I should definitely not use it for something else than my laptop :) since apparently I can have the screen locker on but the focus on the chat | 01:39 |
| sarnold | perrito666: ah :) https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1292217 | 01:41 |
| _mup_ | Bug #1292217: lightdm screen lock has triggered but keyboard is still connected to the main session <amd64> <apport-bug> <lockscreen> <third-party-packages> <trusty> <unity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1292217> | 01:41 |
| perrito666 | sarnold: lol | 01:41 |
| === vladk|offline is now known as vladk | ||
| mattyw | when using goyaml and json is there a way I can tell struct tags to marshal/unmarshal the same for both systems - the syntax in my head is something like `json,yaml:foo-bar` | 03:08 |
| davecheney | mattyw: yes | 03:18 |
| davecheney | the syntax is slightly different | 03:18 |
| davecheney | from memory `yaml:foo-bar,json:foo-bar` | 03:18 |
| davecheney | there might even be some "'s in there as well | 03:18 |
| mattyw | davecheney, I found that `json:"foo" yaml:"foo"` works - but it would be nice not to have to repeat the key | 03:18 |
| mattyw | it would be nice to not need to repeat the key - but I guess that isn't the way the world works | 03:19 |
| davecheney | mattyw: well puyt | 03:19 |
| === vladk is now known as vladk|offline | ||
| mattyw | davecheney, thanks dave - I'll let you get back to implementing generics | 03:20 |
| davecheney | mattyw: you're welcome | 03:20 |
| davecheney | mattyw: you're welcome | 03:20 |
| davecheney | axw: wallyworld i am looking at this bug | 03:38 |
| davecheney | http://paste.ubuntu.com/7165797/ | 03:38 |
| davecheney | and I am really concerned that public and private addresses are being mixed up | 03:38 |
| davecheney | looking at the code, so far I see they are handled separately | 03:38 |
| davecheney | but I woner if at some point they are mushed into a map, then someone is grabbing the first key from the map and assuming that is the first item pushed into the map | 03:39 |
| wallyworld | could be | 03:39 |
| davecheney | wallyworld: it looks liek they are stored in separate fields in the machine/unit document | 03:39 |
| davecheney | sorry it would be the machine document | 03:39 |
| wallyworld | i think so yes | 03:39 |
| axw | davecheney: they are indeed put into a map | 03:39 |
| davecheney | axw: ORLY | 03:40 |
| axw | davecheney: to remove dupes. does order matter here? SelectPublic/SelectInternal should still do the right thing...? | 03:40 |
| davecheney | axw: is that in state, or in instance ? | 03:40 |
| wallyworld | it looks just like another map orderin fting | 03:40 |
| wallyworld | thing | 03:41 |
| davecheney | wallyworld: the first bug is | 03:41 |
| wallyworld | in the test only | 03:41 |
| davecheney | the seconds are a little weirder | 03:41 |
| axw | davecheney: they're merged in state.Machine.Addresses | 03:41 |
| axw | state/machine.go | 03:41 |
| davecheney | addresses := []instance.Address{ | 03:41 |
| davecheney | instance.NewAddress("127.0.0.1"), | 03:41 |
| davecheney | instance.NewAddress("8.8.8.8"), | 03:41 |
| davecheney | } | 03:41 |
| davecheney | err = machine.SetAddresses(addresses) | 03:41 |
| davecheney | c.Assert(err, gc.IsNil) | 03:41 |
| davecheney | address, ok = s.unit.PublicAddress() | 03:41 |
| davecheney | c.Check(address, gc.Equals, "8.8.8.8") | 03:42 |
| davecheney | this is weird | 03:42 |
| davecheney | what defined the public and private addresses ? | 03:42 |
| davecheney | it feels like the order in which the are added | 03:42 |
| davecheney | the first is always private | 03:42 |
| davecheney | the rest are public | 03:42 |
| wallyworld | there's an lgorithm | 03:42 |
| wallyworld | internalAddressIndex | 03:43 |
| axw | davecheney: addresses have a scope which says whether they're public/private | 03:43 |
| wallyworld | i think it's just the test | 03:43 |
| davecheney | wallyworld: the test is failing because s.unit.PublicAddress() returns the priovate address | 03:43 |
| axw | davecheney: see NetworkScope in instance/address.go | 03:43 |
| wallyworld | the test is inserting 2 addresses into a map without enough info for one to be considered private over another | 03:43 |
| wallyworld | the test needs improving i think | 03:43 |
| davecheney | wallyworld: there aren't any maps on that code sample I showed | 03:43 |
| davecheney | i'm concerned that this is a bug in the code | 03:43 |
| davecheney | not the expected in the test | 03:44 |
| wallyworld | davecheney: that's not the point | 03:44 |
| wallyworld | the code picks an address based on the internalAddressIndex algorithm | 03:44 |
| wallyworld | and the addresses in the test don't appear to have enough info for one to be picked over another | 03:44 |
| wallyworld | so an arbitary one is chosen | 03:44 |
| davecheney | wallyworld: right, so that is a bug in unit.PublicAddress | 03:45 |
| axw | if they're all public or private, I think order matters | 03:45 |
| davecheney | not the test | 03:45 |
| wallyworld | that's based on a very quick look at the code | 03:45 |
| axw | but that's arbitrary | 03:45 |
| wallyworld | it's not a bug | 03:45 |
| wallyworld | if more than 1 address matches, it just picks one | 03:45 |
| wallyworld | so the test needs to insert addresses with more info | 03:45 |
| axw | davecheney: instance.NewAddress just gives you an address of "unknown" type | 03:46 |
| wallyworld | so that 1 is definitely private vs public | 03:46 |
| wallyworld | the address type needs to be set | 03:46 |
| axw | so neither 127.0.0.1 nor 8.8.8.8 in that test are public | 03:46 |
| axw | it just happened to be picking 8.8.8.8 before because it was the last in the list | 03:46 |
| davecheney | axw: right, thanks | 03:46 |
| davecheney | axw: wallyworld thanks | 03:46 |
| davecheney | now I understand | 03:46 |
| davecheney | i'll fix it | 03:46 |
| * axw hopes nothing actually relies on that | 03:47 | |
| wallyworld | davecheney: sorry about bad explanation, test is shit | 03:47 |
| davecheney | axw: you'll be surprised :) | 03:47 |
| davecheney | Spot the bug, Holiday | 04:11 |
| davecheney | May 201407/05/2014 - 07/03/2014Awaiting Sign Off | 04:11 |
| davecheney | axw: wallyworld instance.NewAddresses would appear to be a footgun | 04:21 |
| axw | davecheney: yeah, it should probably be in a testing package, if that | 04:22 |
| wallyworld | it doesn't really set the scope does it | 04:22 |
| axw | it's only used by tests | 04:22 |
| davecheney | axw: should I delete it ? | 04:24 |
| davecheney | it never sets the scope | 04:24 |
| davecheney | so its value would be ... dubiois | 04:25 |
| davecheney | instance.Address{Value: "x.y.z.q"} does the same thing | 04:25 |
| davecheney | hmm, NewAddress does do more that I just said | 04:29 |
| davecheney | but it always sets the scope to unknown | 04:29 |
| axw | davecheney: sorry, was making lunch. I don't know, depends on how it makes the tests look. I'd opt for just moving it, so it's not accidentally used in a place where it matters | 04:36 |
| davecheney | axw: moving it out of the instance API and as a helper | 04:46 |
| davecheney | that would certainly reduce it's lethality | 04:46 |
| davecheney | let's see what breaks | 04:49 |
| davecheney | axw: http://paste.ubuntu.com/7166620/ line 174 | 05:04 |
| davecheney | i wonder if this related to the last issue | 05:04 |
| * axw looks | 05:10 | |
| axw | davecheney: broken test; it's setting the wrong scope on the "public" address | 05:11 |
| davecheney | axw: yet it passed up until now .... | 05:18 |
| axw | davecheney: yes, by implicitly relying on map ordering | 05:18 |
| axw | it just happened to pick the internal address previously | 05:19 |
| davecheney | waaaaaaaaaaaaaah | 05:19 |
| davecheney | ok, will fix | 05:19 |
| davecheney | wallyworld: i don't think i'm going to get to adding simple streams data for ppc64el | 05:20 |
| davecheney | i'll log a but | 05:20 |
| davecheney | bug | 05:20 |
| davecheney | but I know you have better things to do | 05:20 |
| wallyworld | ok | 05:20 |
| wallyworld | i'm finishing the joyent provider | 05:20 |
| wallyworld | i'll try and get to it real soon now | 05:20 |
| davecheney | wallyworld: no no | 05:21 |
| davecheney | that is what I am saying | 05:21 |
| davecheney | i need to log a bug for my status report | 05:21 |
| davecheney | but don't think you need to do it | 05:22 |
| wallyworld | ok | 05:22 |
| davecheney | axw: OMG | 05:41 |
| davecheney | cloudLocalAddress := instance.NewAddress("cloudlocal") | 05:41 |
| davecheney | cloudLocalAddress.NetworkScope = instance.NetworkCloudLocal | 05:41 |
| davecheney | ^ even other callers of NewAddress don't trust it | 05:41 |
| axw | :) | 05:45 |
| axw | it's a bit pointless there isn't it | 05:45 |
| axw | davecheney: if you do move it, maybe rename it too. NewUnknownAddress | 05:45 |
| davecheney | axw: i'm thinking instead adding a manditory scope parameter instead | 05:51 |
| davecheney | then it can't be misused | 05:51 |
| axw | davecheney: sounds sensible | 05:51 |
| davecheney | famous last words | 05:51 |
| davecheney | cummon and land my change you mongrel | 06:02 |
| davecheney | jam1: has the bot crapped itself ? | 06:21 |
| davecheney | or is it just reeeeeeeeeeely slow ? | 06:21 |
| davecheney | axw: instance.NewAddress is barely used, only one case in the whole codebase | 06:25 |
| axw | davecheney: apart from tests? yeah, that one can just be changed to create an address struct literal | 06:26 |
| davecheney | yeah, quite a few tests | 06:30 |
| davecheney | i'm going to go with the plan of adding an explict scope argument | 06:30 |
| davecheney | this will probably make people questino the values passed to NewAddress | 06:30 |
| wallyworld | axw: git 101 question - i've forked a github branch, cloned locally into the src tree i use for juju-core development, comitted and push some changes. How do i now revert the branch on disk to the original from github? | 06:47 |
| wallyworld | i'd use bzr switch | 06:48 |
| wallyworld | what's the git equivalent? | 06:48 |
| davecheney | wallyworld: git checkout $BRANCH ? | 06:50 |
| wallyworld | davecheney: ok, ta. i'm a total git noob. | 06:50 |
| davecheney | wallyworld: i *may* not have told you the right thing | 06:50 |
| davecheney | there is also git reset --hard | 06:50 |
| axw | wallyworld: depends on whether you branched to start with | 06:51 |
| davecheney | but that might be a hammer to crack an egg | 06:51 |
| wallyworld | i must say, having created a couple of pull requests on github, bzr + laucnhapd is MUCH nicer :-( | 06:51 |
| wallyworld | axw: i just did a go get -u originally | 06:51 |
| wallyworld | i guess i could rerun that? | 06:52 |
| axw | wallyworld: so, I think what you probably should've done is branched, and pushed the branch to GitHub | 06:52 |
| axw | but it's a bit late | 06:52 |
| axw | no, your push would've pushed to the master branch | 06:52 |
| wallyworld | axw: i forked | 06:52 |
| wallyworld | and then cloned | 06:52 |
| wallyworld | that's what the online help said to do | 06:53 |
| axw | wallyworld: right, but forking on github creates a repo + branch | 06:53 |
| axw | branches | 06:53 |
| axw | so you've modified the master branch in your fork | 06:53 |
| wallyworld | my push went to my copy of the branch | 06:53 |
| wallyworld | yes | 06:53 |
| axw | yep... now what do you want to do exactly? | 06:53 |
| axw | wallyworld: bear in mind I'm a git noob too :) | 06:54 |
| wallyworld | revert, on disk, back to what was there before i deleted the go get version and clone my version | 06:54 |
| wallyworld | ah, i thought you were a git master :-) | 06:54 |
| wallyworld | i used git *for the very first time* just 10 minute ago | 06:54 |
| axw | wallyworld: probably better just to create a new branch off the old commit | 06:54 |
| wallyworld | wouldn't checkout/clone be better? i wonder what go get does | 06:55 |
| wallyworld | i could just rm the dir and run go get again | 06:55 |
| axw | you could, but you'll get the same stuff back | 06:56 |
| wallyworld | that's what i want for now | 06:56 |
| axw | wallyworld: you want the same thing you pushed? | 06:56 |
| axw | that's what you'll get back | 06:56 |
| wallyworld | i'm just trying to figure out how the do the equivalent of "bzr switch" | 06:56 |
| axw | "git checkout <branch>" | 06:57 |
| wallyworld | and that will overwrite what's there? | 06:57 |
| wallyworld | ta, will try that | 06:57 |
| axw | that'll change your working tree | 06:57 |
| wallyworld | coolio, that's what i want | 06:57 |
| wallyworld | it's going to be "fun" switching over | 06:58 |
| axw | it's not so bad, just a bit different | 06:59 |
| wallyworld | i've read and heard that bzr's model and workflow is *much* nicer, so it will be a pain i think | 06:59 |
| davecheney | wallyworld: jam1 axw, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 | 07:19 |
| davecheney | still hasn't landed | 07:19 |
| davecheney | can someone kick the bot ? | 07:19 |
| wallyworld | sure | 07:19 |
| davecheney | ta much | 07:20 |
| wallyworld | Preparing to merge https://code.launchpad.net/~dave-cheney/juju-core/105-fix-lp-1298789 | 07:23 |
| wallyworld | tests running | 07:23 |
| davecheney | wallyworld: right | 07:24 |
| davecheney | thanks for checking | 07:24 |
| wallyworld | np | 07:24 |
| davecheney | tests take 30 mins on my laptop with one cpu | 07:25 |
| davecheney | i can imagine they are even slower on canonistack | 07:25 |
| wallyworld | oh yes | 07:25 |
| rogpeppe | mornin' all | 07:32 |
| davecheney | rogpeppe: o/ | 07:33 |
| davecheney | while we're waiting for the bot, https://codereview.appspot.com/81330044 | 07:33 |
| rogpeppe | davecheney: good call - i've been meaning to do that for a while | 07:34 |
| davecheney | rogpeppe: and then I can change SetAddresses to be var arg | 07:34 |
| davecheney | and remove all the use of NewAddresses | 07:34 |
| rogpeppe | davecheney: that doesn't seem quite right - addresses have more info than is just in the string | 07:35 |
| davecheney | rogpeppe: indeed, that was the subject of todays bug | 07:36 |
| davecheney | NewAddress always creates an address with scope NetworkUnknown | 07:36 |
| davecheney | https://code.launchpad.net/~dave-cheney/juju-core/105-fix-lp-1298789/+merge/213198 | 07:36 |
| rogpeppe | davecheney: are we using NewAddress in production code? | 07:36 |
| davecheney | https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 | 07:36 |
| rogpeppe | davecheney: we shouldn't really. | 07:36 |
| davecheney | rogpeppe: i'm going to do two things | 07:36 |
| davecheney | 1. make the caller always specify the scope | 07:36 |
| davecheney | 2. make sure we're only using it in tests | 07:37 |
| davecheney | rogpeppe: actually, if we do 1 then 2 may not be necssary because it will become less dangerous to call that function | 07:38 |
| rogpeppe | davecheney: that seems ok to me, except that i always presumed that Unknown was there for when a provider genuinely doesn't know the scope of an address | 07:38 |
| davecheney | rogpeppe: unknown can be returned for both a public and private address | 07:39 |
| davecheney | that seems wrong | 07:39 |
| rogpeppe | davecheney: i'm not sure | 07:39 |
| rogpeppe | davecheney: we should talk to mgz about this - it's his scheme | 07:39 |
| rogpeppe | davecheney: the other thing i'd like to do with addresses is drop the explicit type field | 07:40 |
| davecheney | rogpeppe: have a look at the bug attached to this one, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 | 07:40 |
| rogpeppe | davecheney: that's not a production code bug, is it? | 07:41 |
| === vladk|offline is now known as vladk | ||
| vladk | goog morning | 07:42 |
| vladk | good morning | 07:42 |
| rogpeppe | vladk: hiya | 07:44 |
| rogpeppe | axw: you've got a review: https://codereview.appspot.com/81700043/ | 07:54 |
| axw | thanks | 07:55 |
| vladk | dimitern: morning | 07:58 |
| axw | rogpeppe: for client caching addrs, is it reasonable to only do it when using the configstore? and assume that Environ.StateInfo will get updated addresses too? | 07:59 |
| dimitern | morning | 07:59 |
| rogpeppe | dimitern: hiya | 07:59 |
| axw | morning vladk, dimitern | 07:59 |
| rogpeppe | dimitern: i'd appreciate your thoughts on this: https://codereview.appspot.com/81570043/ | 08:00 |
| dimitern | rogpeppe, looking | 08:00 |
| rogpeppe | dimitern: (particularly after our chat yesterday...) | 08:00 |
| rogpeppe | axw: for the former, i think so | 08:01 |
| rogpeppe | axw: without the configstore, i don't there *is* any way to cache addresses | 08:01 |
| davecheney | axw: didn't you fix this ? http://paste.ubuntu.com/7167180/ | 08:01 |
| axw | rogpeppe: hah, good point :) | 08:01 |
| rogpeppe | axw: i'm not sure what you mean by the latter | 08:01 |
| axw | rogpeppe: well actually... | 08:01 |
| axw | rogpeppe: we may have the configstore, but it may have out of date info | 08:02 |
| axw | rogpeppe: so we try using StateInfo to get addrs from external storage | 08:02 |
| axw | davecheney: looking | 08:02 |
| rogpeppe | axw: nothing should be using StateInfo | 08:02 |
| davecheney | axw: i saw you proposed a fix yesterday | 08:02 |
| davecheney | maybe that hasn't laneded | 08:02 |
| davecheney | i'm pretty sure i'm up to date | 08:02 |
| axw | davecheney: I thought so too, but maybe not :( | 08:02 |
| rogpeppe | axw: because nothing connects directly to mongo | 08:02 |
| axw | rogpeppe: I'm talking about environs.Environ.StateInfo, which gets provider-state from storage | 08:03 |
| axw | you know, the one we chatted about the other day | 08:03 |
| * rogpeppe feels bad about tests depending on map ordering. | 08:03 | |
| davecheney | rogpeppe: go 1.3 for the win | 08:03 |
| rogpeppe | axw: ah yes, i think it's reasonable to assume that the info from StateInfo (actually we'll rename it to APIInfo soon) is maintained | 08:04 |
| * rogpeppe will try running tests on tip | 08:05 | |
| axw | rogpeppe: excellente, thanks | 08:07 |
| axw | rogpeppe: you may not have seen my email yet, so: is the APIHostPorts client API still necessary if we return them via Login? | 08:08 |
| axw | I would prefer to do it via Login | 08:08 |
| rogpeppe | axw: i think it does no harm - we can leave it in | 08:08 |
| axw | ok | 08:08 |
| rogpeppe | axw: but i think we should return the results from Login anyway | 08:08 |
| axw | rogpeppe: yeah, that's what I am working on right now | 08:09 |
| axw | rogpeppe: simpler and more efficient | 08:09 |
| rogpeppe | axw: <3 | 08:09 |
| fwereade | guys, today may be challenging, cath is away and laura is a bit sick | 08:20 |
| fwereade | upside: she's fairly subdued | 08:21 |
| fwereade | downside: I will be off and on at complete random today | 08:21 |
| fwereade | just flag me in here with reviews you need and I'll get to them as I can | 08:21 |
| dimitern | fwereade, take a look at this https://codereview.appspot.com/81570043/ i'd like to know your thoughts as well | 08:25 |
| rogpeppe | dimitern: fwereade has already reviewed it (although perhaps not completely) | 08:28 |
| dimitern | rogpeppe, ah, sorry, haven't reached the end | 08:29 |
| dimitern | rogpeppe, i don't really get why do you have a clone method on the configsetteronly? | 08:39 |
| dimitern | rogpeppe, imo once you have configsetteronly, you should've got it from a clone of an existing config | 08:40 |
| dimitern | rogpeppe, what if you forget to call clone? | 08:40 |
| rogpeppe | dimitern: there's not really any point on having it on the Config, because when you've got a Config, it should be immutable | 08:40 |
| rogpeppe | dimitern: if you've got a mutable config (ConfigSetter or ConfigSetterWriter) you are responsible for cloning the config to hand out to potentially concurrent clients | 08:41 |
| dimitern | rogpeppe, and you're handing out a clone with a clone method itself? | 08:42 |
| rogpeppe | dimitern: that's reasonable, i think, because that's the case in only a very small amount of code | 08:42 |
| rogpeppe | dimitern: ? | 08:42 |
| rogpeppe | dimitern: Clone returns Config, which doesn't have a clone method | 08:42 |
| dimitern | rogpeppe, oh ok | 08:43 |
| dimitern | rogpeppe, reviewed | 08:59 |
| rogpeppe | dimitern: thanks a lot | 09:10 |
| rogpeppe | dimitern: responded | 09:11 |
| dimitern | rogpeppe, will look in a moment | 09:13 |
| dimitern | rogpeppe, i'm confused about upgrades + migrate config | 09:15 |
| dimitern | rogpeppe, istm now we're migrating the config in-memory only and then what? | 09:15 |
| rogpeppe | dimitern: the caller is responsible for actually writing the config | 09:16 |
| dimitern | rogpeppe, i'm asking about that particular caller | 09:16 |
| dimitern | rogpeppe, the upgrade step | 09:16 |
| rogpeppe | dimitern: the upgrade step doesn't need to write the config | 09:17 |
| dimitern | rogpeppe, you've changed migrate not to write, but not changed agentconfig upgrade step calling migrate to write after calling migrate | 09:17 |
| dimitern | rogpeppe, that's its only purpose in life | 09:17 |
| rogpeppe | dimitern: the write happens outside of PerformUpgrade | 09:17 |
| dimitern | rogpeppe, migrate and write the updated config | 09:17 |
| rogpeppe | dimitern: which is why PerformUpgrade is called in a ChangeConfig-called function | 09:18 |
| dimitern | rogpeppe, have you tested this with an actual live test upgrading 1.16 to 1.18? | 09:18 |
| rogpeppe | dimitern: not yet | 09:18 |
| dimitern | rogpeppe, please do :) | 09:19 |
| rogpeppe | dimitern: will do | 09:19 |
| rogpeppe | dimitern: is there a particular reason you can see why this scheme won't work? | 09:19 |
| dimitern | rogpeppe, i'm not saying it won't work, i'm just concerned not to introduce regressions | 09:20 |
| rogpeppe | dimitern: ok, that's cool | 09:20 |
| axw | rogpeppe: last one, https://codereview.appspot.com/81780043 | 09:25 |
| axw | rogpeppe: I'll look at parallel connection in the API client on Monday, unless you have something else more important? | 09:26 |
| rogpeppe | axw: thankjs | 09:26 |
| rogpeppe | axw: i'll have a think | 09:26 |
| axw | nps | 09:26 |
| dimitern | rogpeppe, lgtm | 09:29 |
| wwitzel3 | hello | 09:36 |
| davecheney | stupid bot, how long is this going to take, https://code.launchpad.net/~dave-cheney/juju-core/104-fix-lp-1298703/+merge/213195 | 09:40 |
| rogpeppe | davecheney: looks like the bot is hung | 09:42 |
| rogpeppe | davecheney: i'll kick it | 09:42 |
| davecheney | thanks | 09:43 |
| davecheney | otherwise i'll check it tomorrow | 09:43 |
| dimitern | davecheney, hey | 09:43 |
| davecheney | dimitern: hello | 09:43 |
| davecheney | i'm not really here | 09:43 |
| dimitern | davecheney, how do you run juju on ppc btw? | 09:43 |
| davecheney | i have a scotch downstairs which is getting impatient | 09:43 |
| davecheney | dimitern: how do I run it ? | 09:43 |
| davecheney | go build launchpad.net/juju-core/... | 09:43 |
| davecheney | mayube I don't understand the question | 09:44 |
| rogpeppe | ds | 09:44 |
| voidspace | morning all | 09:44 |
| rogpeppe | davecheney: bot now going again | 09:44 |
| davecheney | thanks | 09:44 |
| davecheney | this is the changing of the guard | 09:44 |
| rogpeppe | davecheney: it's got to axw's branch first though, i'm afraid | 09:44 |
| davecheney | rogpeppe: no worries | 09:44 |
| davecheney | not much hurry now | 09:44 |
| davecheney | me -> EOW | 09:44 |
| rogpeppe | voidspace: hiya | 09:44 |
| dimitern | davecheney, I mean on a vm or what machine | 09:44 |
| davecheney | dimitern: we have ppc hardware available | 09:45 |
| dimitern | davecheney, nice! | 09:45 |
| davecheney | dimitern: do you want a machine | 09:45 |
| davecheney | or are you just curious | 09:45 |
| davecheney | you can have a machine | 09:45 |
| davecheney | they are for the juju team | 09:45 |
| dimitern | davecheney, nah, just curious :) | 09:45 |
| davecheney | but it is a non zero amout of work | 09:45 |
| dimitern | davecheney, i have enough on my plate already | 09:45 |
| davecheney | dimitern: right, yes, we have some ppc machines which are cut up into vms so we can each work without having to negotiate for port 17017 and things | 09:46 |
| dimitern | davecheney, good to know, i assume arm vms as well? | 09:46 |
| davecheney | dimitern: not so much | 09:46 |
| davecheney | these ppc machines are kvm vms | 09:46 |
| davecheney | so they are mostly wire speed | 09:46 |
| davecheney | the arm stuff is all inside the arm fast model simulator | 09:46 |
| davecheney | it uses a lot more cpu power, and produce much less impressive results | 09:47 |
| davecheney | for 32 bit arm ubuntu has an AMI which runs userland inside QEMU which is ok | 09:47 |
| davecheney | but still very slow | 09:47 |
| davecheney | that is what sinzui uses for testing and releasing the current arm builds | 09:47 |
| davecheney | adieu | 09:49 |
| fwereade | rogpeppe, 530-lose-hardware-characteristics | 10:09 |
| rogpeppe | fwereade: oh darn, it failed | 10:11 |
| rogpeppe | fwereade: will fix | 10:11 |
| fwereade | rogpeppe, cheers | 10:11 |
| rogpeppe | fwereade: re-approved | 10:15 |
| rogpeppe | afk | 10:17 |
| rogpeppe | back | 10:23 |
| perrito666 | aghh, test, why wont you fail | 10:39 |
| natefinch | perrito666: not a problem I often have, sadly | 10:40 |
| perrito666 | natefinch: I am really having problems replicating it :p | 10:41 |
| natefinch | mgz, fwereade: standup | 10:47 |
| mgz | gah | 10:52 |
| perrito666 | mgz: aghh our ticket is still on todo :p | 10:55 |
| mgz | well, we're not really doing what that ticket says :) | 10:56 |
| perrito666 | haha | 10:56 |
| perrito666 | mgz: did you get my full of not wonderful news mail? | 10:57 |
| mgz | I did, sorry, should have replied | 10:59 |
| mgz | I think the subcommand thing should just work though? | 10:59 |
| perrito666 | ill re read it, i already forgot what I wrote in :p | 11:00 |
| perrito666 | it was late | 11:00 |
| voidspace | new rule - we're not allowed to create any more types called "State" | 11:07 |
| natefinch | no new files called cloudinit.go or bootstrap.go | 11:11 |
| wwitzel3 | so just for myself, I started fixing go vet warnings, mainly as a way to force myself to look them up and learn them and explore different types user types in juju-core. My question is, do we ever merge cleanup like that? should I propse this or should I just toss it? | 11:20 |
| mgz | mergeit | 11:22 |
| natefinch | definitely. Go vet is almost always complaining about something useful that might bite us later (or might even be biting us now and we don't realize it) | 11:23 |
| natefinch | I thought lbox ran go vet? | 11:24 |
| wwitzel3 | I was of that thought as well, but when I went to run go vet manually I didn't even have it installed and lbox never complained I didn't have it. | 11:25 |
| wwitzel3 | natefinch: so it might only run it if you have it? | 11:25 |
| fwereade | natefinch, rogpeppe: how does MA-HA fit in with that agent-config branch of roger's? | 11:28 |
| rogpeppe | fwereade: it's gonna need some work | 11:28 |
| natefinch | fwereade: rogpeppe said it breaks some stuff in our branch | 11:28 |
| fwereade | natefinch, rogpeppe: yeah, I'm getting conflict twitches as I read it | 11:29 |
| rogpeppe | fwereade: i think i know what to do - i plan on working on it next | 11:29 |
| rogpeppe | fwereade: in conjunction with nate'n'wayne | 11:29 |
| rogpeppe | fwereade: the MA-HA branch as is has potential problems with overwriting previous config settings, which was why i did what i did yesterday as a priority | 11:30 |
| natefinch | rogpeppe: was there stuff that was broken in our branch? I really wanted to get it in ASAP and adding more work to it is disappointing | 11:30 |
| rogpeppe | natefinch: i believe there was | 11:30 |
| fwereade | rogpeppe, natefinch, wwitzel3: do you guys all have something productive to work on in the face of this? | 11:31 |
| natefinch | fwereade: I have to tweak the local provider's mongo name, from a review comment from andrew, that should be orthogonal to roger's stuff | 11:32 |
| rogpeppe | natefinch, wwitzel3: if you find yourself at a loose end, there are a good few things that are independently workable on | 11:32 |
| voidspace | simple review for someone: https://codereview.appspot.com/81850043 | 11:32 |
| rogpeppe | natefinch, wwitzel3: i'm just writing a final test for my config branch, then i'll be with you | 11:32 |
| wwitzel3 | rogpeppe, fwereade : ok, I was planning on doing a review of the agent config stuff this morning and then after that I can work on what ever is needed or pair. | 11:33 |
| natefinch | rogpeppe: ok | 11:33 |
| rogpeppe | wwitzel3: more eyes always appreciated :-) | 11:33 |
| wwitzel3 | PTAL https://codereview.appspot.com/81570045/ (non-priority cleanup branch) | 11:34 |
| rogpeppe | voidspace: LGTM | 11:36 |
| fwereade | rogpeppe, natefinch: so, shall I WIP MA-HA? | 11:41 |
| rogpeppe | fwereade: i think that's fair | 11:41 |
| natefinch | yep | 11:42 |
| voidspace | rogpeppe: thanks | 11:53 |
| voidspace | rogpeppe: but if I remove that error path then my branch is even more trivial! | 11:54 |
| voidspace | rogpeppe: but yeah, true enough... :-) | 11:54 |
| rogpeppe | voidspace: trivial branches are good :) | 11:54 |
| voidspace | rogpeppe: I can hear the flaming lips... | 11:54 |
| rogpeppe | voidspace: you can | 11:54 |
| rogpeppe | voidspace: through my headphones, or is there some bleedthrough to the computer? | 11:54 |
| voidspace | voidspace: from the headphones I assume | 11:55 |
| rogpeppe | voidspace: i'll mute | 11:55 |
| voidspace | rogpeppe: hah, I wasn't complaining :-) | 11:55 |
| voidspace | but fine | 11:55 |
| voidspace | rogpeppe: I'm making both changes you suggest and then I'll approve | 11:55 |
| rogpeppe | voidspace: great | 11:55 |
| === vladk is now known as vladk|lunch | ||
| axw | rogpeppe: re APIHostPorts failing in Login, and it being a warning vs. error ... | 12:16 |
| rogpeppe | axw: oh yes? | 12:16 |
| axw | rogpeppe: say the state method had a bug in it. how would we fix it? | 12:16 |
| axw | upgrading requires that we connect to the API | 12:16 |
| axw | kind of a problem in general... | 12:16 |
| rogpeppe | axw: interesting point | 12:17 |
| rogpeppe | axw: login also requires interacting with the state | 12:17 |
| rogpeppe | axw: i think at some point we have to rely on our infrastructure working | 12:17 |
| axw | yeah, I'm just thinking about minimising the surface area for defects. but this isn't really increasing it much | 12:18 |
| axw | I'll make it fatal | 12:18 |
| rogpeppe | axw: as a last resort, it would be possible to directly connect to mongo to change the agent version | 12:18 |
| axw | yep | 12:19 |
| rogpeppe | axw: thanks. i think it's more useful as a fatal error than potentially returning empty API addresses | 12:19 |
| rogpeppe | fwereade: am adding a test for PerformUpgrades returning an error. unfortunately i'm pretty sure that a substantial proportion of jujud UpgradeSuite is crackful | 12:20 |
| rogpeppe | fwereade: it seems to rely on knowing what upgrades will be performed, but that's information that will change over time, and is really private to the upgrades package | 12:21 |
| fwereade | rogpeppe, ha, only testable by side-effect again? goddamn jujud | 12:21 |
| rogpeppe | fwereade: no, it's easy enough to test properly | 12:21 |
| rogpeppe | fwereade: (by mocking PerformUpgrades) | 12:22 |
| rogpeppe | fwereade: i've already done that, but i'm just checking that you agree the upgrade-specific tests shouldn't be there | 12:22 |
| rogpeppe | fwereade: i'm just trying to verify that the upgrades package itself has equivalent tests | 12:24 |
| fwereade | rogpeppe, I agree, they should only be tested enough in jujud to reassure us that jujud does run upgrades | 12:30 |
| rogpeppe | fwereade: thanks | 12:30 |
| perrito666 | man I must be the first person ever to be frustrated that a test is passing | 12:31 |
| axw | heh, intermittent failure? :) | 12:32 |
| perrito666 | axw: sort of, only fails on CI and sinzui's machine | 12:33 |
| perrito666 | I even created a stream to test this hoping to make it fail... yet it works | 12:33 |
| axw | oh environmental, even better | 12:33 |
| perrito666 | altough it is fun, makes suspense, I have to wait a decent amount of time for the test to finish, so it builds suspense a lot while I do other things | 12:34 |
| wwitzel3 | rogpeppe: for what it's worth, review for the agent stuff is up | 12:35 |
| rogpeppe | wwitzel3: thanks | 12:41 |
| rogpeppe | fwereade: if it's ok, i'd like to leave adding that test for another CL - it's a substantial refactor of UpgradeSuite, and pretty much orthogonal to the rest of that branch (and it's a preexisting thing too) | 12:43 |
| === vladk|lunch is now known as vladk | ||
| fwereade | rogpeppe, I has a bit of a sad about removing the old tests and not replacing them | 13:09 |
| rogpeppe | fwereade: i don't *think* i've removed any tests | 13:10 |
| fwereade | rogpeppe, ah, ok then, I got the impression that there were some in jujud that you were getting rid of | 13:10 |
| rogpeppe | fwereade: not right now, but i intend to | 13:11 |
| rogpeppe | fwereade: because they're inappropriate | 13:11 |
| fwereade | rogpeppe, that's great, cheers, sorry misunderstanding | 13:11 |
| rogpeppe | fwereade: (the tests for specific upgrade behaviour) | 13:11 |
| bodie_ | morning all | 13:11 |
| rogpeppe | fwereade: i just don't want to burden this CL with the UpgradeSuite revamp | 13:11 |
| rogpeppe | bodie_: hiya | 13:12 |
| fwereade | bodie_, heyhey | 13:12 |
| fwereade | rogpeppe, +1 | 13:12 |
| rogpeppe | fwereade: does it LGTY then, given that? | 13:12 |
| bodie_ | :) | 13:12 |
| fwereade | rogpeppe, it's had 2 LGTMs and I liked the direction, I can rereview if there's something in particular? | 13:13 |
| rogpeppe | fwereade: no, that's fine | 13:14 |
| fwereade | rogpeppe, cool | 13:14 |
| rogpeppe | fwereade: i always like it if everyone explicitly LGTMs :-) | 13:14 |
| natefinch | wwitzel3, rogpeppe: do you guys have a hangout I should join? I'm just working on undoing my changes to local provider mongo service name | 13:37 |
| dimitern | rogpeppe, fwereade, mgz, vladk, quick review https://codereview.appspot.com/81550046 ? | 13:38 |
| rogpeppe | natefinch: i'm in a hangout with michael currently, but i can join you two | 13:38 |
| rogpeppe | natefinch: (i'm just testing environment upgrades) | 13:38 |
| dimitern | fwereade, that's what you wanted ^^ | 13:40 |
| fwereade | dimitern, looking | 13:40 |
| natefinch | rogpeppe: not necessary right now. Once we need to figure out what changes to make for the config stuff you did | 13:40 |
| rogpeppe | natefinch: ok | 13:41 |
| rogpeppe | natefinch: i'll start working on that, because i think i know what needs to happen | 13:41 |
| rogpeppe | natefinch: unless you want to do it, of course | 13:41 |
| natefinch | rogpeppe: I think you're in a much better position to do it, since you made the config changes | 13:42 |
| rogpeppe | natefinch: yeah | 13:42 |
| fwereade | dimitern, LGTM | 13:43 |
| dimitern | fwereade, thanks! | 13:44 |
| rogpeppe | hmm | 13:51 |
| rogpeppe | 2014-03-28 13:42:07 INFO juju.worker.upgrader error.go:32 upgraded from 1.17.7.1-precise-amd64 to 1.16.6-precise-amd64 ("https://juju-dist.s3.amazonaws.com/tools/releases/juju-1.16.6-precise-amd64.tgz") | 13:51 |
| natefinch | ummmm | 13:53 |
| mattyw | mgz, dimitern any idea if the landing bot is on holiday today? | 13:55 |
| rogpeppe | mattyw: i'll have a look | 13:55 |
| rogpeppe | mattyw: yeah, it's stuck | 13:56 |
| rogpeppe | mattyw: i'll kick it | 13:57 |
| * rogpeppe wished he knew why we get mongods left over from tests | 13:57 | |
| rogpeppe | mattyw: it's going again | 13:58 |
| rogpeppe | this is worryingly weird. here's an excerpt from the relevant machine-0 log: http://paste.ubuntu.com/7168627/ | 14:20 |
| rogpeppe | can anyone think of some way that that sequence of events is possible? | 14:20 |
| rogpeppe | fwereade, dimitern: ^ | 14:20 |
| rogpeppe | dimitern: FWIW, apart from this issue the upgrade worked fine | 14:21 |
| natefinch | how do I edit my last commit message (presuming I haven't pushed yet)? | 14:25 |
| wwitzel3 | natefinch: you can use uncommit | 14:26 |
| wwitzel3 | natefinch: and then just do another commit | 14:26 |
| natefinch | wwitzel3: thanks, I saw uncommit moments after I asked. | 14:27 |
| wwitzel3 | natefinch: no shame in teddy bear questions | 14:27 |
| dimitern | rogpeppe, that's moot | 14:27 |
| natefinch | wwitzel3: yep | 14:28 |
| rogpeppe | dimitern: how so? | 14:28 |
| dimitern | rogpeppe, you'll need to change the version from 1.17.7 to 1.18.0 before the upgrade (and rebuild) | 14:28 |
| natefinch | wwitzel3, rogpeppe: btw I merged trunk into my branch again.... trying to keep up to date so it won't bitrot | 14:28 |
| rogpeppe | dimitern: upgrade steps don't trigger upgrading to 1.17? | 14:28 |
| rogpeppe | dimitern: ok, i'll start again | 14:29 |
| rogpeppe | dimitern: it's still a *really* weird issue | 14:29 |
| rogpeppe | dimitern: and it worries me | 14:29 |
| dimitern | rogpeppe, no, because 1.18 is the target | 14:29 |
| rogpeppe | dimitern: right, ok | 14:29 |
| dimitern | rogpeppe, what's the weird thing about that log excerpt? | 14:30 |
| rogpeppe | dimitern: i actually think that upgrade steps should be targetted to minor versions too | 14:30 |
| rogpeppe | dimitern: the weird thing is that the environ config returned with an agent-version of 1.17; but then a subsequent call to DesiredAgentVersion returned 1.16 | 14:31 |
| rogpeppe | dimitern: which caused a unit agent to try to downgrade | 14:31 |
| rogpeppe | dimitern: which caused it to break | 14:31 |
| rogpeppe | dimitern: rather, it *did* downgrade, but the 1.16 logic then assumed that the config file was 1.12 because there was no version file, and 1.16 config isn't valid 1.12 config. | 14:32 |
| dimitern | rogpeppe, hmm.. well, 1.17 is not a desired version to upgrade to from 1.16 for sure | 14:32 |
| rogpeppe | dimitern: yes it is, if you've done upgrade-juju --upload-tools | 14:33 |
| dimitern | rogpeppe, it still isn't | 14:33 |
| dimitern | rogpeppe, it's a dev version | 14:34 |
| rogpeppe | dimitern: really? you're not allowed to upgrade to a dev version, even if you ask to? | 14:34 |
| dimitern | rogpeppe, so upgrade-juju won't try to upgrade you to it automatically | 14:34 |
| dimitern | rogpeppe, that's not the way to ask | 14:34 |
| dimitern | rogpeppe, the way to ask is --version= (i.e. force it) | 14:34 |
| rogpeppe | dimitern: i thought --upload-tools asked | 14:34 |
| rogpeppe | dimitern: otherwise upgrade-juju --upload-tools is useless | 14:35 |
| dimitern | rogpeppe, no, it just uploads doesn't change the logic | 14:35 |
| rogpeppe | dimitern: because you don't know the version that it will choose | 14:35 |
| mattyw | does anyone else see this error in cmd/juju? http://paste.ubuntu.com/7168714/ | 14:35 |
| rogpeppe | dimitern: (anyway, it demonstrably *does* upgrade, even if it perhaps should not) | 14:35 |
| dimitern | rogpeppe, --upload-tools --version=x.y.z does what you'd expect, but for the upgrade steps to trigger, change version to 1.18.0, then you just need to rebuild and use --upload-tools only, no --version | 14:36 |
| rogpeppe | dimitern: so why did my environment upgrade to 1.17 when i didn't specify --version? would you consider that a bug? | 14:38 |
| rogpeppe | dimitern: i still think that if you use --upload-tools, it should use that version, otherwise why would you use that flag? | 14:39 |
| dimitern | rogpeppe, read the help | 14:39 |
| dimitern | rogpeppe, of upgrade-juju - it's all explained | 14:39 |
| dimitern | rogpeppe, you get the default behavior when running it without --version and --upload-tools | 14:40 |
| dimitern | rogpeppe, otherwise you'd get what you'd get :) | 14:40 |
| rogpeppe | dimitern: so do you think there's a bug currently? | 14:40 |
| dimitern | rogpeppe, because that's the way to upload tools so they can be among the ones to be considered? | 14:41 |
| dimitern | rogpeppe, no | 14:41 |
| dimitern | rogpeppe, it's as designed | 14:41 |
| rogpeppe | dimitern: i thought you said that using --upload-tools shouldn't consider the uploaded tools if you're currently on a non-dev version | 14:41 |
| rogpeppe | dimitern: but in my case, it definitely did | 14:42 |
| * rogpeppe tries to understand the upgrade-juju help | 14:42 | |
| dimitern | rogpeppe, look at the code as well | 14:42 |
| rogpeppe | [14:32:56] <dimitern> rogpeppe, hmm.. well, 1.17 is not a desired version to upgrade to from 1.16 for sure | 14:42 |
| rogpeppe | dimitern: doesn't that mean there's a bug? | 14:43 |
| dimitern | rogpeppe, upload-tools does not change the behavior of what's considered desired | 14:43 |
| rogpeppe | dimitern: right, so since i didn't specify --version, it should not have chosen 1.17 | 14:44 |
| rogpeppe | dimitern: because the current version was 1.16 | 14:44 |
| dimitern | rogpeppe, the logic is still the same, it just uploads or not; --version changes what gets considered | 14:44 |
| rogpeppe | dimitern: but since it *did* choose 1.17, i think that counts as a bug | 14:44 |
| dimitern | rogpeppe, the current version was "juju version" | 14:44 |
| dimitern | rogpeppe, i.e. cli's current version | 14:44 |
| rogpeppe | dimitern: oh really? | 14:44 |
| rogpeppe | dimitern: that's too bizarre for words | 14:45 |
| rogpeppe | dimitern: the "current agent version" is the command line tool's version? | 14:45 |
| dimitern | rogpeppe, look at initVersions - that's where most of the magic happens | 14:46 |
| dimitern | rogpeppe, I'm too maas-distracted to be a credible source without switching too much context | 14:46 |
| rogpeppe | dimitern: FWIW i think it's initVersions1dot16 that's relevant here | 14:47 |
| dimitern | rogpeppe, that's correct | 14:49 |
| rogpeppe | natefinch: am currently resolving conflicts, FYI | 15:11 |
| natefinch | rogpeppe: coool | 15:12 |
| rogpeppe | natefinch: well, the conflicts are resolved. now for the meat of it... | 15:18 |
| natefinch | rogpeppe: heh | 15:19 |
| wwitzel3 | rogpeppe, natefinch: is it about time for a hangout session then? | 15:20 |
| rogpeppe | wwitzel3: i'd be happy to | 15:20 |
| rogpeppe | wwitzel3: https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1 ? | 15:21 |
| rogpeppe | natefinch: https://plus.google.com/hangouts/_/7ecpj5hnavq7rdcfes1ctdva0s?authuser=1&hl=en | 15:22 |
| === vladk is now known as vladk|offline | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| rogpeppe | voidspace: ping | 16:10 |
| voidspace | rogpeppe: pong :-) | 16:25 |
| dimitern | fwereade, can I get an LGTM on https://codereview.appspot.com/80600044/ so I can integrate it with supportnetworks() and land it later? | 16:35 |
| wwitzel3 | rogpeppe: you mentioned there were some HA tasks that could be done that you wanted to discuss? | 16:36 |
| wwitzel3 | rogpeppe: you ready to talk about those yet? | 16:36 |
| rogpeppe | wwitzel3: yeah, gimme a minute or too | 16:53 |
| rogpeppe | two | 16:53 |
| natefinch | rogpeppe: he's getting lunch, so no rush | 16:53 |
| === hatch__ is now known as hatch | ||
| voidspace | rogpeppe: ping | 17:34 |
| rogpeppe | voidspace: pong | 17:34 |
| voidspace | rogpeppe: we need to handle the case where we're unmarshaling and marshaling data with an address instead of statePort | 17:35 |
| voidspace | rogpeppe: what format are the stateDetails addresses? | 17:35 |
| dimitern | rogpeppe, can you review https://codereview.appspot.com/80600044 by any chance? | 17:35 |
| voidspace | rogpeppe: and as it's a slice of addresses, which should I use? | 17:35 |
| voidspace | rogpeppe: is it the standard foo:port | 17:35 |
| voidspace | rogpeppe: and can I use a naive split to get it - or should I find a proper address parsing function somewhere? | 17:36 |
| voidspace | rogpeppe: connectionDetails is defined in agent.go (at the top) | 17:36 |
| rogpeppe | dimitern: currently overloaded. will do in a bit. | 17:36 |
| voidspace | heh, sorry to add to your burden | 17:36 |
| voidspace | I can dig into this myself if you prefer? | 17:36 |
| dimitern | rogpeppe, cheers, no rush | 17:37 |
| * dimitern is away for a while | 17:40 | |
| rogpeppe | voidspace: i'll join you | 17:40 |
| voidspace | kk | 17:40 |
| voidspace | so it is populated from MgoServer.Addr() | 17:41 |
| wwitzel3 | rogpeppe, natefinch https://codereview.appspot.com/81550047 replicaset MasterHostPort | 18:19 |
| voidspace | rogpeppe: if SplitHostPort(format.StateAddresses[0]) errors should we ignore it or should the unmarshal function return an error? | 18:26 |
| voidspace | rogpeppe: this would mean returning an error for data that we *used* to be able to unmarshal fine | 18:27 |
| voidspace | rogpeppe: on the other hand it would leave us without a StatePort which is probably an error... | 18:27 |
| voidspace | rogpeppe: I'm going to turn it into an error | 18:27 |
| rogpeppe | voidspace: yeah we should definitely error | 18:28 |
| voidspace | rogpeppe: cool | 18:28 |
| voidspace | rogpeppe: actually, we have tests to ensure that we can't write/read an invalid address | 18:33 |
| voidspace | rogpeppe: so it shouldn't be an issue | 18:33 |
| rogpeppe | voidspace: cool | 18:33 |
| voidspace | right, going jogging - back later | 18:37 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| * rogpeppe is done for the day | 19:56 | |
| rogpeppe | g'night all | 19:56 |
| rogpeppe | happy weekends to all too | 19:56 |
| wwitzel3 | EOD for me as well | 19:57 |
| natefinch | see ya wwitzel3 | 20:00 |
| natefinch | & rogpeppe | 20:00 |
| sarnold | why does provider/local/environ.go Destroy() execute sudo itself? | 21:20 |
| perrito666 | sarnold: bc you cannot operate with lxc without sudo (perhaps I missed where was your question going) | 21:27 |
| sarnold | perrito666: I'm just surprised it doesn't just fail. it seems odd to me to hard-code an authentication mechanism in the source code. | 21:28 |
| perrito666 | sarnold: well, I guess since it cannot be run without sudo it makes sense, it is better to run sudo for a particular part than for the whole program (just my opinion) | 21:29 |
| sarnold | perrito666: heh, could be, but it appears to just be recursively calling juju destroy again :) | 21:30 |
| perrito666 | sarnold: ah, that is not nice | 21:32 |
| === hatch__ is now known as hatch | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === arosales_ is now known as arosales | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!