[00:06] <wallyworld> thumper: dave around today?
[00:22] <thumper> wallyworld: yeah
[00:22] <wallyworld> thumper: i'm hoping he can look at bug 1335328
[00:23]  * thumper looks at _mup_
[00:23] <wallyworld> it's a follow up from work done last week to fix a windows issue
[00:23] <wallyworld> he did the fix, but curtis says might still be an issue there of somne sort
[00:24] <thumper> hmm... I don't think that davecheney has a test setup to be able to run the tests
[00:24] <thumper> do we have a machine he can use?
[00:24] <thumper> for windows that is
[00:25] <wallyworld> not sure, he ssemed to be able to do the original fix, thought he may be able to follow up
[00:26] <wallyworld> but i can also poke the cloud base guys via nate's squad
[00:29] <davecheney> wallyworld: all I did was looked at where "unknown" was being set as the series
[00:29] <davecheney> and tried to fix that
[00:30] <wallyworld> davecheney: ok, np. the cloud vase guys should fix it since they introduced it
[00:31] <davecheney> wallyworld: ok,
[00:31] <davecheney> osversion.go is all fucked up
[00:31] <davecheney> bunch of logic in thre that is only called from on operating system
[00:32] <wallyworld> yeah :-( i'm pissed it didn't even compile at first
[00:32] <davecheney>         com.Commands = `(gwmi Win32_OperatingSystem).Name.Split('|')[0]`
[00:32] <davecheney>         out, _ := exec.RunCommands(com)
[00:32] <davecheney>         if out.Code != 0 {
[00:32] <davecheney>                 return "unknown"
[00:32] <davecheney>         }
[00:32] <wallyworld> :-(
[00:32] <davecheney> ^ so if gwmi is not installed, and they don't check the error
[00:32] <davecheney> then give up and say it's unknown
[00:32] <wallyworld> nate was going to follow up last week
[00:32] <wallyworld> not sure of the status and he is away this week
[00:33] <wallyworld> not sure how t fark it got past review
[00:33] <davecheney> wallyworld: thumper so, what do you want me to do ?
[00:33] <davecheney> debug it via trial and error ?
[00:33] <davecheney> ^ i'm fine with this
[00:34] <wallyworld> davecheney: i'll follow up with nate's team
[00:34] <davecheney> wallyworld: that blocks me for today
[00:34] <wallyworld> if you are blocked and can fix that would be great :-)
[00:34] <davecheney> understood
[00:34] <thumper> what is gwmi?
[00:34] <wallyworld> i won't get to talk to anyone east coast us till much later this evening
[00:34] <wallyworld> nfi
[00:35] <thumper> is that powershell?
[00:35] <davecheney> y
[00:35] <thumper> why are they ignoring the error? which I'm assuming is in the _
[00:35] <davecheney> hulk smash
[00:36]  * thumper shakes his head
[00:50] <rick_h_> davecheney: do you just need a windows key?
[00:50] <rick_h_> davecheney: I know alexisb was asking about getting some people on the MSDN side of things last week
[00:50] <rick_h_> davecheney: but I can get you a key if you need one
[00:55] <davecheney> rick_h_: thanks, lets see what happens today
[00:55] <rick_h_> davecheney: k
[01:14] <axw> waigani: https://github.com/juju/juju/pull/182#issuecomment-47480573 -- merge failed, please don't set bug Fix Committed until it has
[01:14] <axw> otherwise we may lose track of it
[01:15] <wallyworld> Caxw: hiya, i don't think your fix for replicaset startup (using Direct: true) has landed in 1.20 yet?
[01:15] <axw> wallyworld: I backported something... can't remember which something. I'll check
[01:15] <waigani> axw: right, sorry about that
[01:15] <axw> wallyworld: nope, not in 1.20. I'll backport now
[01:16] <wallyworld> axw: ta, i was looking at CI and local provider upgrade still intermittent
[01:16] <wallyworld> and then i checked the commits
[01:17] <axw> wallyworld: did you see the azure bug I was working on Friday evening? I had put it against 1.20, cos it's a pretty bad first impression of the azure provider
[01:17] <axw> it's not new though
[01:17] <axw> AFAICT anyway
[01:18] <wallyworld> axw: yup, and i agree it should be worked on regardless of any misgivings in the email to the dev list :-)
[01:19] <axw> wallyworld: what email?
[01:20] <wallyworld> axw: ah, just went to team leads, it said that "This issue is more than 6 months old. I am not inclined to divert efforts to fix regressions." from curtis
[01:21] <wallyworld> but i think if we can get a fix in place and it is low risk we should, since we will be highlighting all these other azure improvements
[01:21] <wallyworld> and so people can be expected to try out azure provider
[01:21] <wallyworld> and we don't want them to hit this bug
[01:21] <axw> ok
[01:21] <wallyworld> well, that's imo anyway
[01:22] <axw> wallyworld: so, one possible (kinda big, but I think low risk) way to fix it is to disable apt-get upgrade
[01:22] <axw> it also makes bootstrap significantly faster, at the expense of not having up-to-date packages
[01:23] <wallyworld> hmm, that would then be inconsistent with other providers and i do think we'd want latest packages
[01:23] <axw> wallyworld: I meant across the board
[01:24] <axw> it's a bit arbitrary what we upgrade to, so I just wonder about the value
[01:24] <axw> as opposed to just taking what the server team have released
[01:24] <wallyworld> hmmm. i can see the point
[01:25] <wallyworld> but we can't decide such things
[01:25] <wallyworld> there would be pros and cons
[01:25] <davecheney> wallyworld: thumper
[01:25] <wallyworld> if we can make the current solution work that would be the preference for 1.20
[01:26] <davecheney> i'm going to change version/osVersion() to return a string, error
[01:26] <davecheney> then all the places it returns an error
[01:26] <davecheney> i will wrap it in a mustOsVersion function
[01:26] <axw> wallyworld: sure, I will keep looking to see what's the deal. also, I'm OCR today so gotta take time out from fixing things
[01:26] <davecheney> it is clear that juju cannot operate if it doesn't know the series
[01:26] <davecheney> so we cannot continue at that point
[01:26] <wallyworld> axw: SURE, NP
[01:26] <wallyworld> bah
[01:26] <wallyworld> sorry capslock fail
[01:26] <axw> :)
[01:26] <thumper> davecheney: how is that really changing anything?
[01:27] <thumper> I guess it is more idiomatic
[01:27] <davecheney> thumper: we'll know where the unknown is coming from
[01:27] <davecheney> rather than just being a string "unknown"
[01:27]  * thumper nods
[01:27] <thumper> fair enough
[01:27] <davecheney> that propogates through the app until it finally hits something that tries to use it and fucks out
[01:27] <wallyworld> is it possible to catch the errors instead of panicing?
[01:27] <davecheney> wallyworld: not in the places osVersion is called
[01:27] <davecheney> sorry, not in all the places
[01:28] <wallyworld> ok
[01:28] <davecheney> so you'd have two forms
[01:28] <davecheney> osVersion => string, error
[01:28] <davecheney> mustOsVersion => string or panic
[01:29] <wallyworld> not being familiar with the code, hard to say, but 1 way is always preferable, but if not better to panic than let an impossible value propagate
[01:29] <davecheney> wallyworld: -EDOUBLENEGATIVE
[01:30] <wallyworld> did i leave out a comma
[01:30] <davecheney> wallyworld: it wasn't clear
[01:30] <davecheney> are you for panic'ing or not
[01:31] <wallyworld> prefer 1 way of doing things, but if that's not possible, then i guess a panic is ok since it prevents impossible value being propagated
[01:31] <davecheney> func macOSXSeriesFromKernelVersion(getKernelVersion kernelVersionFunc) string {
[01:31] <davecheney>         majorVersion, err := kernelToMajor(getKernelVersion)
[01:31] <davecheney> look at this !>?>!
[01:31] <davecheney>         if err != nil {
[01:31] <davecheney>                 logger.Infof("unable to determine OS version: %v", err)
[01:31] <davecheney>                 return "unknown"
[01:31] <wallyworld> sigh
[01:31] <wallyworld> how the fark did this get past review
[01:31] <davecheney> so, unknown is being used as a sentinal for error
[01:31] <davecheney> but it happens to be the same type as the valid value
[01:31] <davecheney> so fits throught the hole and leaks
[01:37] <davecheney> func (*CurrentSuite) TestCurrentSeries(c *gc.C) {
[01:37] <davecheney>         s := version.Current.Series
[01:37] <davecheney>         if s == "unknown" {
[01:37] <davecheney>                 s = "n/a"
[01:37] <davecheney>         }
[01:37] <davecheney> more evidence that "unknown" is used as a sentinal for error
[01:41] <axw> menn0: before I land, can you please see my reply on https://github.com/juju/juju/pull/188
[01:41] <axw> menn0: if you've got a suggestion on how to improve that, I'm happy to incorporate
[01:41] <menn0> axw: I was just looking at it now
[01:42] <menn0> axw: give me 2 mins
[01:42] <axw> sure
[01:42] <axw> ta
[01:43] <menn0> axw: I don't quite understand why it's more difficult to do the mongo setup/upgrade work from Run() instead of inside the state worker
[01:44] <axw> menn0: the state worker is started indirectly
[01:44] <menn0> sure the mongo setup work can be done can be done just before the first StartWorker call in Run()
[01:44] <menn0> surely even
[01:44] <axw> there's a "state starter" worker, which starts the state worker when it knows it's a state server
[01:45] <menn0> axw: ok, right. it's getting clearer to me now
[01:45] <axw> menn0: it could, but it'll involve checking for state server info, if we don't have it connecting to the API
[01:46] <menn0> axw: so a jujud can theoretically become at state server any time?
[01:46] <axw> theoretically
[01:46] <menn0> ok I get it then.
[01:46] <axw> there was talk about upgrading non-state servers to state servers
[01:46] <axw> we haven't done that yet
[01:46] <menn0> what you've done makes more sense now.
[01:46] <axw> okey dokey
[01:46]  * menn0 checks the PR one more time
[01:47] <wallyworld> axw: you land the work on both 1.20 and trunk, right
[01:47] <axw> wallyworld: yes I will do
[01:47] <wallyworld> great, once all the 1.20 fixes in the area of upgrades are landed, i'll see if i can run the upgrade job on CI by hand
[01:48] <wallyworld> to get a feel for if it will be happy
[01:49] <menn0> axw, wallyworld: the PR looks ok to me now that I understand the way the state worker is started
[01:49] <wallyworld> \o/
[01:49] <axw> menn0: cheers
[01:50] <menn0> axw, wallyworld: I have been manually doing what the test that was failing in CI was doing  (well with a little script)
[01:50] <menn0> axw, wallyworld: I'm happy to test it again once it lands.
[01:50] <axw> waigani: are you still working on https://github.com/juju/juju/pull/66 ? would you please put "WIP" in the title if it's not ready for review?
[01:50] <menn0> failing test even ...
[01:50] <axw> menn0: thanks
[01:50] <wallyworld> and it's been failing for you too?
[01:51] <menn0> wallyworld: sporadically yes (it's a race after all)
[01:52] <wallyworld> yeah. cool. just checking it *was* failing at least sometimes
[01:52] <axw> davecheney: https://github.com/juju/juju/pull/156   <- is this ready to land?
[01:53] <menn0> wallyworld: I was never able to test the exact scenario because my machine-0 is trusty but thumper has given me a great tip about how to test with the local provider on canonistack (which gives you all precise machines)
[01:53] <wallyworld> ok
[01:53] <davecheney> yes, i believe so
[01:54] <davecheney> tim and william have resolved their differences
[01:54] <davecheney> it's waiting for the 1.20 trunk to sabalise before I merge more difficult to backport changes
[01:54] <axw> ok
[01:54] <wallyworld> menn0: did you log into a canonistack instance and run a local provider env from there? or was there some other magic involved?
[01:55] <waigani> axw: done. also added comment explaining that I'm waiting for the identity stuff to be sorted.
[01:55] <axw> waigani: thanks
[01:55] <menn0> wallyworld: no I have been testing locally so far but will test with a local provider on a canonistack instance once this PR lands
[01:55] <wallyworld> ok
[01:55] <menn0> (that was thumper's trick)
[02:12] <axw> waigani: you have failing tests in your branch if you didn't realise
[02:14] <waigani> axw: on PR 182? I've already fixed it
[02:16] <axw> waigani: not according to the bot
[02:16] <axw> http://juju-ci.vapour.ws:8080/job/github-merge-juju/289/consoleFull
[02:16] <axw> there's a bunch of the usual mongo failures after your ones in cmd/juju
[02:18] <waigani> axw: okay, on it
[02:32] <thumper> Anyone else seen this test failure in state?  export_test.go:58:
[02:32] <thumper> c.Assert(err, gc.IsNil)
[02:32] <thumper> ... value *errors.errorString = &errors.errorString{s:"cannot create log collection: local error: bad record MAC"} ("cannot create log collection: local error: bad record MAC")
[02:33] <thumper>  s.ConnSuite.SetUpTest(c) fails
[02:33] <davecheney> mac relates to the tls handshake between mongodb and juju
[02:33] <thumper> seems intermittent
[02:33] <thumper> race condition?
[02:34] <axw> I've heard in the past that there's a problem with the mongo 2.4 TLS support, and that's fixed in 2.6
[02:34] <axw> we have seen that error occasionally, I think it used to be worse
[02:36] <thumper> wallyworld: https://github.com/juju/juju/pull/194
[02:36] <thumper> axw: ok
[02:37] <davecheney> the hell
[02:37] <davecheney> odessa(~/src/github.com/juju/juju/version) % go test
[02:37] <davecheney> # github.com/juju/juju/version
[02:37] <davecheney> import cycle not allowed in test
[02:37] <davecheney> package github.com/juju/juju/version (test) imports github.com/juju/juju/testing imports github.com/juju/juju/environs/config imports github.com/juju/juju/version
[02:37] <davecheney> FAIL	github.com/juju/juju/version [setup failed]
[02:37] <davecheney> test's for this package don't even pass on darwin at the moment
[02:40] <wallyworld> thumper: looking
[02:41] <wallyworld> +1
[03:00] <thumper> wallyworld: does the merge command work there, or manual
[03:00] <wallyworld> works
[03:37] <davecheney> uh, what the f
[03:37] <davecheney> juju/version tests don't pass at all on osx
[03:37] <davecheney> thumper: OMG
[03:37] <davecheney> i know how this happened
[03:37] <davecheney> someone started to use version.Current in cmd/juju
[03:38] <davecheney> so that meant version.Current.Series had to make sense on any _client_ platofmr
[03:49] <davecheney> https://github.com/juju/juju/pull/195
[03:54] <davecheney>                 reg := regexp.MustCompile("^" + key))
[03:54] <davecheney>                 match := reg.MatchString(series)
[03:54] <davecheney> the award for the most egregious use of regex
[04:00] <thumper> davecheney: wha???
[04:00] <thumper> that makes no sense
[04:00] <thumper> why?
[04:00] <davecheney> strins.HasPrefix(series, key) anyone ?
[04:10] <axw> davecheney: key doesn't contain pattern characters?
[04:11] <davecheney> axw: no idea
[04:11] <davecheney> can't run the tests
[04:11] <davecheney> well, i subtituted osversion_windows for osversion_linux and the tests pass
[04:12] <axw> I mean, HasPrefix is only equivalent if key doesn't have any meta-chars
[04:15] <davecheney> var windowsVersions = map[string]string{ "Microsoft Hyper-V Server 2012 R2": "win2012hvr2", "Microsoft Hyper-V Server 2012":    "win2012hv", "Microsoft Windows Server 2012 R2": "win2012r2", "Microsoft Windows Server 2012":    "win2012", "Windows Storage Server 2012 R2":   "win2012r2", "Windows Storage Server 2012":      "win2012",
[04:15] <davecheney> they aren't regexes
[04:15] <davecheney> the original author just used the wrong hammer
[04:15] <axw> okey dokey
[04:36]  * thumper afk taking kids to ice skating
[04:36] <thumper> bbl
[05:21] <wallyworld> axw: jeez, not having much luck with session closed errors :-(
[05:21] <axw> indeed
[05:21] <axw> driving me crazy
[05:22] <wallyworld> we gotta fix those, maybe we can spike on it next week
[05:22] <axw> yup, sounds like a plan
[05:29] <wallyworld> or this week if we get time after 1.20 goes out
[05:45] <davecheney> wallyworld: axw how can I go from a commit, to the review that supports that commit ?
[05:46] <davecheney> ie, given a hash, how can I find the PR for that hash
[05:46] <wallyworld> hmmm, not sure off hand
[05:46] <davecheney> wallyworld: you're probably not going to like the answer
[05:46] <wallyworld> which is?
[05:46] <davecheney> you can't
[05:46] <wallyworld> wtf
[05:47] <davecheney> wallyworld: https://github.com/juju/juju/commit/f1e95e6507a30fab8a31508f46bfd70753ef452a#diff-0d404a754ae93c99bdaa41896be9ce3e
[05:47] <wallyworld> why is github so popular if it is missing so many key festures
[05:47] <davecheney> i cannot find the PR for this commit
[05:47] <davecheney> wallyworld: unit testing isn't popular in PHP
[05:47] <davecheney> they don't miss what they don't know
[05:47] <wallyworld> sigh
[05:48] <davecheney> wallyworld: can we make the bot insert the link to the PR in the commit message
[05:48] <wallyworld> we can
[05:48] <davecheney> hmm, maybe I just need to find hte "merge commit"
[05:48] <axw> davecheney: yeah, follow the parents up
[05:48] <davecheney> https://github.com/juju/juju/commits/master/version/osversion_windows.go
[05:48] <axw> then the PR for the merge
[05:49] <axw> or.. hmm
[05:49] <axw> that didn't work
[05:49] <davecheney> nup
[05:50] <davecheney> i cannot find who reviewed this file
[05:50] <davecheney> https://github.com/juju/juju/commits/master/version/osversion_windows.go
[05:50] <axw> davecheney: https://github.com/juju/juju/pull/95
[05:50] <axw> I think
[05:51] <davecheney> so, when github does the merge you get
[05:51] <davecheney> https://github.com/juju/errors/commit/6b882ebdb3eb178615c864192a2c1b4502ed86c4
[05:51] <davecheney> when our bot does it
[05:51] <davecheney> we get no record
[05:52] <davecheney> oh the irony
[05:52] <davecheney> https://github.com/juju/juju/pull/95#discussion_r14192953
[05:52] <axw> there's plenty of those merge commits in the log
[05:52] <axw> from the bot
[05:52] <davecheney> nate spotted the problem 5 days ago
[05:52] <davecheney> but the OP never came back to followup
[06:46] <jam1> morning dimitern
[06:47] <dimitern> morning jam
[07:52] <voidspace> morning all
[07:52] <dimitern> hey voidspace
[07:53] <dimitern> voidspace, we should have a quick chat to bring you up-to-speed with the current networking / ipv6 work
[07:53] <voidspace> dimitern: yes, let me get coffee etc first and I'll ping you
[07:54] <dimitern> voidspace, sure, no rush
[07:54] <voidspace> dimitern: thanks :-)
[07:56] <TheMue> morning
[07:56] <TheMue> jam: ping
[08:14] <voidspace> dimitern: ok, hangout?
[08:14] <dimitern> voidspace, just a sec
[08:14] <voidspace> dimitern: no problem
[08:19] <TheMue> jam: no need to pong back anymore, already got it
[08:46] <axw> wallyworld: finally found out the secret sauce to get azure to bootstrap with upgrades
[08:47] <axw> wallyworld: I measured the time for a bootstrap with/without upgrade, apt-get upgrade added 6 minutes
[08:47] <wallyworld> 6 minutes
[08:47] <axw> I'll propose my fix and mail the list about making upgrade optional and off by default
[08:47] <wallyworld> wow
[08:47] <axw> also want to test apt-get using eatmydata
[08:47] <axw> that may make it more reasonable
[08:47] <wallyworld> ok
[08:48] <wallyworld> i wonder if we can deploy an apt cache to azure
[08:48] <wallyworld> or mirror
[08:50] <axw> wallyworld: I believe there is a mirror already
[08:50] <axw> cloud-init configures apt mirrors
[08:50] <mgz> 6 minutes... doing what mostly?
[08:51] <axw> mgz: that's timed from before "apt-get upgrade" to after
[08:51] <axw> so... whatever apt-get upgrade is doing
[08:51] <mgz> I really don't think not upgrading is an option..
[08:51] <axw> why?
[08:51] <mgz> we have security fixes for a reason
[08:53] <axw> mgz: but we don't continue upgrading after it's provisioned, so it just seems so arbitrary to do it at that point
[08:53] <axw> mgz: if people want to keep it secure, then there should be something doing upgrades on a regular basis
[08:53] <mgz> yeah, and we don't reboot for kernel either
[08:53] <axw> not just once and then that's it
[08:54] <axw> anyway, I'll test with eatmydata, maybe it won't be so bad
[08:54] <wallyworld> axw: mgz: can we start the standup now?
[09:05] <wallyworld> axw: standup?
[09:09] <axw> wallyworld: sorry brt
[09:39] <jamespage> jam: around? just getting to looking at mongodb/juju-mongodb -> 2.6.x
[09:56] <axw> wallyworld: the azure virtual network thing may have been coincidental
[09:57] <axw> it's not happening now
[09:57] <wallyworld> ah
[09:59] <wallyworld> maybe see how it goes over the next day or so
[10:02] <axw> yep
[10:03] <axw> could someone please review https://github.com/juju/juju/pull/196
[10:04] <axw> resolves a 1.20 issue
[10:05] <dimitern> axw, reviewed
[10:05] <axw> thanks dimitern
[10:05]  * axw comes back later to handhold the bot
[10:08] <axw> wallyworld: I might just change it back anyway, so we at least don't regress
[10:08] <wallyworld> rightio
[10:37] <voidspace> dimitern: ping
[10:37] <voidspace> dimitern: the "COntainer Addressability in EC2" section of the "Juju Networking Support Changelog and Roadmap" doc
[10:38] <voidspace> dimitern: says: Found a working procedure to spin up LXC containers, allocate a private IP from the host using EC2 API,
[10:38] <voidspace> dimitern: why are we using LXC on EC2?
[10:38] <dimitern> voidspace, we need addressable containers everywhere basically, EC2 is the first step
[10:39] <voidspace> dimitern: why do we need containers?
[10:39] <voidspace> dimitern: I mean, isn't EC2 essentially already a container
[10:39] <dimitern> voidspace, for higher density deployments
[10:39] <voidspace> dimitern: I understand the need for addressability
[10:39] <voidspace> dimitern: heh, containers within containers
[10:39] <dimitern> voidspace, no, EC2 instances are more like KVM machines than LXC containers
[10:40] <voidspace> dimitern: so they are containers...
[10:40] <voidspace> dimitern: ok, and containers on EC2 is primarily a networking issue?
[10:40] <voidspace> dimitern: I'm wondering why it's bundled with the networking story
[10:40] <voidspace> seems like a separate issue - unless the *primary* problem of "nested containers" is addressability
[10:41] <dimitern> voidspace, it is a networking issue - we can't get cloud-local ips for containers without additional work
[10:41] <voidspace> dimitern: ok, cool
[10:41] <voidspace> thanks
[10:41] <voidspace> so we use the host api to get a cloud local address for the contained container
[10:41] <voidspace> and providers need to support this
[10:42] <dimitern> voidspace, yes, if the provider supports addressable containers, it needs to implement AllocateAddress, so we can get an extra private ip for an instance, which we later assign to the container on that instance
[10:43] <voidspace> cool
[10:51] <fwereade> dimitern, quick check: when we're adding the implicitly pre-existing networks to the model, will we be assuming that services require juju-public (if it exists) along with juju-private (which they have to have to communicate with the state servers)?
[10:51] <perrito666> voidspace: hey, welcome back
[10:53] <dimitern> fwereade, right, juju-public and juju-private will be created automatically post-bootstrap, and all instances will be implicitly on them, regardless what other networks might be specified
[10:53] <voidspace> perrito666: hey, hi
[10:53] <voidspace> perrito666: it was a nice relaxing time away - so I'm actually happy to be back
[10:53] <voidspace> perrito666: mostly just because I'm happy...
[10:54] <voidspace> perrito666: how were things?
[10:54] <fwereade> dimitern, juju-private is definitely required for all machines/services
[10:54] <fwereade> dimitern, juju-public, if it exists, should probably be required for state servers and services -- at least by default
[10:54] <dimitern> fwereade, yes, but it won't be part of the requested networks lists, it will just be assumed it is
[10:55] <fwereade> dimitern, hmm, that feels special-casey
[10:55] <dimitern> fwereade, it is pretty special :)
[10:55] <fwereade> dimitern, not sure it's special enough
[10:55] <fwereade> dimitern, juju-private, yes
[10:55] <dimitern> fwereade, yeah
[10:56] <fwereade> dimitern, juju-public (1) might not even exist and (2) might not be wanted for a number of services
[10:56] <fwereade> dimitern, even for the state server, potentially
[10:56] <voidspace> jam: chrome just crashed - sorry!
[10:56] <dimitern> fwereade, but since that's only important at the time expose was called, it should be fine
[10:57] <fwereade> dimitern, I think if it does exist juju-public should be the default for new machines/services, but I suspect that if we're being explicit about required networks we should not automatically tack on juju-public
[10:57] <dimitern> fwereade, why not?
[10:57] <fwereade> dimitern, ^juju-public seems like a very reasonable thing to ask for (eg) a super-secret db server
[10:58] <fwereade> dimitern, and if juju-public is always assumed that's an immediate contradiction
[10:58] <wwitzel3> morning, brb, updates want me to restart
[10:59] <dimitern> fwereade, if juju-public is available at all, we can use it when needed (during expose), for any service, right?
[10:59] <dimitern> fwereade, it won't get configured specifically
[11:00] <voidspace> jam: lost connection!
[11:00] <dimitern> fwereade, until we need it
[11:00] <voidspace> jam: but no, that ticket was dropped
[11:00] <voidspace> jam: it should be deleted
[11:00] <voidspace> sorry
[11:00] <fwereade> dimitern, I'm worried that being *unable* to say "don't allow this service on the public network" is a problem
[11:00] <jam1> voidspace: deleted
[11:00] <voidspace> thanks
[11:00] <voidspace> jam1: I have no in progress tasks
[11:00] <wwitzel3> welcome back voidspace
[11:01] <fwereade> dimitern, and given that that network may or may not exist I think we should avoid special-casing it too much
[11:01] <voidspace> wwitzel3: hey, hi
[11:01] <dimitern> fwereade, let's think about this a bit
[11:01] <fwereade> dimitern, making it a default *if not otherwise specified*, but requiring juju-public explicitly if you also ask for other networks, feels more like what we need
[11:01] <fwereade> dimitern, go for it
[11:01] <dimitern> fwereade, in ec2 any machine is on the public network, and you can't restrict this with the default vpc setup
[11:02] <fwereade> dimitern, I'm more thinking about maasy environments
[11:02] <fwereade> dimitern, if the provider has no machines not on the public network, then provisioning will fail, and hopefully we can clearly explain why
[11:03] <dimitern> fwereade, we can still say deploy --constraints networks=^juju-public
[11:04] <fwereade> dimitern, how can that work if juju-public is always implicitly a required network? everything with ^juju-public will fail
[11:06] <rick_h_> fwereade: rogpeppe call time?
[11:06] <perrito666> does anyone know where --version is being registered?
[11:06] <fwereade> dimitern, if it's a required network *by default*, that can either be explicitly unspecified with `--network=` or (maybe better?) handled by the cli client such that ^juju-public doesn't send that, we might do better
[11:06] <rogpeppe> rick_h_: ah yes
[11:06] <fwereade> rick_h_, balls sorry
[11:06] <fwereade> rick_h_, omw
[11:07] <dimitern> fwereade, implicitly in the sense they're not part of instance selection criteria explicitly, unless explicitly specified
[11:08] <dimitern> fwereade, i.e. trying --constraints networks=^juju-private will fail on the juju side, but networks=juju-private,^juju-public will be ok, and passed to the provider
[11:09] <fwereade> dimitern, I thought --networks didn't take ^
[11:09] <dimitern> fwereade, i'm talking about constraints, since that's the way now to exclude networks
[11:28] <tasdomas`> is there some pattern when operations on state are retried (with state.run(...)) and when they are not?
[11:48] <wallyworld> fwereade: andrew reviewed this and i fixed issues, you may want to take a final look https://github.com/juju/juju/pull/185 cool if you don't have time
[11:49] <fwereade> wallyworld, I will try, for what that's worth :/
[11:49] <fwereade> tasdomas`, in general we'd expect them to be retried, is there something paticular yu're looking at?
[11:49] <fwereade> dimitern, sorry, meeting took over my brain
[11:50] <fwereade> dimitern, my point is simply that if juju-public is implicitly always a required network for anything, you can't exclude it with constraints because that creates a contradiction
[11:51] <dimitern> fwereade, let's say it's not required, but assumed to be there, and you can still specify it with a negative constraint to try to get a machine without it
[11:51] <fwereade> dimitern, I'm fine imposing that on juju-private, but not on juju-public, because everything *has* to have juju-private access (derail: manual provider? is juju-private really juju-public? arrgh) but there are use cases in which even the possibility of juju-public access is contraindicated
[11:52] <fwereade> dimitern, to assume makes an ass of u and me -- *defaults* are fine, but I'm really worried about having it treated specially internally
[11:53] <dimitern> fwereade, re manual - juju-private should be using the same subnet the machine was added with
[11:53] <dimitern> fwereade, and there might be a different public one
[11:54] <fwereade> dimitern, I would be much happier with the CLI being responsible for inserting juju-public into the API call when appropriate, and making it explicit at every possible level beyond that -- the user doesn't have to care, but I would really like it if the API required you to say what you mean and mean what you say
[11:54] <dimitern> fwereade, by special treatment I mean 3 things: 1) cannot be removed, 2) refcount is ignored, 3) assumed to be there when missing in the requested networks lists (but can be specified there explicitly as well)
[11:55] <fwereade> dimitern, (1) is about as much special treatment as I'm willing to deal with
[11:55] <dimitern> fwereade, (1) implies (2)
[11:56] <fwereade> dimitern, it might just mean it's created with a refcount of 1, instead of 0, thus preventing if from being killed; and all the rest of the code works exactly the same
[11:56] <fwereade> dimitern, doing (2)-style stuff will spread through state
[11:56] <fwereade> dimitern, *someone* will fuck it up sooner or later
[11:56] <dimitern> fwereade, well, we have IsDefault=true as well, which might short-circuit some checks for juju-private
[11:58]  * dimitern needs to go out for 1h
[11:58] <fwereade> dimitern, (another derail: IsDefault still bugs me, because it's kinda hard to prevent two things thnking they're default)
[11:58] <dimitern> fwereade, ttyl, sorry
[11:58] <fwereade> dimitern, ping me when you're back please :)
[11:58] <fwereade> dimitern, take care
[11:58] <dimitern> fwereade, sure ;)
[11:58] <tasdomas`> fwereade, ok, thanks - was simply looking for precedent and it seemed like AddUnit in state/service.go was not being re-run
[12:00] <wwitzel3> voidspace: ping
[12:01] <bac> hi mgz
[12:03] <mgz> bac: hey
[12:12] <voidspace> wwitzel3: pong
[12:13] <wwitzel3> voidspace: up for a hangout, could use a rubber duck and potentially active assistance :)
[12:13] <voidspace> wwitzel3: happy to hangout briefly  and be a rubber duck - about to go on lunch after that though :-)
[12:14] <wwitzel3> voidspace: thanks, heading to moonstone
[12:14] <voidspace> wwitzel3: cool
[12:21] <mgz> wwitzel3: I thought the term was teddy bear, not rubber duck :)
[12:23] <wwitzel3> mgz: I've always known it as rubber duck debugging
[12:23] <wwitzel3> mgz: but teddy bear sounds reasonable too
[12:23] <voidspace> mgz: yeah, rubber-ducking is the term I know
[12:23] <mgz> aa, cultral differences :)
[12:23] <voidspace> wikipedia agrees with wwitzel3 and me
[12:23] <voidspace> http://en.wikipedia.org/wiki/Rubber_duck_debugging
[12:24] <voidspace> although it does suggest "talk to the bear" as an alternative
[12:30] <fwereade> tasdomas`, having taken a quick look, I think the AddUnit thing represents an assumption that addUnitOps doesn't return ops that can fail for any reason other than the service no longer being alive
[12:30]  * voidspace lunches
[12:30] <fwereade> tasdomas`, I am at least 80% sure that assumption still holds
[12:31] <fwereade> tasdomas`, but it's a lot harder to be sure now that addUnitOps has been factored out
[12:31] <TheMue> jam: jam1: ping
[12:32] <TheMue> jam1: jam: would you take a look at https://github.com/TheMue/juju/tree/api-endpoints-public-private-address/cmd/juju and here endpoint.go and its test?
[12:53] <jam1> TheMue: const endpointDoc = `Returns a list of the API servers formatted as host:portDefault output format returns an api server per line.
[12:53] <jam1> needs updating
[12:53] <jam1> TheMue: I don't think we want to repeat the Start/End private lists here
[12:54] <jam1> if we want to do that filtering, we can reuse it from network
[12:54] <jam1> though I think we don't actually want to do that here.
[12:54] <jam1> TheMue: so my thought was that we just return the first API address in the list
[12:54] <jam1> as that is the one that Juju successfully connected to.
[12:55] <jam1> TheMue: if you feel more strongly that we should be determining what addresses to connect to, then we should find a way to share the code with our existing implementation
[12:56] <jam1> TheMue: see "network.isIPv4PrivateNetworkAddress"
[12:56] <TheMue> jam1: the addresses returned by the API are ordered so the the first one is enough? would be more simple, yes
[12:57] <TheMue> jam1: ah, and haven’t seen the network test function
[12:57] <jam1> TheMue: so we probably need to document that we're relying on the behavior, but I implemented code so that explicitly the IP address that we connected to last is always sorted to the beginning of the list
[12:58] <TheMue> jam1: ok, so the change would be taking the first address, doc that we rely on that and change the doc string that we only return one address?
[12:58] <TheMue> jam1: that’s even simpler then :)
[12:59] <TheMue> jam1: at least it helped a bit to get into networking
[12:59] <jam1> TheMue: I believe so. "state/api/state.go Login()" calls addAddress which calls slideAddressToFront for the address that we successfully connected to.
[13:00] <TheMue> jam1: nice behavior. only became insecure because of the slice of strings which made me thought it has no special order. dunno why.
[13:06] <TheMue> jam1: eh, the command is called api-endpoints. so always returning only one looks a bit strange. the filename states, that it once has been singular, has it?
[13:07] <jam1> TheMue: I believe in older versions it was singular, you'll have to do some spelunking into the 1.18 and 1.16 code bases to figure it all out. But it used to connect to the Environ directly, and report the single DNSName (I think?) of the state server that it found doing a lookup of the instance id found in bootstrap-state in provider storage.
[13:09] <TheMue> jam1: just started to dig in the history. but I won’t rename it back as it now used this way.
[13:09] <jam1> TheMue: well, I think the only consumer of it was probably assuming it returned a single value
[13:09] <jam1> as I *think* we changed the behavior in 1.18 and kapil filed bugs about it not working the way he wanted.
[13:09] <TheMue> jam1: ah, august last year
[13:10] <bac> morning sinzui
[13:10] <sinzui> hi bac
[13:14]  * fwereade failing to think properly, going for a short walk
[13:22] <axw> TheMue: there's already code in network/address.go for categorising IP addresses, too.
[13:23] <axw> TheMue: if you pass an IP address into network.NewAddress with ScopeUnknown, it'll check the private network ranges
[13:23] <wwitzel3> woo got my test stubs compiling and passing .. I feel like getting the suite setup with the right data and intefaces is always the biggest part of the battle
[13:23] <axw> TheMue: sorry, just saw jam1 made the same comment
[13:24] <TheMue> axw: yes, but still thanks for the hint
[13:25] <TheMue> axw: it’s now unneeded in this case as I learned, but talked today about a possible additional command for listing (and filtering) the addresses together with more information
[13:26] <axw> ok
[13:37] <mattyw> axw, I'm just reviewing https://github.com/juju/juju/pull/197 <- It's my first time reviewing core code - and I'm not very familiar with the azure stuff, it looks fine to me but you might like to get someone more familiar with azure to double check
[13:37] <axw> mattyw: thanks
[13:37] <axw> and I'll add a reference to the doc
[13:38] <TheMue> jam1: simplified it (aka stripping all curious ideas of first approach away) ;)
[13:41] <mattyw> axw, shouldn't you be asleep?
[13:41] <axw> mattyw: it's not yet 10pm, I don't go to sleep that early :)
[13:42] <mattyw> axw, oh right  - you must be western Australia?
[13:42] <axw> yup
[13:42] <axw> UTC+8
[13:45] <jam1> TheMue: "we rely on the fact that the returned API endoint always has the last address we connected to as the first address" perhaps?
[13:46] <jam1> TheMue: and second to that, I think we want a test where "info" has more than one value (if we can manage that) so that we can see that it is actually doing the right thing.
[13:46] <jam1> I have the feeling we'd really like a simple helper that runs the command and grabs the output rather than putting that into each test caes.
[13:47] <jam1> we might also need a test where we haven't connected to the state already?
[13:48] <TheMue> jam1: ok, text change is simple. but info with more than one value? hmm, have to check how we can to this
[13:50] <perrito666> wwitzel3: voidspace I will not make it to the stdup, I am on the sprint, sorry
[13:50] <perrito666> btw, where is eric?
[13:53] <axw> sinzui: the summary you just changed 1316185 to isn't right. it happens in azure with the release stream, but does not happen with the daily stream. but it's not just the stream that's the problem it's a combination of things
[13:54] <axw> at the end of the day it's how long apt-get upgrade takes
[13:58] <wwitzel3> perrito666: voidspace is on sapphire's standup anyway, he is working on the networking stuff
[14:00] <alexisb> wwitzel3, so sad you are all alone
[14:05] <wwitzel3> I wallow in it, the sadness
[14:08] <sinzui> axw, sorry I will fix the summary
[14:08] <mbruzek> Hi guys, I need to search for and/or open a bug against juju-core.  I know you moved the code to github, are the bugs still kept in launchpad?
[14:09] <axw> sinzui: nps. I changed it already, feel free to change again
[14:11] <rogpeppe> fwereade, wallyworld: i'm just wondering why we keep both md5 and sha256 hashes for the storage blobs?
[14:12] <mbruzek> disregard my question, read it in the topic.
[14:12] <katco> hi everyone, i'm katherine/katie :) today's my first day on the juju-core team. going through some administrative setup at the moment, but wanted to pop in and say hello!
[14:12] <mbruzek> welcome Katie!
[14:12] <ericsnow> katco: welcome!
[14:14] <perrito666> katco: welcome
[14:15] <mgz> hi!
[14:15] <katco> thanks all :)
[14:17] <TheMue> katco: heya, nice to have you now in our team. welcome and enjoy your new job.
[14:27] <rogpeppe> katco: hiya and welcome to Canonical! i saw your blog post about joining and enjoyed it... i recognised your name from somewhere (possibly comments on gustavo's posts?)
[14:29] <jcw4> welcome katco :)
[14:31] <dimitern> hey katco and welcome!
[14:38] <katco> rogpeppe: quite possibly! i enjoy gustavo's posts
[14:39] <rogpeppe> katco: me too
[14:44] <perrito666> the "only refresh video when this tab is active" hangout policy is going to give me a hearth attack one of these days
[14:49] <dpb1> 1.19.4: anyone seen this error? https://pastebin.canonical.com/112696/  (intermittent).
[14:50] <rogpeppe> fwereade, rick_h_, wallyworld: this is the kind of thing i had in mind for blob storage: http://paste.ubuntu.com/7726779/
[14:51] <rogpeppe> fwereade: i think it could work pretty well. no need to ref count - we can just garbage collect occasionally.
[14:51] <jam1> katco: welcome to the team!
[14:52] <katco> jam1: ty!
[14:52] <wwitzel3> katco: welcome
[14:52] <katco> wwitzel3: ty as well :)
[14:52]  * katco learning the joys of sl
[14:57] <TheMue> jam1: short info, w/o an API connection we currently only return nothing. I’ll change it to an error message, ok?
[15:00]  * TheMue is afk for a moment, switching car back from the garage
[15:00] <alexisb> katco, welcome!
[15:00] <katco> alexisb: thank you, and hello again!
[15:01] <jam1> TheMue: I thought that the "refresh" logic would have connected to the state server to ensure we have addresses if there was none already cached.
[15:01] <jam1> certainly if we don't have an address and can't connect, that sounds like an error state
[15:45] <TheMue> jam1: maybe my test is to naive here. I’ve closed APIConn of the test to see how the command execution behaves
[15:45] <wwitzel3> So the caller.Call code (http://paste.ubuntu.com/7726982/) is panicing from a nil pointer reference. It happens in Call, it never makes it to the apiserver method. I'm sure I'm doing something completely wrong, I just have no idea what.
[15:49] <jam1> wwitzel3: most likely the caller you are passing into NewFacade is nil
[15:53] <wwitzel3> jam1: when I check caller for nil it isn't nil and the printed value is http://paste.ubuntu.com/7727026/
[15:54] <jam1> wwitzel3: can you paste the traceback?
[15:54] <jam1> (panic)
[15:55] <wwitzel3> yep
[15:58] <wwitzel3> jam1: think I found it, looks like a call to api.st.EnvironConfig is causing it
[16:41] <wwitzel3> It helps if I actually set the state in the EnvironmentAPI struct.
[16:45] <perrito666> is the bot only set up for juju/juju ?
[16:47] <perrito666> I just $$merge$$d on juju/utils and nothing happens, and looking into the history of the repo merges are by rogpeppe
[16:47] <rogpeppe> perrito666: yeah, the 'bot is only set up for juju/juju
[16:48] <rogpeppe> perrito666: you just have to do the merge
[16:48] <perrito666> rogpeppe: using the gh large green button or via command line?
[16:48]  * perrito666 does not want to break the repo
[16:48] <rogpeppe> perrito666: green button
[16:49] <perrito666> rogpeppe: thank you
[16:50] <perrito666> I tested the branch by hand just in case
[16:50] <perrito666> and I read the other day that github was nice enough to implement unmerge
[17:11] <voidspace> Right, Krav Maga time
[17:11] <voidspace> see you all tomorrow
[17:12] <voidspace> EOD
[17:12] <ericsnow> voidspace: bye
[17:57] <ChrisW1> so this is where all the cool kids hang out :-)
[17:57]  * ChrisW1 waves to thumper, men0 and voidspace
[18:14] <katco> gah make install-dependencies hosed my go v1.3
[18:15] <katco> what version is the project utilizing, and should it work in 1.3?
[18:30] <ericsnow> katco: FWIW I'm running 1.2.1 (system install)
[18:30] <ericsnow> katco: no idea on 1.3
[18:31] <katco> i know there were some performance improvements in 1.3. newbie question: how does the team evaluate migration to new releases?
[18:35] <perrito666> katco: iirc 1.2
[18:35] <katco> ericsnow: perrito666: ty
[18:36]  * katco is now wondering how difficult it might be to juggle multiple versions of go
[18:37] <ericsnow> katco: I just started a few weeks ago so don't count on me to be a deep resource :)
[18:37] <ericsnow> katco: yet
[18:37] <wwitzel3> katco: we are kind of restricted by what is distributed with LTS releases.
[18:38] <wwitzel3> at least that is my understanding, I am sure someone has a better more indepth explanation of the actual process or migration to the latest release
[18:38] <katco> ericsnow: well you have a few weeks on me ;)
[18:39] <katco> wwitzel3: i use gustavo niemeyer's excellent godeb to grab new versions. i understand if that's not tenable for the project; just curious!
[19:35] <katco> hm. i'm trying to go get code.google.com/p/go.tools/cmd/vet, but i don't have write access to goroot. is there a better solution than to grant my user account access to goroot?
[19:36] <perrito666> goroot is not something on ~ I assume
[19:37] <katco> perrito666: i'm following the CONTRIBUTING.md, and when i ran make install-dependencies, it grabbed the go dist from ubuntu proper
[19:37] <katco> currently sitting under /usr
[19:37] <katco> /usr/lib/go
[19:38] <katco> i can probably just overwrite it with gustavo's godeb, but i wasn't sure if that was a good solution. i'm assuming i'll be doing make install-dependencies in the future
[19:38] <mattyw> It's probably not the best answer but I gave up on that a while ago. I just download the binary from golang.org
[19:38] <perrito666> katco: mm, I set GOPATH to ~/gocode and in my case GOROOT is not set
[19:38] <ericsnow> katco: your GOPATH is set to something you own?
[19:39] <katco> ericsnow: it is... it's using gotooldir since this is in go.tools
[19:39] <katco> which is the thing under /usr/lib/go
[19:39] <katco> it sounds like maybe what i should do is just install my own version of go... do we run make install-dependencies repeatedly? or is that like a one-timer?
[19:40] <mattyw> A one time thing I think
[19:40] <mattyw> I've got my path setup so my go binary is the first thing it finds. So anything that changes underneath is ignored
[19:40] <perrito666> katco: in my experience onetimer (that is ~3months)
[19:40] <katco> perfect :)
[19:41] <katco> mattyw: well, i use godeb which uninstalls ubuntu's version, and make install-dependencies does the same
[19:41] <katco> so they would be warring =/
[19:41] <mattyw> There was something weird with old packages of go that would try to put packages in /usr/lib irrespective of gopath
[19:42] <katco> i asked over in #go-nuts, and they said it's because it comes from go.tools that it will use go env |grep -i gotooldir
[19:42] <katco> which points to /usr/lib/...
[19:42] <katco> i'll see if godeb behaves better
[19:42] <katco> ty team :)
[19:44] <katco> it just occurred to me that if i switch back to 1.3 i'll get debugging working again too
[19:51] <katco> fyi, gustavo's godeb installation works quite nicely
[19:51] <katco> saves time on setup too!
[19:51] <perrito666> ok eod
[19:51] <katco> tc perrito666 ty for the help!
[19:52] <perrito666> cuall tomorrow, cheers
[20:04] <katco> in scripts/, should these refer to local directory, or hard-coded to github.com/juju/juju?
[20:07] <katco> also, off of a fresh go get -u, these scripts return 3 errors for me
[20:19] <mattyw> Have you run godeps?
[20:20] <katco> mattyw: i have not
[20:21] <katco> i'm following: https://github.com/juju/juju/blob/master/CONTRIBUTING.md
[20:21] <mattyw> godeps -u dependencies.tsv I think is the command
[20:21] <mattyw> It sets everything to the correct version
[20:21] <katco> ty i'll try that... should the CONTRIBUTING.md be updated? or is this just implied
[20:21] <katco> ?
[20:22] <ericsnow> katco: it should already be there
[20:22] <ericsnow> katco: see the "Dependency management" section
[20:22] <katco> ericsnow: oy. sorry... i swear i just did a find on the page =/
[20:23] <ericsnow> katco: no worries :)
[20:23] <mattyw> Although it's just occurred to me that I haven't setup the pre commit hook
[20:32] <katco> i'm still receiving a build error in trunk: # github.com/juju/juju/state
[20:32] <katco> ../../juju/juju/state/action.go:86: too many arguments in call to names.NewActionTag
[20:33] <thumper> katco: have you run godeps?
[20:33] <thumper> katco: we have a system so trunk is always buildable
[20:33] <katco> thumper: i have
[20:33] <thumper> katco: let me look
[20:33] <katco> i'm sure i'm doing something wrong
[20:34] <katco> did a go get -u github.com/juju/juju; go build ./...
[20:34] <bodie_> you want to do juju/juju/...
[20:34] <bodie_> then run godeps
[20:34] <bodie_> then try building
[20:35] <bodie_> (... in the go get step)
[20:35] <katco> ah i bet that's it
[20:35] <thumper> yeah
[20:36] <katco> (get taking longer :))
[20:36] <thumper> katco: pretty sure the godeps instructions are in the contributing file
[20:36] <katco> thumper: they are, thank you
[20:36] <thumper> np
[20:37] <katco> yay, building!
[20:38] <katco> ok, now my other question is why are the scripts in my fork building the trunk for error checking?
[20:39] <thumper> um... wat?
[20:40] <katco> (assuming i am wrong again) if i look at github.com/katco-/juju/scripts/pre-push.bash
[20:40] <thumper> wallyworld, sinzui: interesting data point, last night bootstrapping ec2 m3.medium, I got timeout failure during jujud bootstrap with mongo replica set not coming up
[20:40] <thumper> one time out of three
[20:40] <katco> the last line is: go build github.com/juju/juju/...
[20:41] <katco> i am wondering if that should be "go build ../..."?
[20:42] <thumper> nah...
[20:42] <thumper> that's fine
[20:42] <thumper> it was probably that the godeps step hasn't been added there
[20:42] <thumper> and it probably should be
[20:42] <sinzui> thumper, I have seen that too. The 5 failures listed here pertain to replicaset http://juju-ci.vapour.ws:8080/job/aws-deploy-trusty-amd64/
[20:43] <thumper> sinzui: any idea why it is flakey?
[20:43] <bodie_> katco, if you go build ./... in juju, and the deps aren't built, it should also build them
[20:43] <bodie_> :)
[20:43] <thumper> sinzui: or is it likely to be "you are using an old mongo, please upgrade"
[20:43] <sinzui> thumper, does trusty have an old mongo?
[20:43] <thumper> sinzui: we are using juju-mongodb which is 2.4
[20:43] <katco> maybe i'm resting on a bad assumption; isn't that line designed to check to see if the branch you're currently hacking on builds?
[20:44] <thumper> katco: yes
[20:44] <katco> hm. is my setup wrong? should i be working out of the github.com/juju dir?
[20:45] <bodie_> why?
[20:46] <katco> i think i'm missing something. if go build github.com/juju/juju is designed to test my current working set, and i'm modifying github.com/katco-/juju, i am missing how it fulfills its purpose
[20:46] <mattyw> It needs to be juju/juju
[20:47] <bodie_> ah, what you want to do is actually clone your personal repo to $GOPATH/github.com/juju/juju
[20:47] <katco> ahhh ok!
[20:47] <bodie_> I think this is all in CONTRIBUTING though
[20:47] <katco> gosh i'm sorry. i suppose i need to go back through and read this more carefully
[20:47] <bodie_> I had many of the same questions, heh
[20:47] <katco> thanks for the help
[20:47] <bodie_> np :)
[20:48] <thumper> sinzui: what is up with the lander?  I see lots of rejections. Is there a common failure?
[20:50] <sinzui> all are PANIC session closed thumper .  A bad test is blocking everyone's work
[20:50] <thumper> fark
[20:51] <sinzui> And it is happening with got test and got test -p 2
[20:52]  * thumper sighs
[20:52] <thumper> how did it get in
[20:52] <thumper> ?
[20:53]  * thumper runs tests locally to see if he can reproduce
[20:53] <sinzui> thumper, it only has to pass intermittently to get in.
[20:54] <thumper> sinzui: is it always the apiserver code?
[20:55] <sinzui> thumper, Is it possible for the joyent provider to disable the default bootstrap timeout of 10 minutes? That is to say, I have killed procs that are 23 hours old. Bootstrap didn't give up
[20:55] <sinzui> thumper, I think it is...I have never seen it to be any other case and it did appear with API a few weeks ago
[20:56]  * thumper takes a wild stab in the dark and points at the presense code
[20:56] <wallyworld> rogpeppe1: we use both hashes because william insisted on it :-) originally it was just md5 or sha256
[20:57] <wallyworld> thumper: sinzui: we have been living with the intermittent failures till now since they were, well, vey intermittent. now it seems there's a much more serious issue we'll need to try anf fix asap
[20:57]  * thumper nods
[20:58] <thumper> wallyworld: I'm guessing it happens more under load
[20:58] <wallyworld> part of the issue is the folks fixing it didn;t write the original code nor are mongo experts
[20:58] <thumper> wallyworld: I don't see it much at all with my i7, and ssd
[20:58] <wallyworld> me either
[20:59] <thumper> I remember having to run tests while having other code in a compile loop to put my machine under load
[20:59] <thumper> (in another project)
[21:01] <wallyworld> thumper: the cloud on which the tests are run also seems to affect it somewhat, so it does seem to be a timing issue of some sort
[21:01] <thumper> yeah
[21:02] <thumper> I'm looking at the presense code now
[21:02]  * thumper recoils
[21:02] <thumper> type Presencer
[21:02] <thumper> aarrggghhh....
[21:03] <wallyworld> yep, i hate those names
[21:03] <wallyworld> katco: meeting?
[21:07] <katco> wallyworld: apologies... setting up canonical g+
[21:07] <bodie_> anyone familiar with the uniter_test Steps in worker/uniter?
[21:07] <wallyworld> np :-)
[21:08] <katco> wallyworld: and again apologies for noise. we brilliantly scheduled air duct cleaning before i knew my start-date
[21:08] <wallyworld> lol
[21:09] <wallyworld> my laptop fan is very noisy
[21:10] <thumper> wallyworld: I think I have found it
[21:10]  * thumper double checks
[21:10] <wallyworld> thumper: otp with katco
[21:12] <thumper> hmm... maybe not
[21:12] <katco> wallyworld: katherine.cox-buday@canonical.com
[21:23] <katco> wallyworld: i'm so sorry i can't hear anything
[21:23] <wallyworld> no worries
[21:23] <katco> wallyworld: i muted you out of compassion ;)
[21:23] <katco> i think they may be done with this section of the house momentarily
[21:23] <wallyworld> that's what people say to me too
[21:23] <katco> LOL
[21:24] <bodie_> they sensed the frustration.. lol
[21:26] <thumper> ugh....
[21:26] <thumper> katco: welcome, just worked out who you were
[21:27] <thumper> I think I have found a leak in some of my tests...
[21:47] <bodie_> https://github.com/juju/juju/pull/199
[21:47] <bodie_> any and all review would be appreciated, WIP
[21:48] <bodie_> (Action running on unit)
[22:01] <katco> thumper: thank you!
[22:34] <ericsnow> do we use /etc/init/juju-db.conf anywhere?  (we are currently backing it up)
[22:35] <sinzui> ericsnow, that is the upstart script to keep the service alive when the machine reboots
[22:36] <ericsnow> sinzui: what creates it?
[22:37] <sinzui> ericsnow, I onlt know from what I observe in QA. I think the act of bootstrapping creates both /etc/init/juju-db.conf and /etc/init/jujud-machine-0.conf
[22:38] <ericsnow> sinzui: okay, thanks
[22:38] <sinzui> ericsnow, issuing  kill -SIGABRT <pid> will terminate jujud and remove both upstart scripts
[23:29] <wallyworld> wwitzel3: looking at branch now. just saw first line. be forewarned - me and thumper detest the apparent Go idiom of adding "er" to nouns to make stupid interface names :-P
[23:29] <wallyworld> the worst case in our code base was/is Addresserer
[23:29] <wallyworld> or something like that
[23:30] <wallyworld> InstanceTyper isn't too bad though :-)
[23:32] <wwitzel3> wallyworld: yeah thumper just talked about that in the Oynx standup .. I only did it because I thought I was supposed to :) .. I also think it is stupid
[23:33] <wallyworld> :-)
[23:33]  * wallyworld vomits
[23:34] <wallyworld> wwitzel3: "capabilityer"
[23:34] <wallyworld> lol
[23:34] <wallyworld> that's gotta go
[23:36] <thumper> haha
[23:43] <mbruzek> Hiya thumper do you have a minute?
[23:44] <thumper> mbruzek: ah... yeah
[23:44] <mbruzek> I got an error that tvansteenburgh (lets call him Tim2) has also found.
[23:44] <mbruzek> http://pastebin.ubuntu.com/7728552/
[23:45] <thumper> wallyworld: it looks like I don't leak in the test like I thought, no idea why they are in the panic log of the tests...
[23:46] <wallyworld> thumper: np, thanks for looking. we'll look today and try and sort it out
[23:46] <thumper> mbruzek: what architecture
[23:46] <mbruzek> We are both getting our deployments to fail on apt-get install  commands.  I spoke with Ben Howard about this and I understand it might be due to stale meta-data
[23:46] <mbruzek> Tim2 is getting his on x86, but I am getting this same problem on Power systems.
[23:47] <thumper> mbruzek: is samba ported to power? could be stale metadata
[23:47] <thumper> looks like it should be there but isn't
[23:47] <mbruzek> Once I ssh to the nagios/0 unit and run sudo apt-get update everything works fine.
[23:48] <thumper> mbruzek: perhaps the install hook should do an update before trying to install
[23:48] <mbruzek> thumper, I considered that, but I got this problem on a few charms.
[23:49] <wallyworld> wwitzel3: looks solid. i don't think the client api needs to marshal the result to json though - that is done by the rpc layer if we just define a struct in params.go to hold the result
[23:49] <thumper> I bet it is the local provider right?
[23:49] <mbruzek> thumper,  yes on both architectures.
[23:49] <bigjools> thumper: can you comment on this please? I think it's really a juju bug https://bugs.launchpad.net/maas/+bug/1335179
[23:49] <_mup_> Bug #1335179: deploying containers to maas environment breaks with nic renaming <oil> <MAAS:Incomplete> <https://launchpad.net/bugs/1335179>
[23:49] <thumper> mbruzek: right, in order to make machines boot faster, juju doesn't do apt-get update/upgrade when the machines are started any more
[23:49] <wallyworld> wwitzel3: also, it would be ideal if this were a few branches - 1 for provider refactor, 1 for client calling code etc
[23:50] <thumper> mbruzek: so deploying on to normal other machines, you wouldn't need the update
[23:50] <thumper> as juju has done it already
[23:50] <thumper> but the local hasn't
[23:50] <thumper> and is likely stale
[23:50] <mbruzek> thumper, how recently was this changed?
[23:50] <thumper> months ago
[23:50] <thumper> but only becomes apparent as new packages are put on the archives
[23:50] <thumper> to make it stale
[23:50] <wallyworld> wwitzel3: but git sucks for pipelines cf bzr so if you need to leave it all in one branch we can managed that
[23:51] <thumper> it should probably be best practice for charms to do an update before installing packages
[23:51] <thumper> as they can't be sure they are on a new up to date machine
[23:51]  * thumper clicks on bigjools's bug
[23:52] <mbruzek> marcoceppi, claims that breaks idepotentcy.  If you install today and apt-get update is called on config-changed several days later you could get a different (incompat) version.
[23:52] <mbruzek> thumper, Is there a way to enable the apt-get update in cloud-init through juju ?
[23:53] <mbruzek> I haven't tested all the charms, but I am guessing this is not isolated to 1 or 2 charms.
[23:53] <thumper> mbruzek: the local provider explicitly doesn't
[23:53] <thumper> mbruzek: ha, that is laughable, you don't get idempotency with juju charms
[23:54] <thumper> mbruzek: you never will unless you use version pinning for everything you depend on
[23:54] <thumper> sorry, but I'll argue with marcoceppi if I have to
[23:55] <mbruzek> thumper, aside from that issue, what happens if we find that *many* charms have to be "re-written" to work around this issue?
[23:55] <thumper> bigjools: you were right, juju bug not maas
[23:56] <bigjools> thumper: ok thank you, can you retarget? :)
[23:56] <thumper> mbruzek: then it should be documented as charm best practice
[23:56] <thumper> bigjools: added bug target already
[23:56] <bigjools> thumper: cool ta