[06:45] <jam> vladk: Your patch failed to land on a couple of tests: provider/maas/environ_whitebox_test.go:686: undefined: environs.NetworkInfo
[06:45] <jam> It looks relevant to  what you changed.
[06:45] <vladk> jam: I'll look
[09:11] <jam> mgz: ping me when you wake up
[10:01] <vladk> jam, mgz: I can't commit my branch because tests failed due to interface changes in the trunk branch. What is the usual process to resolve such situation?Merge manually? Use rebasing?
[10:01] <jam> vladk: merge trunk, resolve conflicts, commit, push, mark approved again
[10:34] <perrito666> morning everyone
[10:37] <jam> morning perrito666
[10:37] <jam> I think its going to be a bit quite in the standup today. I think most people are out for Easter
[10:39] <perrito666> well for the moment its only me and wwitzel3 s room
[10:42] <wwitzel3> :)
[10:46] <natefinch> stupid hangouts
[10:47] <jam> natefinch: morning
[10:48] <natefinch> morning
[10:48] <natefinch> I may need to reboot to get hangouts to work
[10:48] <natefinch> brb
[11:17] <jam> natefinch: if you want to chat a bit early, I have free time now
[11:19] <natefinch> jam: sure
[11:38] <wwitzel3> natefinch: mongo API rename review https://codereview.appspot.com/89840044
[11:39] <natefinch> wwitzel3: I'll look
[11:48] <wwitzel3> natefinch: also, what should I start on next?
[12:09] <natefinch> wwitzel3: see if there are any of these you can take on: https://launchpad.net/juju-core/+milestone/1.19.1
[12:49] <rogpeppe> hi all
[12:51] <perrito666> hi rogpeppe
[12:51] <rogpeppe> perrito666: hiya
[12:51] <perrito666> rogpeppe: my calendar says you are not here
[12:51] <rogpeppe> perrito666: i am not
[12:51] <rogpeppe> perrito666: i am going skiing again today
[12:52] <perrito666> wow, skiing while irc chatting, skillful dude
[12:52] <rogpeppe> perrito666: :-)
[14:45] <sinzui> natefinch, wwitzel3 : We are getting a lot of activity about 1.18.1 and 1.19.0 local not being able to find tools. I cannot reproduce it https://bugs.launchpad.net/juju-core/+bug/1309805
[14:45] <_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series <juju-core:Incomplete> <https://launchpad.net/bugs/1309805>
[14:45] <sinzui> Maybe I am not affected because I have been on trusty for 6 months
[14:46] <natefinch> sinzui: possible we have the same problem
[14:46] <natefinch> (being on trusty)
[14:48] <sinzui> natefinch, For some number of hours, there was a checksum mismatch in a security update that broken cloud-init (not tools). The fixed package is propagating now
[15:40] <hazmat> sinzui, what's the juju ftest jenkins url?
[15:41] <hazmat> sinzui, having some issues this morning (different then the archive issues noted) about 1.19 not installing mongo on precise.
[15:43] <sinzui> http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/
[15:44] <sinzui> hazmat, ^ CI was angry about the checksum mismatch over the last few hours
[15:44] <hazmat> http://paste.ubuntu.com/7300113/
[15:44] <hazmat> sinzui, that's an image/repo issue not juju's fault afaics
[15:44] <hazmat> sinzui, that pastebin has the mongo issue i'm trying to trackdown
[15:45] <hazmat> albeit juju should still deal with it nicely
[15:46]  * hazmat tries again with current trunk
[15:46] <sinzui> hazmat, wow
[15:50] <sinzui> hazmat, I expect to see juju always install a juju. precise should install mongodb-server. I think juju wanted to exec /usr/bin/mongod
[15:51] <sinzui> ^ natefinch I *think* juju always installs a mongodb-server on bootstrap when it doesn't find one. trusty wants /usr/lib/juju/bin/mongod, precise wants /usr/bin/mongod
[15:51] <hazmat> sinzui, mongo install has  been subsumed into the ha worker bits
[15:52] <hazmat> might have gotten caught in the ha merge ... trying again with current trunk/upload-tools to see if it helps
[15:59] <natefinch> hazmat, sinzui: juju always installs mongod
[16:00] <sinzui> natefinch, but is chooses one to match the series. trusty gets juju-mongodb?
[16:01] <natefinch> sinzui: it should, I'm trying to detangle the code
[16:02] <jam1> sinzui: hazmat: Trunk is not compatible with 1.19.0. In 1.19.0 it assumed the Client installed mongodb-server or juju-mongodb via cloud-init. In 1.19.1 it is done in the jujud server. So if you are testing with Trunk, you have to use --upload-tools
[16:03] <jam1> hazmat: bug #1308337
[16:04] <_mup_> Bug #1308337: 1.19.1 cannot bootstrap 1.19.0 (no longer installs mongodb-server during bootstrap) <regression> <juju-core:Won't Fix> <https://launchpad.net/bugs/1308337>
[16:04] <natefinch> sinzui: it looks like it always installs mongodb-server from cloud-archive, but not juju-mongodb
[16:04] <jam1> natefinch: it gets mongodb-server from ctools, but juju-mongodb is in the Trusty Universe archive.
[16:04] <jam1> natefinch: the bug hazmat was seeing was because it was targetting the released 1.19.0
[16:04] <jam1> as the "latest available version"
[16:04] <jam1> but per my bug report, 1.19.1 *won't* bootstrap a 1.19.0
[16:05] <jam1> (well, will fail to)
[16:06] <natefinch> jam1: there's no mention of juju-mongodb in the code, so I have to assume we're not installing it
[16:06] <natefinch> jam1: ensuremongoserver just installs mongodb-server
[16:06] <jam1> natefinch: ffs...
[16:07] <jam1> natefinch: well, on amd64 mongodb-server is now available, so that might actually still work, but it will be broken for non amd/i386
[16:08] <natefinch> jam1: I can fix it so we install juju-mongodb on trusty
[16:08] <jam1> natefinch: so there was func MongoPackageForSeries(series string) string {
[16:08] <jam1> 	switch series {
[16:08] <jam1> 	case "precise", "quantal", "raring", "saucy":
[16:08] <jam1> 		return "mongodb-server"
[16:08] <jam1> 	default:
[16:08] <jam1> 		// trusty and onwards
[16:08] <jam1> 		return "juju-mongodb"
[16:08] <jam1> 	}
[16:08] <jam1> }
[16:08] <jam1> which is, install "juju-mongodb" for everything new
[16:09] <natefinch> jam1: I remember that... weird, I guess it must have gotten dropped during a merge or something
[16:11] <jam1> natefinch: it was removed by r 2593 "  p, li { white-space: pre-wrap; }  r=natefinch] The machine agent is now responsible for setting up mongo. Cloud Init is no longer used to set up the upstart script. Mongo now starts with --replSet and the replicaset gets initiated. We still start just a single machine, but more machines will be able to be added later (once we have code to do so)."
[16:11] <jam1> natefinch: code from rog, r=natefinch
[16:13] <jam1> natefinch: I think your EnsureMongoServer patch just removed the "what package should be installed" logic completely
[16:13] <jam1> because it was removing the "use cloud-init to install the right package"
[16:21] <natefinch> jam1: well, fixable, obviously it should be there.  Probably just overzealous code deletion
[16:29] <hazmat> re ha stuff, we can get this out of status state-server-member-status? feels like leaky internal details
[16:30] <natefinch> hazmat: it's pretty useful information to know which of your state servers are voting members in the replicaset.  It can help when figuring out what's going on with HA
[16:31] <hazmat> natefinch, again thats' leaky internal impl details
[16:31] <natefinch> hazmat: yes, but it's *useful* internal impl details
[16:31] <hazmat> natefinch, if we want to go that route, why not just list out jobs on machines
[16:31] <hazmat> natefinch, ideally internal impl details only get show when requested
[16:32] <hazmat> natefinch, else we're just drowning status in more noise
[16:32] <natefinch> hazmat: we're considering making a more succinct status anyway
[16:32] <hazmat> i've heard..
[16:32] <natefinch> hazmat: status is already too huge for any medium sized deployment
[16:32] <hazmat> but let's not keep doing the opposite ;-)
[16:32] <hazmat> till we get there
[16:33] <natefinch> hazmat: well, we need information about HA so you can tell what's going on about it. We can change it so it doesn't say "vote", but we need information that say s "this is a state machine, and it's currently being used to keep juju highly available"
[16:34] <hazmat> natefinch,  state-server-member-status: has-vote doesn't really convey that
[16:36] <natefinch> hazmat: Roger's initial suggestion was "Active, Inactive, Deactivating, Activating".  Maybe I was wrong to get him to change it.
[16:37] <hazmat> natefinch, those sound pretty reasonable.. i'd expect omission on Inactive.. but the others convey better to an end user rather than has-vote
[16:38] <hazmat> its still dev version.. re changing
[16:40] <natefinch> hazmat: inactive means the machine is likely down or is a mongo backup (non-voting) only.   I don't think it should be simply removed, otherwise it will look like it's not a state server, when it is.
[16:43] <natefinch> hazmat: the name change isn't a big deal, people can mentally translate to mongod terms as needed.  But I do still think more information is still better than less, even with status being too long as-is.  We can make a less spammy one later, but until then, this is the only way people can easily introspect their environment without having to start querying log files.
[16:44] <natefinch> brb gotta make some lunch
[17:03] <hazmat> natefinch, better would be some ha centric commands/options ie fold into ensure-availability
[17:07] <natefinch> hazmat: yeah, ha-status or something
[17:16] <hazmat> when's 1.19.1 scheduled
[17:16] <hazmat> afaics 1.19.0 is hosed on precise
[17:16] <hazmat> with manual provider
[17:24] <jam> natefinch: did we get a bug for not installing juju-mongodb or should I add one?
[17:26] <natefinch> jam: I haven't made one, my guess is that there isn't one right now.  I was just testing a fix for it
[17:26] <jam> natefinch: submitting a bug so we can track it against the release
[17:28] <jam> natefinch: bug #1310719
[17:28] <jam> assigned to you
[17:28] <_mup_> Bug #1310719: mongodb-server installed instead of juju-mongodb on trusty <ha> <mongodb> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1310719>
[17:28] <natefinch> jam: thanks
[17:28] <natefinch> jam: I have to run out to run an errand, but I should be able to get that fix in before EOD
[17:29] <jam> natefinch: any status update on bug #1304407
[17:29] <_mup_> Bug #1304407: juju bootstrap defaults to i386 <amd64> <apport-bug> <ec2-images> <metadata> <trusty> <juju-core:Triaged by natefinch> <juju-core 1.18:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1304407>
[17:30] <natefinch> jam: I have a fix, needs to be proposed
[17:33] <natefinch> jam: https://codereview.appspot.com/89900043
[17:34] <natefinch> jam: occurred to me there's no tests for it, though
[17:34] <jam> natefinch: do we strictly prefer amd64 if you're running from say ppc ?
[17:34] <jam> I wonder if strictly preferring version.Current would be better
[17:34] <jam> and a test helps us keep this from regressing
[17:34] <natefinch> jam: I don't know.  It seems complicated to know what people expect
[17:35] <natefinch> jam: probably a strict heirarchy of what we prefer is better than depending anything on the juju client
[17:35] <natefinch> jam: but I really gotta run
[17:35] <jam> natefinch: so --upload-tools will just break if we don't use version.Current
[17:35] <jam> natefinch: see ya later
[17:35] <natefinch> jam: good point
[18:04] <hazmat> sinzui, the effort involved in converting the docs is pretty large.. and keeping it running and delta minimized as changes are made to both is painful.. is there an issue with just moving forward and resolving these issues as we go?
[18:04] <hazmat> these formatting issues that is
[18:06] <sinzui> hazmat, I am concerned that we lost information in translation.
[18:09] <hazmat> sinzui, lost as in your recent merge proposals?
[18:09] <hazmat> sinzui, syncing content between two different formats is time consuming.. the only way to make that pain go away is to finish the switch
[18:36] <perrito666> hi, can you all read me?
[19:08] <wwitzel3> perrito666: didn't notice until now, but if it still helps, yes
[19:09] <natefinch-afk> alexisb: you around?  Sorry I'm late
[19:09] <alexisb> natefinch-afk, yep, on and ready when you are
[19:12] <perrito666> wwitzel3: tx, I was checking network connectivity trough phone, light went out for a moment
[19:35] <bac> sinzui: do you know when juju started generating a control-bucket if one was not supplied?
[19:36] <wwitzel3> perrito666: ahh you still on the phone now?
[19:36] <perrito666> wwitzel3: nope, power came back (I am behind an irc proxy)
[19:36] <sinzui> bac 1.17.0 or 1.17.1
[19:37] <bac> thanks
[23:44] <stokachu> is the gomaasapi exposed through the juju api as well?
[23:44] <stokachu> or is it just internal to juju