[01:29] <thumper> hi axw
[01:29] <axw> hey thumper
[01:30] <thumper> axw: what does ReadFull do?
[01:30] <axw> ReadFull reads exactly len(buf) bytes from r into buf. It returns the
[01:30] <axw>     number of bytes copied and an error if fewer bytes were read.
[01:30] <thumper> oh cool
[01:30] <thumper> yeah, that's better than the loop
[01:36] <thumper> axw: I only noticed it because I occasionally habitually run "make check" when I switch to an updated trunk
[01:36] <thumper> and it errored the first time and not the second
[01:36] <thumper> actually, it didn't fail again
[01:37] <axw> that's race conditions for you :)
[01:37] <axw> glad it didn't cause too much strife
[01:42] <wallyworld> thumper: last one for the 1.15 release i hope https://codereview.appspot.com/13800043
[01:42] <thumper> axw: no, not strife. I've spent lots of time in the past dealing with race conditions
[01:50]  * thumper objects horribly
[01:52] <axw> thumper: re jc.Set?
[01:52] <thumper> yes
[01:52] <thumper> now on juju-cev
[01:52] <thumper> dev
[01:53] <thumper> how about testing/basesuite
[01:53] <thumper> or basesuties
[01:53] <thumper> suites
[01:53] <axw> testing/testbase?
[01:53] <thumper> I'd be happy with that
[01:53] <thumper> shall I do it now?
[01:53] <axw> doesn't have to be about suites
[01:53] <thumper> sure
[01:54] <thumper> worth having any test helper methods and functions that don't drag in extra dependencies
[01:54] <thumper> keep it loopless if possible
[01:54] <thumper> should be possible
[01:54] <axw> I say go for it
[01:55]  * thumper finishes wallyworld's review then goes for it
[01:55] <wallyworld> \o/
[01:55] <wallyworld> s/review/reviews
[01:55] <wallyworld> and we need to talk about logging
[01:56] <thumper> ack
[01:56]  * thumper dedicates 20 minutes to this task
[01:56] <thumper> if it takes longer than that, interrupt me
[01:56] <thumper> make that 30 minutes
[01:57] <axw> thumper: it can wait till later, but am I likely to get a lgtm on sshstorage today?
[01:57] <thumper> axw: yes, I'm at the disposal of you two today
[01:57] <thumper> after this hacking
[01:57] <axw> bueno
[01:57] <axw> thanks
[01:58]  * axw looks at authenticated httpstorage
[02:06] <thumper> bugger
[02:07]  * thumper forgot to add the directory before moving things to it
[02:07] <thumper> bzr lost track
[02:08]  * thumper found bzr mv --after
[02:08] <mramm> hey thumper got a couple of min?
[02:09] <mramm> I think robbie (kvm robbie not cdo robbie) is out all next week
[02:09] <thumper> sure
[02:09] <mramm> so if you want to round trip with him on kvm issues it is going to have to be today :/
[02:09] <thumper> yeah...
[02:09] <thumper> he scheduled a meeting 1am nz saturday
[02:09] <mramm> ouch!!!!
[02:09] <mramm> that is nutto
[02:11] <thumper> yeah, at least I'm down as optional :)
[02:11] <thumper> mramm: did you want to hangout?
[02:11] <mramm> I just wanted to tell you that news
[02:12] <mramm> and to let you know that Dan is *very* concerned about kvm stuff
[02:12] <mramm> he says it is pretty well tested on his end, and wanted me to give him a detailed view of what problems you've had
[02:12] <thumper> I'll forward you the email
[02:13] <mramm> thanks
[02:14] <davecheney> mramm: is there background on the kvm issue ?
[02:14] <davecheney> i have heard 512mb + kernel overcommit == 0 is the issue ?
[02:14] <davecheney> mramm: we believe this is fixed in golang trunk
[02:16] <davecheney> fixed is an oversimplification of the problem
[02:16] <davecheney> if this is the problem I think it is
[02:16] <davecheney> dan will have the same issue running jvm applications in those small kvm containers
[02:17] <davecheney> thumper: mramm ping
[02:17] <thumper> hi davecheney
[02:17] <davecheney> thumper: may i butt into this issue
[02:17] <davecheney> i believe i have experience
[02:18] <mramm> davecheney: the issue is with the kvm wrappers that they wrote
[02:18] <mramm> not in any way with jvm
[02:19] <mramm> and it's just about us supporting kvm containers *inside juju*
[02:19] <davecheney> mramm: ok
[02:19] <davecheney> thanks
[02:19] <davecheney> mramm: what does kvm inside juju mean ?
[02:21] <mramm> like lxc containers but kvm containers
[02:21] <mramm> EG deploy ceph inside kvm on a machine as part of an openstack install
[02:23] <mramm> ok, gotta run
[02:23] <mramm> getting late here.
[02:25] <axw> gnight
[02:29] <davecheney> mramm: how does this problem relate to the 1gb issue ?
[02:29] <davecheney> are they unrelated
[02:29] <davecheney> i'm only interested in the latter
[02:29] <mramm> which problem?
[02:29] <mramm> kvm?
[02:29] <davecheney> mramm: yes
[02:29] <mramm> they are completely unrelated
[02:29] <mramm> yes
[02:29] <davecheney> ok
[02:30] <davecheney> please view my comments above with respect only to the 1gb issue
[02:30] <mramm> and the later is that we can't bootstrap on a 512 node anymore
[02:30] <davecheney> mramm: ahh, that is why i am confused
[02:30] <davecheney> 512mb nodes are a kvm thing ?
[02:30] <davecheney> correct ?
[02:37] <davecheney> mramm: is there an issue for the 1gb / 512mb problem ?
[02:43] <thumper> mramm: sorry those emails hadn't arrived, I thought I had sent them but the email client was stuck asking me to sign things
[02:45] <mramm> dave I don't know where the issue is or even if there is a bug filed, sorry
[02:47] <davecheney> mramm: i will follow up with rog to see if he raised an issue
[02:47] <davecheney> mramm: i've seen the other side of the conversation on the golang-dev ML
[02:49] <davecheney> the gui has just crapped out on me as well
[02:49] <davecheney> looking at the unit
[02:49] <davecheney> the gui process has died ...
[02:51] <davecheney> oooooooooooooh, interesting
[02:51] <davecheney> this is a chrome issue
[02:51] <davecheney> one chrome tab was showing the SSL warning
[02:51] <davecheney> which was blocking any other connectino to that site ....
[02:54] <thumper> nice huge mechanical branch coming
[02:58] <thumper> wallyworld, axw: rack up the reviews you need in the order you need them
[02:58] <thumper> I'll drill through them after I have kids from school
[02:58]  * thumper goes to put on shoes
[02:58] <axw> thumper: I see you've lgtm'd sshstorage (thanks); just this one now: https://code.launchpad.net/~axwalk/juju-core/sanity-check-constraints/+merge/185015
[02:58] <wallyworld> https://codereview.appspot.com/13763044/
[02:59] <wallyworld> https://codereview.appspot.com/13800043/
[02:59] <thumper> axw: you can take a look at my testbase branch
[02:59] <axw> thumper: yep, will do
[02:59] <thumper> https://codereview.appspot.com/13694046
[02:59] <thumper> all it does is move a few things
[03:09] <thumper> axw: are you landing the sshstorage?
[03:09] <thumper> if so, I'll wait for my as they'll clash
[03:09] <axw> thumper: I can wait for you to land that one if you like
[03:10] <thumper> ok, I'll land it
[03:10] <axw> thanks
[03:10] <thumper> axw: I'd prefer to avoid importing checkers into testbase, but we could, as long as we make sure that it is just that
[03:10] <axw> thumper: nps, just leave it till it's an issue
[03:11] <thumper> approved it, so lets see if it lands :)
[03:11] <axw> thumper: did you land the sshstorage test one?
[03:11] <axw> yes
[03:12] <thumper> yes
[03:14] <axw> thumper: does mocking out ssh/sudo really make the test whitebox? the fact that it's in the same package is really just an unfortunate requirement
[03:14] <thumper> hmm...
[03:14] <thumper> perhaps not
[03:14] <thumper> I'm flexible
[03:15] <axw> I'll leave it. I think we may move the SSH stuff out to another package later anyway, for centralising common flags
[03:23] <thumper> wallyworld: /environs/tools/tools_test.go is still using filepath, do you know where?
[03:23] <wallyworld> in the mp?
[03:24] <thumper> nm
[03:24] <thumper> I' look
[03:24] <thumper> and it is ok
[03:24] <wallyworld> sigh, another one https://codereview.appspot.com/13694047
[03:32] <thumper> kid says "take me to hockey now, I have a game at 4"
[03:32]  * thumper afk for a few minutes.
[03:57] <thumper> axw, wallyworld: where are we up to on reviews needed?
[03:57] <wallyworld> thumper: i've got 3
[03:57] <axw> thumper: I'm all good now
[03:57] <wallyworld> let me check them to see what's approved
[03:58] <axw> thumper: I'm just going to make sure my null provider stuff still works with all the changes to sshstorage and co, then I'll land manual bootstrap and propose null provider
[03:58] <wallyworld> thumper: default hp cloud set up is not needed anymore because there's nothing hp cloud specific anymore
[03:59] <thumper> wallyworld: how do the users point openstack at hpcloud?
[03:59] <wallyworld> what do you mean?
[03:59] <thumper> axw: ok
[03:59] <thumper> wallyworld: well, I want to go bootstrap
[03:59] <wallyworld> they set their credentials same as now
[03:59] <thumper> how does it know where to look?
[03:59] <wallyworld> it uses the credentials
[03:59] <thumper> you suggest os env vars
[04:00] <thumper> ?
[04:00] <wallyworld> no, they set in yaml or env vars
[04:00] <wallyworld> their choice
[04:00] <thumper> ok, fair enough
[04:00] <thumper> do the users know that hpcloud is openstack?
[04:00] <wallyworld> before, hp cloud was different because the public bucket url was needed
[04:00] <wallyworld> they don't need to know that
[04:01] <thumper> I'm just wondering if it is nice to keep hpcloud as an option since it is a certified cloud
[04:01] <wallyworld> the only hp cloud difference was the public bucket url, else it is just standard openstack
[04:01] <thumper> wallyworld: but you have removed hpcloud as an option
[04:01] <wallyworld> no need
[04:01] <thumper> in the config
[04:01] <wallyworld> yes, because there is no hp cloud specific config
[04:01] <thumper> I know there is no *need*, I just think it is useful
[04:01] <wallyworld> it's done via credentials
[04:01] <wallyworld> useful how?
[04:01]  * thumper slaps wallyworld for not listening
[04:02]  * wallyworld slaps thumper for the same reason
[04:02]  * thumper slaps wallyworld for slapping him
[04:02] <wallyworld> hangout perhaps?
[04:02] <thumper> wallyworld: yes, please
[04:02] <thumper> however
[04:02] <thumper> I need to go get kid 3 in 2 minutes
[04:02] <wallyworld> ok
[04:02] <thumper> only takes a few minutes
[04:02] <wallyworld> with the tests, i deliberately used text
[04:02] <thumper> I'll create a hangout and ping you when I'm back
[04:02] <wallyworld> not a const
[04:02] <wallyworld> ok
[04:19] <thumper> wallyworld: https://plus.google.com/hangouts/_/6f17da147ed6be734a284c49eb9c67086eef59b0?hl=en
[04:57] <wallyworld> davecheney: hi still working on getting the code for the release ready. i'll update the release notes tonight. i assume that will be ok?
[04:59] <davecheney> wallyworld: sure
[05:00] <davecheney> wallyworld: it's more important to get it right, than to get it out there tonight
[05:00] <davecheney> if you need more time, just say
[05:00] <wallyworld> yep. pushing shit uphill, but getting there
[05:01] <davecheney> wallyworld: the friday date is fairly arbitary
[05:01] <wallyworld> i've 3 branches to land then test
[05:26] <wallyworld> davecheney: do you have credentials to write to the s3 public bucket?
[05:26] <davecheney> wallyworld: will /msg
[05:26] <wallyworld> ok
[05:29] <thumper> ick
[05:29] <thumper> axw: got a minute?
[05:29] <axw> thumper: yes?
[05:30] <thumper> axw: hangout?
[05:30] <axw> sure
[05:30] <thumper> axw: https://plus.google.com/hangouts/_/43172cdd0670d5faaae767a84e0c0fe72923a9ea?hl=en
[05:37] <davecheney> AAAAAAAAAAAAARHRHG
[05:37] <davecheney> lucky(~/charms/precise/galaxy/hooks) % juju add-machine -n10
[05:37] <davecheney> error: flag provided but not defined: -n
[05:37] <davecheney> WHY
[05:38] <wallyworld> davecheney: are you thinking of add-unit?
[05:39] <wallyworld> add-machine doesn't take a -n parameter
[05:46] <davecheney> wallyworld: it would be good if it did
[05:46] <wallyworld> yeah. no one has asked for it that i know of
[05:46] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1214209
[05:46] <_mup_> Bug #1214209: cmd/juju: add-machine should take a -n param <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1214209>
[05:47] <wallyworld> fair enough
[05:58] <axw> :(
[05:59] <axw> thumper: you know how I changed sshstorage to create/remove the tempdir on Put?
[05:59] <axw> it's not going to work
[05:59] <thumper> why
[05:59] <axw> storage goes to /var/lib/juju/storage
[05:59] <axw> tempdir to /var/lib/juju/storage.tmp
[06:00] <thumper> and...
[06:00] <axw> /var/lib/juju/storage gets created under sudo, and chown'd to $SUDO_UID
[06:00] <axw> then.,..
[06:00] <thumper> hmm
[06:00] <thumper> how about /var/lib/juju/storate/.tmp ?
[06:00] <axw> another, non-sudo shell is executed to do the transfers
[06:00] <axw> that just means we can't have .tmp in storage, which I suppose is reasonable
[06:01] <rogpeppe> mornin' all
[06:01] <axw> morning rogpeppe
[06:01] <rogpeppe> axw: hiya
[06:01] <davecheney> ave
[06:02] <axw> thumper: by which I mean, the user can't Put anything starting with ".tmp"
[06:03] <thumper> axw: yeah...
[06:03] <thumper> axw: however your tmp dir is now removed after right?
[06:03] <thumper> axw: doesn't the function to create a tmpdir take a prefix?
[06:03] <thumper> and won't clash with names?
[06:04] <axw> thumper: yes, but if you die before removing it
[06:04] <axw> then you have something in storage
[06:04] <thumper> yes, that is a risk
[06:05] <thumper> but managable compared to the other options I think
[06:10] <rogpeppe> thumper: testbase looks good (not keen on "base" in names in general, but can't think of a better one here)
[06:10] <thumper> rogpeppe: axw and I brainstormed some names
[06:10] <thumper> and it was the best we could come up with
[06:10] <thumper> I'm particularly fond of the test that makes sure it doesn't grow dependencies
[06:11] <rogpeppe> thumper: one thing though: how about Patch rather than PatchValue? the lines that use it tend to be longish anyway, so the extra horizontal space is useful.
[06:11] <thumper> Patch doesn't say what it is patching
[06:11] <thumper> it isn't a descriptive name
[06:12] <rogpeppe> thumper: it's patching its argument, which is (by definition) a value
[06:12] <thumper> no, sorry I disagree
[06:12] <rogpeppe> thumper: "Value" doesn't really add any, erm, value there
[06:13] <rogpeppe> thumper: i think it works well for the basic patching mechanism
[06:13] <rogpeppe> thumper: and it's a reasonable compromise between PatchValue and Set :-)
[06:14] <thumper> my suggesting is this: if you still think strongly that we should change it by the time we all get together in SFO, then we can get a team concensus
[06:14] <thumper> then we can run sed -i on the codebase
[06:14] <thumper> but give it a little time to settle
[06:15] <thumper> we should schedule a session for pure bikeshedding :)
[06:15]  * thumper is at EOW
[06:15]  * rogpeppe sobs that it was his shed originally :-)
[06:15] <rogpeppe> thumper: have fun
[06:15]  * thumper throws pink paint at rogpeppe's shed and runs
[06:16] <wallyworld> rogpeppe: are you an ec2 expert? we are getting access denied trying to access http://juju-dist.s3.amazonaws.com/ and i have no idea why
[06:16] <wallyworld> hence juju is currently broken for ec2
[06:16] <rogpeppe> wallyworld: oh shit
[06:17] <rogpeppe> wallyworld: i am by no means an ec2 expert
[06:17] <wallyworld> i tried sync tools and aborted it after it had uploaded a few tarballs. not sure if that caused it. i can't see how
[06:17] <wallyworld> i also aborted uploads to hp cloud etc and no problem
[06:17] <rogpeppe> that *shouldn't* have caused a problem
[06:18] <rogpeppe> wallyworld: so did it stop working immediately after your abort?
[06:18] <wallyworld> i think so
[06:22] <wallyworld> may fwereade knows? or mgz?
[06:23] <rogpeppe> wallyworld: i don't have any s3 access at all
[06:23] <rogpeppe> wallyworld: i wonder if this might be an amazon issue
[06:23] <wallyworld> i sure hope so
[06:23] <rogpeppe> % s3 put /tmp/x s3://pefkesnjesesvds
[06:23] <rogpeppe> ERROR: S3 error: 403 (InvalidAccessKeyId): The AWS Access Key Id you provided does not exist in our records.
[06:24] <wallyworld> so i guess we wait a bit
[06:24] <wallyworld> and see if they fix anything
[06:24] <rogpeppe> wallyworld: hmm, status.aws.amazon.com doesn't indicate anything amiss
[06:25] <rogpeppe> wallyworld: could you install s3cmd and try making a bucket, please?
[06:25] <rogpeppe> wallyworld: just to see if you get the same issue
[06:25] <wallyworld> ok
[06:26] <wallyworld> i can create one
[06:28] <davecheney> wallyworld: do i need to declare an emergency
[06:28] <hazmat> wallyworld, i'm an expert..
[06:28] <davecheney> it's 3:30pm in japan
[06:28] <wallyworld> hazmat: any idea why we are getting access denied all of a sudden trying to read the juju-dist bucket?
[06:28] <hazmat> davecheney, its sounds like its just an upload issue not a public issue
[06:29] <hazmat> wallyworld, are you using the correct account..
[06:29] <hazmat> wallyworld, are you sure you don't have some openstack/canonistack stuff in your env
[06:29] <wallyworld> hazmat: i was testing sync-tools and aborted a tarball upload part way through with Ctrl^C. but surely that could not have caused it?
[06:29] <rogpeppe> hazmat: it should be globally readable
[06:29] <hazmat> ie. your actually using an aws account
[06:29] <wallyworld> hazmat: yes
[06:29] <hazmat> rogpeppe, we're talking about upload
[06:29] <hazmat> wallyworld, i've seen that error when i accidentally try to use an openstack account against aws
[06:30] <hazmat> alternatively when an iam account i'm using is deleted
[06:30] <rogpeppe> hazmat: i can't access that url, which i think i should be able to
[06:30] <hazmat> rogpeppe, who is the owner of the account / bucket?
[06:30] <wallyworld> hazmat: i'm almost 100% sure i used the correct account details
[06:30] <davecheney> hazmat: gustavo
[06:30] <rogpeppe> hazmat: niemeyer
[06:31] <hazmat> hmm.. too early for him..
[06:31] <hazmat> one moment.. checking the bucket with creds
[06:35] <rogpeppe> wallyworld, hazmat: FWIW i see the same issue, though i can in fact upload to my own buckets (i'm not sure why s3cmd was failing to do that)
[06:35] <hazmat> wallyworld, davecheney, rogpeppe ... okay verified the account works
[06:36] <hazmat> i can upload files to the bucket, and remove them
[06:36] <rogpeppe> hazmat: to juju-dist?
[06:36] <hazmat> rogpeppe, yes
[06:36] <hazmat> the problem is that the permissions on the account are restricted
[06:36] <wallyworld> so why do we get access denied reading it?
[06:36] <hazmat> i can't for example list all the buckets on the account
[06:36] <hazmat> but i can list th contents of that bucket, and r/w to that bucket
[06:37] <hazmat> read access to juju-dist would be a separate issue
[06:37] <hazmat> er... public read access
[06:37] <rogpeppe> oh, ffs, s3cmd doesn't look at the usual env vars
[06:38] <wallyworld> hazmat: so you can fix the permissions?
[06:38] <wallyworld> i wonder how they changed
[06:38] <hazmat> wallyworld, well first i want to verify if its an actual issue
[06:38] <wallyworld> juju doesn't work
[06:38] <hazmat> wallyworld, it works for me..
[06:38] <wallyworld> not for me or rogpeppe :-( or davecheney
[06:39] <hazmat> i'm in the middle of a class, and we've been deploying units and services in different envs this whole time
[06:39] <hazmat> those envs were already bootstrapped though.. but the tool logic is pretty constant on pinging the pub bucket
[06:39] <wallyworld> once bootstrap happens i don't think it uses the pub bucket anymore
[06:40] <hazmat> wallyworld, hmm.. ic what you mean
[06:40] <hazmat> wallyworld, checking
[06:40] <hazmat> wallyworld, you can still download tools from the bucket.. http://juju-dist.s3.amazonaws.com/tools/juju-1.13.2-saucy-i386.tgz
[06:40] <davecheney> ahh, but we cannot list the bucket ...
[06:40] <hazmat> for example
[06:41] <wallyworld> hazmat: yes
[06:41] <davecheney> i woner if we've passed some limit
[06:41] <hazmat> we should be using an explicit index anyways..
[06:41] <davecheney> ie, the number of rows to return ?
[06:41] <hazmat> ie. a json/yaml file we create..
[06:41] <davecheney> maybe it isn't 200
[06:41] <hazmat> relying on aws default output isn't sane
[06:42] <rogpeppe> hazmat: you can't rely on list-bucket?
[06:42]  * hazmat looks into the bucket perms
[06:42] <davecheney> hazmat: i guessed at the limit
[06:42] <hazmat> rogpeppe, juju does not do list-bucket
[06:42] <hazmat> rogpeppe, we don't require every use to have an aws account
[06:42] <hazmat> every user.
[06:43] <wallyworld> juju does list buvket
[06:43] <rogpeppe> hazmat: list-bucket is just a GET of the bucket, no?
[06:43] <wallyworld> when it looks for the tools
[06:43] <hazmat> not quite
[06:43] <hazmat> rogpeppe, yes.. but its a bit more involved for pagination, etc
[06:43]  * wallyworld has to run away for a bit. back a bit later
[06:43] <rogpeppe> hazmat: agreed. but we do that.
[06:43] <rogpeppe> hazmat: is there a problem with doing that?
[06:44] <rogpeppe> hazmat: there are definite advantages to relying on ec2 itself to provide data about what files are uploaded
[06:45] <hazmat> rogpeppe, wallyworld, davecheney fixed
[06:45] <rogpeppe> hazmat: in particular it means that you can concurrently upload tools without worrying about maintaining a shared "directory" file (something i'm not is possible in s3)
[06:45] <hazmat> http://juju-dist.s3.amazonaws.com
[06:45] <rogpeppe> hazmat: yup, that's better
[06:45] <rogpeppe> hazmat: what was the problem?
[06:45] <hazmat> rogpeppe, we control the upload process, we should define our format
[06:45] <hazmat> rogpeppe, the bucket perms had changed to not be public
[06:45] <rogpeppe> hazmat: how tf did that happen?
[06:46] <hazmat> rogpeppe, and updating an index file allows us the flexibility to host tools elsewhere
[06:46] <rogpeppe> hazmat: we're moving towards using "simple" streams for all of this
[06:46] <hazmat> relying on aws .. means they change something and we break.. and we have multiple impls if we have to go somewhere else
[06:46] <hazmat> rogpeppe, good
[06:48] <hazmat> rogpeppe, wallyworld, davecheney if you want the gory xml details.. here's previous and current of the bucket acl.. http://pastebin.ubuntu.com/6131371/
[06:49] <hazmat> something reset the bucket perms..
[06:49] <hazmat> it seems like
[06:50] <hazmat> to only allow owner access.. anyways.. its fixed afaics, heading back to class
[06:50] <rogpeppe> hazmat: yeah
[06:50] <rogpeppe> hazmat: thanks
[06:50] <hazmat> np
[08:55] <rogpeppe> fwereade, dimitern, mgz, axw: small review anyone? https://codereview.appspot.com/13806043/
[08:56] <axw> rogpeppe: looking
[08:56] <rogpeppe> axw: thanks!
[10:04] <wallyworld> i have a branch for review for the 1.15 release. tim started it but got stuck when ec2 failed earlier. i took his work and added a test and here it is https://codereview.appspot.com/13642045
[10:06] <mgz> wallyworld: looking
[10:06] <wallyworld> thanks :-)
[10:29] <natefinch> Is it just me, or do the menus on www.ubuntu.com look totlaly messed up?
[10:39] <rogpeppe> natefinch: me too
[10:40] <rogpeppe> another trivial review: https://codereview.appspot.com/13780044/
[10:40] <natefinch> rogpeppe: I'll take a look
[10:40] <rogpeppe> natefinch: thanks
[10:42] <natefinch> rogpeppe: done
[10:42] <rogpeppe> natefinch: ta!
[10:43] <natefinch> rogpeppe: who should I poke about www.ubuntu.com?
[10:43] <rogpeppe> natefinch: i have no idea, sorry
[10:43] <natefinch> heh no problem
[10:46] <dimitern> natefinch, fwereade, rogpeppe, wallyworld: standup?
[10:54] <dimitern> rogpeppe, fwereade : a quick review after standup? https://codereview.appspot.com/13636044/
[11:06] <fwereade> rogpeppe, wallyworld, mgz, dimitern, natefinch: sorry, I'm trying to get back in
[11:19] <fwereade> gents, my audio is appallingly bad, I think we stick with "don't do that then" and hope that everybody can remember that until we have simplestreams online
[12:16]  * fwereade pops out for coffee
[12:18]  * rogpeppe just got bitten by this bug. it really confused me! https://bugs.launchpad.net/gocheck/+bug/1228105
[12:18] <_mup_> Bug #1228105: panic in TearDownTest obscures original test panic <Gocheck:New> <https://launchpad.net/bugs/1228105>
[13:26] <sinzui> natefinch-afk, does https://launchpad.net/juju-core/+milestone/1.14.1 need a bug fix to address the missing azure documentation?
[13:35] <rogpeppe> trivial review anyone? https://codereview.appspot.com/13775046
[13:35] <rogpeppe> took a while to diagnose that!
[13:36] <rogpeppe> fwereade, dimitern, mgz: ^
[13:37] <fwereade> rogpeppe, looking
[13:38] <mgz> metoo
[13:38] <rogpeppe> fwereade: oh it would be so good to sort out JujuConnSuite. i think we're heading in the right direction with the configstore interface actually
[13:39] <mgz> ugh, this is all so fragile
[13:39] <rogpeppe> mgz: yeah
[13:40] <fwereade> rogpeppe, LGTM
[13:40] <rogpeppe> mgz: most of it's actually unnecessary in fact
[13:40] <rogpeppe> fwereade: thanks
[13:41] <dimitern> still waiting for a review on https://codereview.appspot.com/13636044/ please
[13:41] <dimitern> rogpeppe, fwereade ^^ ?
[13:41] <rogpeppe> fwereade: i kind of agree about nestable fixtures, but i'm not really sure why this CL implies the need
[13:42] <rogpeppe> dimitern: looking, sorry
[13:43] <fwereade> rogpeppe, it looked like we were half-assing a fixture with sub-Test-method setup/teardown effectively
[13:44] <rogpeppe> fwereade: that actually works ok in general - it's not really nesting as such, more splitting.
[13:44] <rogpeppe> fwereade: i wish fixtures looked less like test suites though
[13:47] <rogpeppe> dimitern: can't a machine tell its container type just by looking at its id?
[13:51] <dimitern> rogpeppe, I prefer to have an explicit method
[13:51] <rogpeppe> dimitern: why do we need another API round trip for this?
[13:52] <dimitern> rogpeppe, it's still the same - no more roundtrips
[13:53] <rogpeppe> dimitern: oh, i guess that's true. but still, i'm not entirely convinced it's worth denormalising here.
[13:54] <dimitern> rogpeppe, denormalising what?
[13:55] <rogpeppe> dimitern: storing the container type redundantly to the id which directly implies it
[13:56] <dimitern> rogpeppe, then why do we have a ContainerType method on machine, or even a doc field?
[13:56] <rogpeppe> dimitern: hmm, good point
[13:56] <rogpeppe> dimitern: about the doc field anyway
[13:57] <dimitern> rogpeppe, the fact the machine id implies the container type is a side-effect, I think, does not merit doing tricky magical stuff in the api, just because we know its format
[13:58] <wallyworld> fwereade: i have a small mp to fix an issue with hp cloud that i found while smoke testing the 1.15 release https://codereview.appspot.com/13789045
[13:58] <rogpeppe> dimitern: you may be right there. tbh, i think that it's pretty dodgy that the agent needs to know its container type - it looks pretty hacky to me
[13:58] <rogpeppe> dimitern: it would be more regular if lxc machines had an lxc job, or something like that
[13:59] <dimitern> rogpeppe, perhaps, but we're not there yet
[13:59] <fwereade> wallyworld, ha, Isee, good catch
[13:59] <rogpeppe> dimitern: fair enough
[13:59] <fwereade> rogpeppe, agreed and understood hacky, but out of scope for now ;)
[14:00] <rogpeppe> dimitern: reviewed
[14:01] <dimitern> rogpeppe, ta!
[14:09] <fwereade> wallyworld, LGTM
[14:09] <wallyworld> fwereade: great thanks, landing now
[14:11] <fwereade> wallyworld, there's some code commented out you might want to remove first
[14:11] <wallyworld> fwereade: yeah, already done :-)
[14:11] <wallyworld> it's late, i'm tired, stupid typo
[14:14] <fwereade> wallyworld, I know the feeling, get some rest :)
[14:15] <wallyworld> soon, will just land the branch
[14:16] <motter> out of curiosity, does all of juju's logging code write to syslog?
[14:16] <motter> (i'm looking at https://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/log/)
[14:17] <mgz> motter: we've been moving that way
[14:18] <mgz> for the agents that run on remote machines at least
[14:18] <motter> the loggo package does levels, is that configured to write to syslog too?
[14:19] <mgz> yes, there should be a correspondance
[14:20] <motter> mgz: thanks
[14:20] <motter> we're also using syslog, but i'm curious as to what other projects are doing
[14:58] <sinzui> I need help setting up a reliable test env/config. I always get failures running trunk and 1.14. I doubt the suite is really broken.
[14:59] <rogpeppe> sinzui: what failures are you seeing?
[15:00] <sinzui> rogpeppe, http://pastebin.ubuntu.com/6133051/
[15:00] <rogpeppe> sinzui: what version of mongod have you got installed?
[15:01] <sinzui> db version v2.4.6
[15:01] <rogpeppe> sinzui: could you paste the output of mongod --help, please?
[15:02] <sinzui> rogpeppe, http://pastebin.ubuntu.com/6133061/
[15:03] <rogpeppe> sinzui: hmm, that looks ok. although i'm actually using 2.2, so it's possible there's a problem with later versions.
[15:03] <rogpeppe> sinzui: i think it's *probably* a mongod problem
[15:04] <sinzui> rogpeppe, I have mongod running on my system by default. I don't think I have messed with it (I build my apps in containers)
[15:04] <rogpeppe> sinzui: what version of ubuntu are you running?
[15:05] <sinzui> saucy
[15:08] <rogpeppe> sinzui: hmm, i don't know what the status of juju on saucy is currently. mgz?
[15:08] <rogpeppe> sinzui: the version of mongo i get with "sudo apt-get install mongodb-server" is v2.2.4, which is earlier than yours
[15:09] <mgz> should e working...
[15:09] <rogpeppe> mgz: do you know anything about what versions of mongo juju currently works with?
[15:09] <mgz> youmean it's not all of them? :)
[15:09] <rogpeppe> mgz: well, it looks like it fails with 2.4.6
[15:10] <sinzui> I have a precise container. I can try running the suite from there
[15:10] <rogpeppe> sinzui: i'm running raring and it works ok there
[15:11] <rogpeppe> sinzui: you could try grabbing the mongod binary from juju-dist.s3.amazon.com
[15:11] <rogpeppe> sinzui: are you running the standard mongod installed with saucy? (i'm presuming so)
[15:12] <sinzui> I am
[15:12] <sinzui> and I have deployed many times with it. I see no signs of breakage
[15:13] <rogpeppe> anyone else here running saucy?
[15:17] <rogpeppe> sinzui: i think i see a possible fix - looks like mongo have changed their error messages
[15:17] <rogpeppe> sinzui: could you try editing testing/mgo.go for me please
[15:18] <sinzui> one moment, I am running the tests in a precise container
[15:19] <rogpeppe> sinzui: and change the isUnauthorized function to this: http://paste.ubuntu.com/6133129/
[15:19] <sinzui> rogpeppe, I have the file open, I will make the change when the suite completes
[15:19] <rogpeppe> sinzui: that might *possibly* fix your problem
[15:23] <sinzui> The test run is taking forever in this container. but it is also passing where it failed for saucy
[15:31] <sinzui> thank you rogpeppe, the patch is better, only one failure: http://pastebin.ubuntu.com/6133177/
[15:31] <sinzui> The tests passed in my precise container. I am unblocked for now, and can test more patches if you like
[15:32] <rogpeppe> sinzui: ah, that looks like exactly the same issue in a different guise
[15:35] <rogpeppe> sinzui: could you try one more thing for me, please
[15:35] <rogpeppe> ?
[15:35] <rogpeppe> sinzui: if you could try another version of isUnauthorized and paste me what the panic prints, that would be very useful: http://paste.ubuntu.com/6133195/
[15:35] <rogpeppe> sinzui: then i'll be able to submit an appropriate patch to trunk
[15:36]  * sinzui runs tests
[15:41] <sinzui> sorry rogpeppe , quite errors this time: http://paste.ubuntu.com/6133222/
[15:42] <rogpeppe> sinzui: thanks; line 31 is all i need
[15:42]  * rogpeppe wishes mongo could sort out its error codes
[16:31] <mgz> filed bug 1228255 for my live test woes earlier
[16:31] <_mup_> Bug #1228255: Live bootstrap tests fail on canonistack <juju-core:Confirmed> <https://launchpad.net/bugs/1228255>
[16:34] <rogpeppe> sinzui: ping
[16:35] <sinzui> hi rogpeppe
[16:35] <rogpeppe> sinzui: could you pull this branch and try testing it, please. i hope it should fix your problem: lp~rogpeppe/juju-core/409-fix-for-mongo.2.4
[16:35]  * sinzui does
[16:49] <sinzui> rogpeppe, I have one failure. I don't think it is related to your work. I think I have the deps wrong when I switched back to trunk: http://paste.ubuntu.com/6133503/
[16:51] <rogpeppe> sinzui: could you paste the whole of that failure log please?
[16:51] <rogpeppe> sinzui: (no, i don't think it's related either)
[16:51] <sinzui> goose and mgo had higher revnos. I just reverted to what the dependencies.tsv listed
[16:51] <rogpeppe> sinzui: try this (in the juju-core root directory): go get launchpad.net/godeps; godeps -u *.tsv
[16:52] <rogpeppe> sinzui: ah, or manually, sure
[16:52] <sinzui> rogpeppe, I did. it warned that the branches were on the wrong version. I assumed it would correct that
[16:53] <sinzui> this is the full log: http://paste.ubuntu.com/6133515/
[16:53]  * sinzui runs tests again
[17:04] <rogpeppe> sinzui: you can run that test alone to get a quicker turnaround time: go test launchpad.net/juju-core/cmd/juju -gocheck.f TestAutoUploadAfterFailedSync
[17:04] <rogpeppe> sinzui: i'd like to know if it fails consistently in saucy
[17:05] <sinzui> sorry rogpeppe. I don't know how to clean goose and v2/mgo. godeps says the are not clean when I run clean on them
[17:05] <rogpeppe> sinzui: if in doubt, remove them and go get them again.
[17:05] <rogpeppe> sinzui: e.g. rm -r $GOPATH/src/launchpad.net/goose
[17:06] <rogpeppe> sinzui: rm -r $GOPATH/src/labix.org/v2/mgo
[17:06] <rogpeppe> sinzui: go get launchpad.net/goose labix.org/v2/mgo
[17:07] <rogpeppe> sinzui: if you want to know *why* they're considered unclean, go into the directory and run "bzr status"
[17:07] <sinzui> goody. I will try that next time. I am getting the code again
[17:09] <sinzui> rogpeppe, http://paste.ubuntu.com/6133582/ shows the failure again
[17:09] <rogpeppe> sinzui: ok, that's useful thanks
[17:11] <rogpeppe> mgz, fwereade, dimitern: saucy fix CL review? https://codereview.appspot.com/13808043
[17:13] <mgz> looking
[17:24] <rogpeppe> fwereade: ping
[17:26] <mgz> rogpeppe: reviewed
[17:27] <rogpeppe> mgz: we're using standard base64 (as witness the StdEncoding below.
[17:27] <mgz> so, that change shouldn't be needed than?
[17:27] <rogpeppe> mgz: but i'm actually inclined to use '[^']*'
[17:28] <rogpeppe> mgz: why not? standard encoding includes + and /, no?
[17:28] <rogpeppe> mgz: (neither of which were in the original regexp)
[17:32] <mgz> ah, yes, I misread
[17:32] <mgz> the change is correct
[17:37] <natefinch-afk> smoser: have a minute?
[17:37] <smoser> here
[17:37] <natefinch> smoser: Having difficulty ssh'ing into the maas virtual machines (it worked yesterday and then today somehow it's not... probably user error)
[17:38] <natefinch> smoser: I recreated the machins with 1024M of RAM, since we'd seen some problems lately bootstrapping with 512
[17:38] <smoser> k
[17:39] <natefinch> smoser: maybe I messed something up... what's weird is that juju bootstrap seems to run ok (at least from what I see locally), but then I try to ssh insto the machine, and it says it can't find a machine with that name
[17:39] <smoser> natefinch, its the hack that i told you about.
[17:39] <smoser> you have to fix /etc/resolv.conf now. i'll do it.
[17:39] <natefinch> natefinch: I figured there was something I'd forgotten
[17:39] <smoser> what happened that changed is that your dhclient lease came up
[17:39] <smoser> and it rewrote /etc/network/interfaces
[17:40] <smoser> i dont have a real solution for this at the moement.
[17:40] <natefinch> ahh ok no problem
[17:41] <natefinch> smoser: I'll leave myself a note so I don't forget next time
[17:42] <smoser> natefinch, i think its fixed now
[17:43] <smoser> basically just re-wrote /etc/resolv.conf but to have '127.0.0.1' as the nameserver
[17:43] <smoser> now , 'host inst-001.master' works
[17:43] <natefinch> smoser: yep, saw it.  That did it. Thanks.  Wrote myself a note to remind me to do that if this happens again.
[17:43] <smoser> i also just added 'search master'
[17:44] <natefinch> Cool
[17:44] <smoser> i'd like to have a real fix for that, but ... time.
[17:44] <natefinch> yuuup
[17:44] <smoser> on canonistack instances the dhclient lease is 2 minutes.
[17:44] <smoser> so you get to re-apply every 2 minutes :)
[17:44] <natefinch> OMG
[17:45] <natefinch> crazy
[18:14] <rogpeppe> sinzui: i've managed to reproduce your test failure locally, and the fix is straightforward, i think. i reported the bug here: https://bugs.launchpad.net/juju-core/+bug/1228315
[18:14] <_mup_> Bug #1228315: cmd/juju test failure under saucy <juju-core:New> <https://launchpad.net/bugs/1228315>
[18:15] <sinzui> thank you very much rogpeppe
[18:15] <rogpeppe> sinzui: the mongo fix is now in trunk, BTW
[18:15] <sinzui> fab
[18:51] <rogpeppe> natefinch, fwereade, dimitern, wallyworld: a simple review? after this, saucy tests should run ok, theoretically. https://codereview.appspot.com/13811043
[18:51] <natefinch> rogpeppe: I can take it
[18:52] <rogpeppe> natefinch: thanks
[18:53] <rogpeppe> sinzui: perhaps you could try out lp:~rogpeppe/juju-core/410-only-one-version and verify that it fixes the problem?
[18:53]  * sinzui does
[18:54] <rogpeppe> sinzui: ta
[18:56] <natefinch> rogpeppe: I like the change, but it doesn't look like it would change the behavior unless /etc/lsb-release changes while you're running.  What is it fixing, other than reparsing the same data over and over?
[19:02] <sinzui> rogpeppe, saucy loves your branch.
[19:06] <rogpeppe> sinzui: good to hear!
[19:07] <rogpeppe> natefinch: it fixes tests that patch version.Current
[19:07] <natefinch> rogpeppe: aahhhh yep
[19:10] <hatch> when newbies follow the lxc guide and run `juju boostrap -e local` then follow up with a `juju status` the error message is that it can't connect and to check your credentials
[19:10] <hatch> this will be very confusing
[19:11] <hatch> I am guessing there is no way to know that the bootstrap node is still starting up
[19:11] <hatch> but maybe a 'your bootstrap node might still be starting' message could be added?
[19:28] <natefinch> hatch:  a friendlier error message might be all we really need
[19:29] <hatch> natefinch: that's what I was thinking - any 'real' sollution is probably a little too fragile
[19:29] <hatch> shall I file a bug ?
[19:33] <natefinch> hatch: go for it
[21:11] <jamespage> sinzui, 1.14.1 all done - should build in the stable PPA shortly
[21:12] <sinzui> wow. Thank you for your dedication jamespage
[21:12] <jamespage> sinzui, np
[21:48] <hatch> awesome!