[00:00] <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:01] <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:13] <wallyworld> davecheney: is there simplestreams metadata for ppc64el?
[00:13] <wallyworld> that would be a likely cause
[00:34] <davecheney> wallyworld: in the test fixures ?
[00:35] <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:36] <wallyworld> the missing ppc64el tools metadata
[00:36] <davecheney> wallyworld: in that case I agree
[00:36] <davecheney> let me check quickly
[00:39]  * davecheney flails around a bit
[00:40] <davecheney> wallyworld: where in the source are the test fixtures ?
[00:40] <wallyworld> depends on what tests are filing
[00:41] <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:42] <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:44] <davecheney> afk for a bit
[01:36] <perrito666> eu1Ahloo
[01:36] <perrito666> eu
[01:37] <perrito666> ouch
[01:37] <perrito666> :p
[01:37] <sarnold> not a bad password, as passwords go..
[01:39] <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:41] <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
[03:08] <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:18] <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:19] <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:20] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47]  * 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 :)
[04:11] <davecheney> Spot the bug, Holiday
[04:11] <davecheney> May 2014	07/05/2014 - 07/03/2014	Awaiting Sign Off
[04:21] <davecheney> axw: wallyworld instance.NewAddresses would appear to be a footgun
[04:22] <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:24] <davecheney> axw: should I delete it ?
[04:24] <davecheney> it never sets the scope
[04:25] <davecheney> so its value would be ... dubiois
[04:25] <davecheney> instance.Address{Value: "x.y.z.q"} does the same thing
[04:29] <davecheney> hmm, NewAddress does do more that I just said
[04:29] <davecheney> but it always sets the scope to unknown
[04:36] <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:46] <davecheney> axw: moving it out of the instance API and as a helper
[04:46] <davecheney> that would certainly reduce it's lethality
[04:49] <davecheney> let's see what breaks
[05:04] <davecheney> axw: http://paste.ubuntu.com/7166620/ line 174
[05:04] <davecheney> i wonder if this related to the last issue
[05:10]  * axw looks
[05:11] <axw> davecheney: broken test; it's setting the wrong scope on the "public" address
[05:18] <davecheney> axw: yet it passed up until now ....
[05:18] <axw> davecheney: yes, by implicitly relying on map ordering
[05:19] <axw> it just happened to pick the internal address previously
[05:19] <davecheney> waaaaaaaaaaaaaah
[05:19] <davecheney> ok, will fix
[05:20] <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:21] <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:22] <davecheney> but don't think you need to do it
[05:22] <wallyworld> ok
[05:41] <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:45] <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:51] <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
[06:02] <davecheney> cummon and land my change you mongrel
[06:21] <davecheney> jam1: has the bot crapped itself ?
[06:21] <davecheney> or is it just reeeeeeeeeeely slow ?
[06:25] <davecheney> axw: instance.NewAddress is barely used, only one case in the whole codebase
[06:26] <axw> davecheney: apart from tests? yeah, that one can just be changed to create an address struct literal
[06:30] <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:47] <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:48] <wallyworld> i'd use bzr switch
[06:48] <wallyworld> what's the git equivalent?
[06:50] <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:51] <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:52] <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:53] <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:54] <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:55] <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:56] <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:57] <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:58] <wallyworld> it's going to be "fun" switching over
[06:59] <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
[07:19] <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:20] <davecheney> ta much
[07:23] <wallyworld> Preparing to merge https://code.launchpad.net/~dave-cheney/juju-core/105-fix-lp-1298789
[07:23] <wallyworld> tests running
[07:24] <davecheney> wallyworld: right
[07:24] <davecheney> thanks for checking
[07:24] <wallyworld> np
[07:25] <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:32] <rogpeppe> mornin' all
[07:33] <davecheney> rogpeppe: o/
[07:33] <davecheney> while we're waiting for the bot, https://codereview.appspot.com/81330044
[07:34] <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:35] <rogpeppe> davecheney: that doesn't seem quite right - addresses have more info than is just in the string
[07:36] <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:37] <davecheney> 2. make sure we're only using it in tests
[07:38] <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:39] <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:40] <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:41] <rogpeppe> davecheney: that's not a production code bug, is it?
[07:42] <vladk> goog morning
[07:42] <vladk> good morning
[07:44] <rogpeppe> vladk: hiya
[07:54] <rogpeppe> axw: you've got a review: https://codereview.appspot.com/81700043/
[07:55] <axw> thanks
[07:58] <vladk> dimitern: morning
[07:59] <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
[08:00] <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:01] <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:02] <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:03] <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:04] <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:05]  * rogpeppe will try running tests on tip
[08:07] <axw> rogpeppe: excellente, thanks
[08:08] <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:09] <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:20] <fwereade> guys, today may be challenging, cath is away and laura is a bit sick
[08:21] <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:25] <dimitern> fwereade, take a look at this https://codereview.appspot.com/81570043/ i'd like to know your thoughts as well
[08:28] <rogpeppe> dimitern: fwereade has already reviewed it (although perhaps not completely)
[08:29] <dimitern> rogpeppe, ah, sorry, haven't reached the end
[08:39] <dimitern> rogpeppe, i don't really get why do you have a clone method on the configsetteronly?
[08:40] <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:41] <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:42] <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:43] <dimitern> rogpeppe, oh ok
[08:59] <dimitern> rogpeppe, reviewed
[09:10] <rogpeppe> dimitern: thanks a lot
[09:11] <rogpeppe> dimitern: responded
[09:13] <dimitern> rogpeppe, will look in a moment
[09:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:25] <axw> rogpeppe: last one, https://codereview.appspot.com/81780043
[09:26] <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:29] <dimitern> rogpeppe, lgtm
[09:36] <wwitzel3> hello
[09:40] <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:42] <rogpeppe> davecheney: looks like the bot is hung
[09:42] <rogpeppe> davecheney: i'll kick it
[09:43] <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:44] <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:45] <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:46] <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:47] <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:49] <davecheney> adieu
[10:09] <fwereade> rogpeppe, 530-lose-hardware-characteristics
[10:11] <rogpeppe> fwereade: oh darn, it failed
[10:11] <rogpeppe> fwereade: will fix
[10:11] <fwereade> rogpeppe, cheers
[10:15] <rogpeppe> fwereade: re-approved
[10:17] <rogpeppe> afk
[10:23] <rogpeppe> back
[10:39] <perrito666> aghh, test, why wont you fail
[10:40] <natefinch> perrito666: not a problem I often have, sadly
[10:41] <perrito666> natefinch: I am really having problems replicating it :p
[10:47] <natefinch> mgz, fwereade: standup
[10:52] <mgz> gah
[10:55] <perrito666> mgz: aghh our ticket is still on todo :p
[10:56] <mgz> well, we're not really doing what that ticket says :)
[10:56] <perrito666> haha
[10:57] <perrito666> mgz: did you get my full of not wonderful news mail?
[10:59] <mgz> I did, sorry, should have replied
[10:59] <mgz> I think the subcommand thing should just work though?
[11:00] <perrito666> ill re read it, i already forgot what I wrote in :p
[11:00] <perrito666> it was late
[11:07] <voidspace> new rule - we're not allowed to create any more types called "State"
[11:11] <natefinch> no new files called cloudinit.go or bootstrap.go
[11:20] <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:22] <mgz> mergeit
[11:23] <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:24] <natefinch> I thought lbox ran go vet?
[11:25] <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:28] <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:29] <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:30] <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:31] <fwereade> rogpeppe, natefinch, wwitzel3: do you guys all have something productive to work on in the face of this?
[11:32] <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:33] <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:34] <wwitzel3> PTAL https://codereview.appspot.com/81570045/ (non-priority cleanup branch)
[11:36] <rogpeppe> voidspace: LGTM
[11:41] <fwereade> rogpeppe, natefinch: so, shall I WIP MA-HA?
[11:41] <rogpeppe> fwereade: i think that's fair
[11:42] <natefinch> yep
[11:53] <voidspace> rogpeppe: thanks
[11:54] <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:55] <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
[12:16] <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:17] <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:18] <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:19] <axw> yep
[12:19] <rogpeppe> axw: thanks. i think it's more useful as a fatal error than potentially returning empty API addresses
[12:20] <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:21] <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:22] <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:24] <rogpeppe> fwereade: i'm just trying to verify that the upgrades package itself has equivalent tests
[12:30] <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:31] <perrito666> man I must be the first person ever to be frustrated that a test is passing
[12:32] <axw> heh, intermittent failure? :)
[12:33] <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:34] <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:35] <wwitzel3> rogpeppe: for what it's worth, review for the agent stuff is up
[12:41] <rogpeppe> wwitzel3: thanks
[12:43] <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)
[13:09] <fwereade> rogpeppe, I has a bit of a sad about removing the old tests and not replacing them
[13:10] <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:11] <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:12] <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:13] <fwereade> rogpeppe, it's had 2 LGTMs and I liked the direction, I can rereview if there's something in particular?
[13:14] <rogpeppe> fwereade: no, that's fine
[13:14] <fwereade> rogpeppe, cool
[13:14] <rogpeppe> fwereade: i always like it if everyone explicitly LGTMs :-)
[13:37] <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:38] <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:40] <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:41] <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:42] <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:43] <fwereade> dimitern, LGTM
[13:44] <dimitern> fwereade, thanks!
[13:51] <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:53] <natefinch> ummmm
[13:55] <mattyw> mgz, dimitern any idea if the landing bot is on holiday today?
[13:55] <rogpeppe> mattyw: i'll have a look
[13:56] <rogpeppe> mattyw: yeah, it's stuck
[13:57] <rogpeppe> mattyw: i'll kick it
[13:57]  * rogpeppe wished he knew why we get mongods left over from tests
[13:58] <rogpeppe> mattyw: it's going again
[14:20] <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:21] <rogpeppe> dimitern: FWIW, apart from this issue the upgrade worked fine
[14:25] <natefinch> how do I edit my last commit message (presuming I haven't pushed yet)?
[14:26] <wwitzel3> natefinch: you can use uncommit
[14:26] <wwitzel3> natefinch: and then just do another commit
[14:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <rogpeppe> dimitern: yes it is, if you've done upgrade-juju --upload-tools
[14:33] <dimitern> rogpeppe, it still isn't
[14:34] <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:35] <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:36] <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:38] <rogpeppe> dimitern: so why did my environment upgrade to 1.17 when i didn't specify --version? would you consider that a bug?
[14:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:45] <rogpeppe> dimitern: that's too bizarre for words
[14:45] <rogpeppe> dimitern: the "current agent version" is the command line tool's version?
[14:46] <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:47] <rogpeppe> dimitern: FWIW i think it's initVersions1dot16 that's relevant here
[14:49] <dimitern> rogpeppe, that's correct
[15:11] <rogpeppe> natefinch: am currently resolving conflicts, FYI
[15:12] <natefinch> rogpeppe: coool
[15:18] <rogpeppe> natefinch: well, the conflicts are resolved. now for the meat of it...
[15:19] <natefinch> rogpeppe: heh
[15:20] <wwitzel3> rogpeppe, natefinch: is it about time for a hangout session then?
[15:20] <rogpeppe> wwitzel3: i'd be happy to
[15:21] <rogpeppe> wwitzel3: https://plus.google.com/hangouts/_/canonical.com/juju-core?authuser=1 ?
[15:22] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/7ecpj5hnavq7rdcfes1ctdva0s?authuser=1&hl=en
[16:10] <rogpeppe> voidspace: ping
[16:25] <voidspace> rogpeppe: pong :-)
[16:35] <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:36] <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:53] <rogpeppe> wwitzel3: yeah, gimme a minute or too
[16:53] <rogpeppe> two
[16:53] <natefinch> rogpeppe: he's getting lunch, so no rush
[17:34] <voidspace> rogpeppe: ping
[17:34] <rogpeppe> voidspace: pong
[17:35] <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:36] <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:37] <dimitern> rogpeppe, cheers, no rush
[17:40]  * dimitern is away for a while
[17:40] <rogpeppe> voidspace: i'll join you
[17:40] <voidspace> kk
[17:41] <voidspace> so it is populated from MgoServer.Addr()
[18:19] <wwitzel3> rogpeppe, natefinch https://codereview.appspot.com/81550047 replicaset MasterHostPort
[18:26] <voidspace> rogpeppe: if SplitHostPort(format.StateAddresses[0]) errors should we ignore it or should the unmarshal function return an error?
[18:27] <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:28] <rogpeppe> voidspace: yeah we should definitely error
[18:28] <voidspace> rogpeppe: cool
[18:33] <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:37] <voidspace> right, going jogging - back later
[19:56]  * rogpeppe is done for the day
[19:56] <rogpeppe> g'night all
[19:56] <rogpeppe> happy weekends to all too
[19:57] <wwitzel3> EOD for me as well
[20:00] <natefinch> see ya wwitzel3
[20:00] <natefinch> & rogpeppe
[21:20] <sarnold> why does provider/local/environ.go Destroy() execute sudo itself?
[21:27] <perrito666> sarnold: bc you cannot operate with lxc without sudo (perhaps I missed where was your question going)
[21:28] <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:29] <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:30] <sarnold> perrito666: heh, could be, but it appears to just be recursively calling juju destroy again :)
[21:32] <perrito666> sarnold: ah, that is not nice