[00:04] <davecheney> sigh, i guess I can't put off looking at simple streams bugs any longer
[00:04] <davecheney> waigani: how you doing today?
[00:05] <waigani> hi davecheney, well after blowing up my vm, I'm now back on track.
[00:05] <waigani> so just starting to look at the tests now
[00:06] <waigani> davecheney: I noticed you start your branches with 106, 111 etc - what is that?
[00:06] <waigani> is there a convention I should follow for branch names?
[00:07] <davecheney> waigani: we all started doing that years ago
[00:07] <davecheney> for me it was because i couldn't remembver what I had comitted and what I hadn't
[00:07] <davecheney> you can do whatever makes sense
[00:08] <davecheney> waigani: for me the branch name is entirely to remind me
[00:08] <davecheney> so they tend to be long
[00:08] <davecheney> and descriptie
[00:09] <waigani> okay, including the bug no. makes sense
[00:12] <waigani> davecheney: you might want to add installing mercurial to your tl;dr
[00:13] <davecheney> waigani: everyone has permission to update those deps
[00:13] <davecheney> I think when i wrote it code.google.com was blocked bythe firewall
[00:13] <davecheney> so I had to copy those deps in by hand
[00:13] <davecheney> waigani: everyone has permission to update that install doc
[00:13] <waigani> okay, I'll add it in
[00:17] <Valduare> hows it going guys
[00:19] <davecheney> Valduare: good
[00:19] <davecheney> and yourself
[00:19] <Valduare> doing well
[00:20] <Valduare> doing photoshoot this week at the wife’s dance studio - on irc in between :P
[00:20] <Valduare> looks like few updates to my bug https://bugs.launchpad.net/juju-core/+bug/1300264
[00:20] <_mup_> Bug #1300264: manual provisioning requires target hostname to be directly resolvable <manual-provider> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1300264>
[00:21] <davecheney> Valduare: axw is will be in an hour or so
[00:21] <Valduare> ok
[00:35] <perrito666> if anyone has a moment to spare https://codereview.appspot.com/83370043
[00:38] <davecheney> perrito666: quick review, please fix the typos in the descriptoin
[00:38] <davecheney> you can use
[00:38] <davecheney> lbox propose -edit
[00:38] <perrito666> davecheney: thank you
[00:39]  * perrito666 should not propose during night
[00:43] <perrito666> davecheney: thank you, reproposed, if any typo is still there it might be poor English grammar on my behalf
[00:44] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1301085
[00:44] <_mup_> Bug #1301085: state/apiserver: login_test.go intermittent failure <juju-core:Triaged> <https://launchpad.net/bugs/1301085>
[00:44] <davecheney> this one is concerning
[00:44] <perrito666> davecheney: thank you for the comments, will address them
[00:50] <davecheney> mwhudson: how are you doing today ?
[00:51] <mwhudson> davecheney: i am mostly getting distracted
[00:54] <davecheney> HURRY THE GUCK UP JUJU
[00:54] <davecheney> SHIT
[00:54] <davecheney> these god damn tests take hours!
[00:55] <jpds> davecheney: Hi.
[00:57] <davecheney> jpds: speaking of frustration
[00:57] <jpds> davecheney: Quite.
[01:03] <davecheney> sinzui: http://paste.ubuntu.com/7192347/
[01:03] <davecheney> shit, results are the same as yesteday
[01:03] <davecheney> i don't understand
[01:04] <davecheney> [LOG] 36.85478 DEBUG juju.environs.configstore Making /tmp/gocheck-1976235410884491574/0/home/ubuntu/.juju/environments
[01:04] <davecheney> ... Panic: cannot share a state between two dummy environs; old "dummyenv"; new "dummyenv" (PC=0x3FFFB02F3E4F)
[01:04] <davecheney> :0
[01:04] <davecheney> brilliant :(
[01:13] <stokachu> hazmat: https://github.com/liris/websocket-client/issues/73 - im going to work with upstream to get python2/3 into one codebase so we can package a python3 version easily
[01:14] <axw> davecheney: I think that means two tests are trying to Prepare a dummy env without calling dummy.Reset() first
[01:14] <hazmat> stokachu, awesome!
[01:14] <axw> davecheney: are you just running make check, or what?
[01:16] <stokachu> hazmat: looks like i can ping andreas once thats done to have a python2 and python3 package
[01:16] <stokachu> i didnt see it in debian
[01:16] <axw> thumper: oops, sorry, I gave you bad advice about using listener.Addr() yesterday apparently
[01:16]  * thumper shrugs
[01:16] <thumper> it passed the test
[01:16] <thumper> :)
[01:16] <thumper> interestingly when I logged it out
[01:17] <thumper> it was ipv6 as a value
[01:17] <thumper> http://[::]:1234
[01:17] <hazmat> stokachu, tick tock on trusty, i'll merge in 2/3 support to jujuclient its a pretty tiny diff.. deployer might need a little more work
[01:18] <stokachu> ok ill work on it this week, the maintainer is in japan though so time differences will be difficult
[01:23] <davecheney> axw: nope
[01:23] <davecheney> go test
[01:25] <axw> davecheney: in just the configstore directory?
[01:26] <davecheney> axw: nopt
[01:26] <davecheney> nope
[01:26] <davecheney> go test launchpad.net/juju-core/...
[01:27] <axw> oh sorry that's from the log, not the test that's being run
[01:27] <davecheney> axw: i have no idea what you're talking about
[01:27] <davecheney> sorry
[01:27] <davecheney> oh
[01:27] <axw> davecheney: " [LOG] 36.85478 DEBUG juju.environs.configstore Making /tmp"
[01:27] <davecheney> it's the package name
[01:27] <davecheney> right
[01:38] <thumper> wallyworld_: https://launchpad.net/bugs/1299588
[01:38] <_mup_> Bug #1299588: LXC permission denied issue with 1.17.7 <landscape> <micro-cluster> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1299588>
[01:52] <thumper> davecheney: is there a test memory thing I can use for an io.ReaderSeeker?
[01:52] <thumper> davecheney: like bytes.Buffer
[01:52] <thumper> or somthing
[01:52] <thumper> or do I need to write a file
[01:54] <perrito666> davecheney: thanks for your help, I rewrote a part of the script and looks definitely cleaner now :D
[02:07]  * thumper writes a file...
[02:08] <axw> thumper: bytes.Reader?
[02:33] <wallyworld_> axw: thumper: you guys used an aws environment lately? the shared credentials i've been using appear to have been revoked
[02:33] <thumper> I've not used shard creds
[02:33] <axw> wallyworld_: I haven't, but I use my own account
[02:34] <wallyworld_> mmmm ok. i'll dig up som other creds
[02:34] <wallyworld_> after lunch. nom nom
[02:45] <davecheney> thumper: bytes.Reader ?
[02:45] <thumper> nm
[02:45] <sinzui> wallyworld_, CI failed failed the first attempt of joyent
[02:45] <sinzui> I am running it again
[02:54] <waigani> so a test on ppc64el needs zip, but it is not installed by default.
[02:55] <davecheney> waigani: add it to the Makefile
[02:55] <davecheney> for the install-deps section
[02:55] <davecheney> this is a server image
[02:55] <davecheney> most people test with the desktop image
[02:55] <davecheney> which has gnome fileroller
[02:55] <davecheney> so I guess it has zip
[02:55] <waigani> davecheney: okay, will do
[02:57] <waigani> hmm, it's already there
[03:05] <wallyworld_> sinzui: i'll look at the error
[03:05] <sinzui> wallyworld_, I am just reporting a bug about the issue
[03:06] <sinzui> wallyworld_, You can see the config for the env in cloud-city
[03:06] <wallyworld_> ok. i wonder why it worked for me
[03:06] <wallyworld_> i'll look at the bug
[03:06] <wallyworld_> what's cloud-city?
[03:08] <wallyworld_> sinzui: i see th error says quota exceeded - i had to hog smash wordpress and mysql onto the one machine cause the credentials i had only allow 2 machines
[03:09] <wallyworld_> sinzui: so if your test deploys wordpress an my sql, use the --to option for the second charm
[03:09] <sinzui> wallyworld_, Our test wont like exceptions. It needs 3 machines.
[03:09] <wallyworld_> :-(
[03:09] <sinzui> I will ask someone to give us proper resources
[03:09] <wallyworld_> won't work for joyent unless we get more quota
[03:09] <wallyworld_> ok
[03:10] <sinzui> We have a similar problem with azure. CI failed during the release because the release + revision testing + cloud health checks can exceed the cpu limit
[03:11] <sinzui> wallyworld_, At least I don't need to report a bug
[03:12] <wallyworld_> sinzui: and at least it looks like stuff would have worked hopfully :-)
[03:12] <sinzui> wallyworld_, yep.
[03:15] <waigani> hmm so if I install zip by hand it works. If I run make install, it doesn't get installed?
[03:18] <axw> wallyworld_ thumper: so, I can delete 1.16 compat stuff right?
[03:18] <wallyworld_> YES!
[03:18] <axw> wheee
[03:19] <wallyworld_> have fun, i'm jealous
[03:19] <axw> :)
[03:19] <axw> I'm just making changes in cmd/juju/ssh.go, figured I'll delete the compat stuff while I'm there
[03:20] <wallyworld_> yep
[03:42] <sinzui> wallyworld_, I hacked the test to make an exception for the joyent provider. http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/joyent-deploy-devel/6/console
[03:42] <sinzui> ^ same error even though --to 1 was used for mysql
[03:42] <sinzui> any other ideas?
[03:42]  * wallyworld_ looks
[03:43] <wallyworld_> sinzui: is there another orphaned machine running in that account? use the joyent daskboard to check
[03:44] <sinzui> nothing in the dashboard
[03:44] <wallyworld_> that happened to me and once i shut down the extra machine it worked
[03:44] <sinzui> but wallyworld_ I never even saw the juju machine show up
[03:44] <wallyworld_> sinzui: i can pm you the cred i used
[03:44] <sinzui> there was a machine there earlier today. I deleted it
[03:50] <thumper> fuckity fuck fuck
[03:50] <davecheney> thumper: ?
[03:51] <thumper> trying to write a test
[03:51] <davecheney> :)
[03:51] <davecheney> no, wait
[03:51] <thumper> however the behaviour is full of async
[03:51] <davecheney> :(
[03:51] <davecheney> wow. such fuck
[03:51] <thumper> multiple go rountines started
[03:51] <thumper> I kinda need to wait to know that the tailer has started listening for new lines before I have the test write a few more
[03:51] <thumper> not sure how
[03:52]  * thumper thinks...
[03:53] <wallyworld_> sinzui: there's a showstopper bug in 1.17.7 which i'm fixing :-(
[03:53] <wallyworld_> i just confirmed it
[03:54] <wallyworld_> so 1.18 will need to be held off till i fix it, which will be today
[03:54] <sinzui> wallyworld_, I found the instance. The old UI doesn't show it. The beta does
[03:54] <wallyworld_> ah
[03:54] <wallyworld_> well that kinda sucks
[03:55] <sinzui> wallyworld_, I need to get the docs completed. I wont release tomorrow
[03:55] <wallyworld_> yay, gives me time to fix
[03:56] <sinzui> this run gets farther, but I wonder how far this will go with just 2G ram
[03:58] <wallyworld_> should be enough to bring up wordpress/mysql you'd hope
[03:58] <sinzui> wallyworld_, PASS. I am going to sleep. I will find someone tomorrow to address 1 machine to test and release with
[03:58] <wallyworld_> \o/
[03:58] <wallyworld_> good night :-)
[03:59] <thumper> wallyworld_: what was the problem?
[04:00] <wallyworld_> thumper: i don't want to tell you
[04:00] <wallyworld_> it was my fault :-(
[04:00] <wallyworld_> permisison error ivoking new api from container provisioner
[04:00] <wallyworld_> works fine from env provisioner
[04:00] <thumper> ah
[04:01] <wallyworld_> our logging/error reporting kinda sucks
[04:01] <wallyworld_> we need to get this errgo stuff integrated and used
[04:02] <wallyworld_> axw: we would expect destroy-env --force to remove the jenv file right?
[04:07] <davecheney> join #go-nuts
[04:07] <davecheney> oh hai!
[04:08] <thumper> wallyworld_: yes we would
[04:08] <wallyworld_> thumper: i'll have to see if i can reproduce later, but on trunk i did a --force and the jenv file stuck around
[04:21] <axw> wallyworld_: sorry, afk. the .jenv file should be removed if destroy-env succeeds
[04:21] <axw> wallyworld_: regardless of --force
[04:21] <axw> wallyworld_: but --force *should* always succeed
[04:21] <wallyworld_> np. yeah, it seems like it wasn't. i'll have to try and reproduce
[04:21] <axw> obviously that's an ideal though
[04:22]  * axw goes back afk
[04:23] <thumper> OH FFS
[04:23]  * thumper looks for someone to stab
[04:23] <thumper> ..
[04:25] <thumper> oops
[04:25]  * thumper sighs
[04:25] <thumper> ran 'go test' instead of 'go test -gocheck.f ...'
[04:26] <thumper> oh well, all tests passed
[04:26] <thumper> yay
[04:26] <thumper> now for step 27
[04:41]  * thumper is done for now
[06:31] <jam1> axw: I'm just testing the bot for a second, I'll set your branch back to approved when I'm done
[06:32] <axw> jam: okey dokey
[07:24] <axw> jam: do you know what that error was about?
[07:24] <jam> axw: well, I killed it once
[07:25] <jam> but we also seem to have a new intermittent failure in TestRunStop
[07:25] <jam> https://bugs.launchpad.net/juju-core/+bug/1301198
[07:25] <axw> yay :(
[07:25] <_mup_> Bug #1301198: jujud Provisioner TestRunStop no activity detected <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1301198>
[07:26] <jam> and AddRemoveSet still causes problems from time to time...
[07:26] <jam> not *quite* as often as it used to
[07:30] <wallyworld_> jam: is the bot stalled?
[07:30] <jam> wallyworld_: I was poking at it, it should be back up now
[07:30] <wallyworld_> log file lasted updated 11 mins ago
[07:31] <wallyworld_> doesn't *appear* to be working
[07:31] <rogpeppe3> mornin' all
[07:31] <axw> morning rogpeppe3
[07:31] <axw> jam: did you notice this? "listen unix @/tmp/juju-core-test.ARliJS/gocheck-6334824724549167320/18/var/lib/juju/agents/unit-wordpress-0/agent.socket: invalid argument"
[07:31] <axw> jam: I wonder if the TMPDIR change has broken something
[07:32] <jam> I had not seen that.
[07:38] <jam> axw: one thing comes to mind, the /tmp/XXX dir starts with 700 permissions.
[07:38] <jam> but doesn't everything have to be running as the tarmac user anyway?
[07:38] <axw> yeah, I thought the same thing and had the same conclusion...
[07:39] <axw> it won't/can't change user
[07:44] <axw> jam: I think we may have exceeded the path length.
[07:44] <axw> max path length
[07:44] <axw> max path length is 108, that is exactly 108 - I'm guessing it needs to include the null byte
[07:45] <jam> axw: odd. We also had a problem where we rm -rf /tmp
[07:45] <jam> :)
[07:45] <jam> which I'm fixing now
[07:45] <axw> :o
[07:46] <jam> axw: if something before we set TMPDIR ran and failed, it would still hit the rm -rf TMPDIR
[07:46] <axw> ah heh :)
[07:46] <jam> so I'm setting it in another var, and only removing that one.
[07:46] <jam> axw: I didn't realize normal users could rm tmp
[07:47] <jam> axw: but that is why the bot stopped working, because it couldn't get /tmp access.
[07:47] <axw> does it not just remove all the files they own within and then fail?
[07:47] <axw> yikes, ok
[07:47] <jam> axw: well /tmp was gone
[07:47] <jam> I had to mkdir it
[07:48] <jam> axw: I don't think that is why the original failure occurred.
[07:48] <axw> jam: tmp being gone, or the invalid argument/max path limit?
[07:48] <jam> axw: you're probably right about the socket thing: https://bugs.launchpad.net/unity-scopes-api/+bug/1252588
[07:48] <_mup_> Bug #1252588: UNIX domain socket path name limit <unity-scopes-api:Fix Released by michihenning> <https://launchpad.net/bugs/1252588>
[07:48] <axw> mk
[07:49] <jam> axw: so I can make my TMPDIR prefix a bit shorter, but we were only just lucky that it was working before.
[07:50] <axw> indeed, if ever moved away from /var/lib/juju...
[07:51] <jam> axw: like with the namespacing work?
[07:51] <jam> /var/lib/juju-jameinel-local ?
[07:51] <axw> namespace only affects the log dir
[07:52] <axw> data-dir is in $HOME for machine-0 in the local provider
[07:52] <axw> but that does not allow units
[07:52] <jam> axw: so, I can reproduce directly by making TMPDIR really long and running that test.
[07:52] <jam> I made them shorter, but it still seems like we're going to get bitten sometime.
[07:53] <axw> yeah. I dunno how we're going to fix that one... perhaps the socket should be in /var/run or something
[07:53] <axw> that's no good for tests, but we could override it for tests
[07:55] <vladk> dimitern: morning
[07:56] <dimitern> morning vladk
[08:11] <jam> morning vladk and dimitern
[08:11] <vladk> jam: morning
[08:15] <dimitern> morning jam
[08:23] <jam> axw: did you see the bug about rev 2524 ?
[08:23] <axw> not yet
[08:24] <axw> oh
[08:24] <jam> axw: https://bugs.launchpad.net/juju-core/+bug/1300889
[08:24] <_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1300889>
[08:24] <axw> eh
[08:24] <jam> no shared-secret file
[08:24] <jam> error getting file /var/lib/juju/shared-secret: No such file or directory
[08:25] <axw> gah, because it doesn't exist during cloud-init
[08:25] <jam> axw: at the least, your patch should probably have included a logger.Debugf() when we were writing the file.
[08:26] <jam> axw: ah, because we write the Upstart during cloud init, but we don't run the rest of bootstrap stuff until we ssh into the machine.
[08:26] <axw> yeah, that was a bit dumb. I'll fix it...
[08:26] <jam> axw: so I think that means we just need to back out your patch until EnsureMongoServer is writing the file at a later time
[08:26] <jam> because we *don't* want to write the contents of shared-secret to cloud-init
[08:26] <axw> jam: yeah. I'll just take the --keyFile bit out of the upstart script for now?
[08:27] <jam> axw: that's probably ok
[08:27] <jam> axw: I'll note, changes during bootstrap is something that you should probably test live
[08:28] <axw> jam: I did run with local, but have no idea why it worked now
[08:28] <jam> axw: local is special
[08:28] <jam> for a lot of things
[08:28] <jam> machine-0 is your $HOST
[08:28] <jam> so not brought up via cloud-init
[08:29] <axw> mongo is still started before the machine agent though
[08:29] <jam> axw: I'm pretty sure we also don't "ssh localhost"
[08:29] <jam> axw: sure but the bootstrap steps probably happen at a different time.
[08:29] <axw> jam: we don't ssh localhost, but we run the same script via bash
[08:29] <axw> it's now very similar to cloud bootstrap
[08:29] <axw> anyway
[08:30] <axw> I will investigate, and test with azure
[08:30] <jam> kk
[08:31] <jam> I have the feeling it is broken on EC2 as well, but I haven't tested that
[08:31] <jam> I don't see any reason why it would be special
[08:32] <jam> wallyworld_: did you get your Joyent changes backported to the 1.18 branch?
[08:32] <wallyworld_> jam: yep, and CI tests passed ok \o/
[08:32] <jam> wallyworld_: nice, so we get a 1.17.8 today ?
[08:33] <wallyworld_> as soon as my bug fix gets backported but i need to get in landed in trunk first
[08:33] <jam> wallyworld_: that's what you're landing now?
[08:33] <wallyworld_> yep
[08:33] <jam> p:~wallyworld/juju-core/container-provisioner-retrywatcher
[08:33] <jam> k,
[08:33] <jam> Bot is running it again
[08:33] <jam> you had a test suite timeout
[08:33] <wallyworld_> great
[08:34] <wallyworld_> as soon as it lands, i'll backport, probably after dinner
[08:34] <jam> the other failures were probably just my changes, so I'll keep an eye on it.
[08:34] <wallyworld_> which is imminent
[08:41] <voidspace> morning all
[08:43] <rogpeppe> voidspace: mornin'
[08:43] <rogpeppe> voidspace: hangout?
[08:43] <axw> morning voidspace
[08:44] <axw> rogpeppe: https://codereview.appspot.com/83500043 when you're free
[08:44] <rogpeppe> axw: looking
[08:51] <voidspace> rogpeppe: sure, in a minute or two
[08:51] <rogpeppe> axw: reviewed
[08:51] <voidspace> rogpeppe: coffee first :-)
[08:51] <axw> thanks
[08:52] <axw> rogpeppe: so, using State and it working is just lucky (racy)?
[08:52] <axw> I never quite State vs. BackingState
[08:52] <axw> I never quite understood
[08:53] <rogpeppe> axw: how long did the tests take to run?
[08:53] <axw> I never quite English
[08:53] <rogpeppe> axw: it's really a failure of vision
[08:53] <rogpeppe> axw: because you talk to a specific State to sync it, but in this case we've got several
[08:53] <rogpeppe> axw: so you need to prod the right one into action
[08:54] <rogpeppe> axw: for a while now, i've wanted to change the syncing scheme so it's global
[08:54] <axw> rogpeppe: didn't take particularly long to run. it makes sense to change it, anyway
[08:57] <jam> wallyworld_: your patch has landed.
[08:57] <wallyworld_> jam: the one in 1.18? i submitted that just before dinner
[08:57] <wallyworld_> almost finished eating :-)
[08:58] <wallyworld_> i hadn't checked back
[08:58] <jam> wallyworld_: no, the one in trunk, I guess you were faster than I :)
[08:58] <wallyworld_> yeah, i am keen to get 1.18 fixed
[08:58] <wallyworld_> so i can relax
[08:58] <jam> wallyworld_: bot is currently processing axw's gocrypto change, probably will do yours next
[08:59]  * wallyworld_ taps fingers impatiently
[09:00] <voidspace> rogpeppe: I'm in the hangout
[09:01] <frankban> morning all, is the joyent provider working in trunk? I am trying it and bootstrapping hangs on "Bootstrapping Juju machine agent"
[09:01] <rogpeppe> voidspace: i suspect my net connection may be working even less than yesterday...
[09:01] <voidspace> rogpeppe: that's impressive :-)
[09:02] <rogpeppe> voidspace: and there's a BT van outside, so it's quite possible it'll go away completely soon
[09:06] <rogpeppe> fwereade: what's the deal with utils.IsNotExist ?
[09:06] <axw> frankban: there's a bug on trunk that affects all providers, I'm fixing it right now
[09:07] <fwereade> rogpeppe, exactly what it looks like: if foo is a file, statting foo/bar does not give an error that satisfies IsNotExist :/
[09:07] <fwereade> os.IsNotExist, that is
[09:09] <frankban> axw: cool, FYI 1) ec2 works well and 2) bootstrapping joyent panics if key-file is not specified in the environments.yaml file
[09:10] <frankban> panic: interface conversion: interface is nil, not string on /provider/joyent/config.go:121
[09:10] <axw> frankban: ec2 worked? ok. I think there's a race condition. key-file is something specific to joyent... over to wallyworld_ :)
[09:11] <frankban> axw: yes, I was able to bootstrap that correctly earlier (saucy, revno 2535)
[09:11] <frankban> axw: ec2 I mean
[09:12] <rogpeppe> i'm just losing internet connection while an engineer works on the line
[09:12] <rogpeppe> back soon i hope
[09:12] <axw> frankban: if you want to get unstuck quickly, then try merging lp:~axwalk/juju-core/lp1300889-disable-mongo-keyfile
[09:12] <axw> (still uploading...)
[09:16] <jam> wallyworld_: bot is running your 1.18 branch now
[09:16] <jam> started 14 min ago
[09:17] <jam> fwereade: because ENOTDIR != ENOEXIST ?
[09:20] <jam> wallyworld_: bots done
[09:21] <frankban> axw: trying joyent with your branch
[09:21] <jam> wallyworld_: looks like it was happy with your patch
[09:22] <jam>  2253 Ian Booth	2014-04-02 [merge]
[09:22] <jam>       [r=wallyworld],[bug=1299588] Backport r2536 to fix container provisioner retry issue.
[09:24] <jam> rogpeppe: I did end up going with "godeps before the bot runs", thanks for the suggestion.
[09:24] <jam> I trust godeps enough now, I'm still not sure about a go get -u in there, though.
[09:24] <rogpeppe> jam: i thought i'd already changed it to do that actually
[09:25] <jam> rogpeppe: if you did, it didn't end up in the config I saw
[09:25] <jam> rogpeppe: maybe you did but didn't push the config back into swift ?
[09:26] <rogpeppe> jam: ah, yes, you're right, i didn't
[09:26] <rogpeppe> jam: so i guess you (or someone) overwrote the config i'd done
[09:26] <rogpeppe> jam: oh well
[09:27] <jam> rogpeppe: I did, as I needed to update it, so I updated my local copy from swift
[09:28] <rogpeppe> jam: i've got a program that enables you to do a juju set with the same data that juju get returns
[09:28] <jam> frankban: joyent panic is bug #1300846, right?
[09:28] <_mup_> Bug #1300846: Juju crashes bootstrapping joyent <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300846>
[09:29] <frankban> jam: yeah it seems to be that bug
[09:30] <rogpeppe> voidspace: MgoInstance.Port returns the same port that is inside MgoInstance.Addr
[09:30] <voidspace> rogpeppe: right
[09:30] <rogpeppe> voidspace: so no need to parse
[09:30] <voidspace> rogpeppe: cool, that's nicer
[09:32] <voidspace> rogpeppe: so one of your suggestions (agent/agent.go:528)
[09:33] <voidspace> rogpeppe: you suggest gating on SharedSecret == "" instead of StatePort == 0
[09:33] <rogpeppe> voidspace: i can hear you pretty well BTW
[09:33] <voidspace> rogpeppe: how is that any better or different
[09:33] <frankban> axw: after merging your branch, bootstrapping joyent succeeded, thank you!
[09:34] <axw> frankban: cool, no worries
[09:35] <voidspace> rogpeppe: if you're talking I can't hear you :-)
[09:35] <rogpeppe> voidspace: ok, i'll give up on the hangout :-)
[09:35] <voidspace> rogpeppe: if StatePort == 0 but SharedSecret != "" we're just as screwed as StatePort != 0 but SharedSecret == ""
[09:35] <rogpeppe> voidspace: so, i see SharedSecret as slightly more fundamental, but you're probably right that it doesn't matter much
[09:35] <voidspace> rogpeppe: so they seem directly equivalent checks
[09:35] <rogpeppe> voidspace: the other possibility i thought of was to store a *StateServingInfo instead
[09:35] <voidspace> rogpeppe: I'm happy to make the change
[09:36] <voidspace> rogpeppe: that would be less arbitrary
[09:36] <rogpeppe> voidspace: then the test could be "if not nil"
[09:36] <voidspace> rogpeppe: yep
[09:36] <rogpeppe> voidspace: yeah, otherwise they're both pretty arbitrary
[09:36] <voidspace> but think of the performance hit we take from the extra level of indirection!
[09:37] <voidspace> rogpeppe: ok, I'll look at making that change
[09:39] <wallyworld_> frankban: axw: key-file is supposed to be optional and default to ~/.ssh/id_rsa. if it doesn't do that, then that's a bug :-(
[09:39] <rogpeppe> voidspace: ha ha
[09:39] <frankban> wallyworld_: yeah, it seems to be  bug #1300846
[09:39] <_mup_> Bug #1300846: Juju crashes bootstrapping joyent <bootstrap> <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1300846>
[09:39] <jam> wallyworld_: sounds like we have a bug :)
[09:40] <wallyworld_> we can still release 1.18 with that unresolved but documented in the release notes
[09:40] <wallyworld_> just ensure key-file is set
[09:40] <wallyworld_> it will be fixed for 1.20
[09:41] <frankban> wallyworld_: so, the mandatory fields are sdc-user, sdc-key-id, manta-user and manta-key-id, correct?
[09:41] <wallyworld_> from memory yes
[09:41] <wallyworld_> in oractice key-file will also be set
[09:41] <wallyworld_> practice
[09:41] <frankban> wallyworld_: yeah
[09:41] <wallyworld_> because you don't necessarily want to use your default private key with joyent
[09:42] <wallyworld_> you want to generate one for the purpose
[09:42] <wallyworld_> hence the bug got missed also in CI
[09:42] <voidspace> rogpeppe: made all those changes except switching to *params.StateServingInfo
[09:42] <frankban> wallyworld_: agreed
[09:42] <voidspace> rogpeppe: pushed and running tests
[09:42] <rogpeppe> voidspace: cool
[09:42] <wallyworld_> frankban: so yeah, not a show stopper :-)
[09:42] <wallyworld_> but will be fixed
[09:43] <frankban> wallyworld_: ack, thank you
[09:43] <wallyworld_> np, sorry about the bug
[09:43] <wallyworld_> i was a bit rushed to make the 1.18 release
[09:43] <jam> wallyworld_: the bug seems pretty trivial to fix, even for 1.17.8
[09:43] <jam> just the line that looks at private-key and then at key-file needs to be aware that key-file may be empty
[09:44] <wallyworld_> jam: yes, but if we wnt to ship real soon now i may not get it done as it's way pat my EOD
[09:44] <wallyworld_> past
[09:44] <jam> wallyworld_: k, I'll poke at it.
[09:44] <wallyworld_> jam: i'd normally look at it but am way tired tonight
[09:45] <wallyworld_> if you get stuck let me know and i'll do it after the standup
[09:45] <jam> np
[09:45] <jam> wallyworld_: so *should* it default to ~/.ssh/id_rsa ?
[09:45] <jam> because internally it defaults to ""
[09:46] <jam> ah I see
[09:46] <jam> they have a bunch of logic to pull it from the ENV or use a different default
[09:46] <jam> they just reference it before they've done those steps
[09:46] <wallyworld_> yeah
[09:46] <wallyworld_> it got messy
[09:46] <wallyworld_> it needs to be "" so the env can override if necessary
[09:46] <wallyworld_> or something like that
[09:47] <jam> wallyworld_: right, they just fix it up in validateConfig, but apparently we call prepareConfig without validating first.
[09:48] <wallyworld_> jam: i did a fair bit of refactoring in that area to bring stuff into line with other providers, so i likely was complicit in the bug
[09:48] <wallyworld_> maybe a call to validate is all that is required, not sure
[09:48] <wallyworld_> bbiab, got to put the kid to bed
[09:48] <rogpeppe> voidspace: here's the followup to your branch: https://codereview.appspot.com/83530043
[09:51] <axw> rogpeppe: is "HA: make APIAddresses use state.APIAddresses, not state.APIAddressesFromMachines" still relevant?
[09:52] <rogpeppe> axw: yes
[09:52] <rogpeppe> axw: it should be a totally trivial change
[09:52] <axw> what uses APIAddresses rather than APIHostPorts?
[09:52] <rogpeppe> axw: nothing should be using APIAddressesFromMachines any more
[09:52] <rogpeppe> axw: ah, i may well be talking about APIHostPorts here :-)
[09:54] <axw> ah, so uniter and deployer use it for initial addresses... yeah ok.
[09:54] <axw> I can take a look at that next if nobody else does
[09:57] <axw-afk> can someone please take a look at https://codereview.appspot.com/83270045/, which fixes https://bugs.launchpad.net/juju-core/+bug/1300889
[09:57] <_mup_> Bug #1300889: azure and hp cannot deploy as of r2524 <azure-provider> <hp-cloud> <regression> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1300889>
[09:58] <rogpeppe> axw-afk: i'm on it
[09:59] <voidspace> rogpeppe: yep, looks good
[09:59] <rogpeppe> voidspace: have you proposed yours yet?
[09:59] <voidspace> rogpeppe: about to
[10:00] <rogpeppe> BT engineer found the problem with my phone line
[10:01] <rogpeppe> a intermittent break in a copper line at the top of the telegraph pole opposite the house
[10:01] <voidspace> good he found it
[10:01] <rogpeppe> voidspace: yeah
[10:02] <rogpeppe> voidspace: now i'll just need to phone talktalk and get them to reset the SNR on the line, and hopefully should be back to normal
[10:02] <voidspace> rogpeppe: just switching to using *params.StateServingInfo
[10:02] <voidspace> it's not much work
[10:02] <voidspace> just a couple of changes
[10:02] <rogpeppe> voidspace: cool
[10:13] <dimitern> fwereade, mgz, https://codereview.appspot.com/83070047/ quick review adding machine NICs?
[10:15] <rogpeppe2> yay, internet now fixed
[10:19] <jam> rogpeppe2: now we just have to figure out who your doppleganger is :)
[10:19] <fwereade> dimitern, couple of tweaks -- just add a separate collection/doc for configured networks and different types for internal/external usage
[10:19] <fwereade> dimitern, hum, another thought
[10:20] <dimitern> fwereade, i forgot to add NetworkName to the struct
[10:20] <fwereade> dimitern, mgz: how does this stuff interact with mgz's Network type?
[10:20] <fwereade> dimitern, mgz: I am worried that there should be some link between the two
[10:20] <voidspace> rogpeppe2: I think this change makes one code path untestable
[10:20] <voidspace> rogpeppe2: or very hard to test
[10:21] <dimitern> fwereade, what's that type?
[10:21] <dimitern> mgz, around?
[10:22] <fwereade> dimitern, mgz: sorry, I think I mean instance.Address -- I just feel like there probably ought to be some connection that isn't just coincidental, but maybe it's not the time quite yet
[10:22] <dimitern> fwereade, I think it's not the time yet
[10:23] <fwereade> dimitern, mgz: in particular the scope stuff feels like it ought to be reflected somehow
[10:23] <fwereade> dimitern, mgz: but I'll accept that suggestion if mgz concurs ;)
[10:24] <dimitern> fwereade, and what do you mean by "different types for internal/external usage" ?
[10:24] <perrito666> good morning
[10:25] <fwereade> dimitern, if we use the same struct in the DB and in the exported methods, then it's hard to track the scope of changes to that type
[10:25] <dimitern> fwereade, ok, I'll add a separate networkInterfaces collection linked to a machine
[10:26] <fwereade> dimitern, if there's a translation layer we have a place to deal with schema changes as they happen, if there isn't it's way too easy to make schema changes without knowing
[10:26] <fwereade> dimitern, eg changing charm.Meta should not magically change our schema, but it does :/
[10:27] <dimitern> fwereade, I see, good point!
[10:39] <voidspace> rogpeppe2: so making configInternal.servingInfo into a *params.StateServingInfo
[10:39] <voidspace> rogpeppe2: leaves one code path untestable
[10:39] <voidspace> rogpeppe2: but only because it's not possible for that code path to be triggered
[10:39] <voidspace> rogpeppe2: so I'm removing the test
[10:40] <voidspace> rogpeppe2: and I'm also going to ignore the "ok" return value from config.StateServingInfo()
[10:40] <voidspace> rogpeppe2: because it's not possible for it to return false in InitializeState
[10:41] <rogpeppe2> voidspace: ah, i have internet again!
[10:41] <voidspace> rogpeppe2: cool
[10:47] <voidspace> rogpeppe2: proposal updated
[10:47] <voidspace> https://codereview.appspot.com/82960044/
[10:48] <rogpeppe2> voidspace: lookin
[10:48] <rogpeppe2> g
[10:49] <wwitzel3> updated proposal https://codereview.appspot.com/83150043/ .. if someone can take a look
[10:49]  * perrito666 curses hi decaf coffee and its lack of ... well caf :p
[10:50] <wwitzel3> rogpeppe2, perrito666 ^
[10:50] <perrito666> wwitzel3: looking
[10:50] <rogpeppe2> wwitzel3: will do
[10:50] <fwereade> jam, standup?
[11:24] <wallyworld_> fwereade: mgz: as far as i can see, there is no remote API on machine to get Addresses() so that would need to be added before we ship 1.18
[11:24] <fwereade> wallyworld_, yeah, I think we'd need that, dammit
[11:25] <wallyworld_> so a blocker for 1.18, needs to be done post haste
[11:37] <rogpeppe2> axw-afk: this branch fixes your test failure: lp:~rogpeppe/juju-core/axwalk-lp1300889-disable-mongo-keyfile
[11:38] <axw-afk> rogpeppe2: thanks, I was about to look into it.
[11:39] <axw-afk> rogpeppe2: will you be sending an MP?
[11:39] <rogpeppe2> axw-afk: i suggest just pulling it into your branch and reproposing
[11:40] <jam1> axw-afk: if you have time now, do so, otherwise rogpeppe2 I would just suggest you push it up, mark it for merging and approve it.
[11:40] <jam1> At least, if the changes are obvious
[11:40] <axw-afk> rogpeppe jam1: right, will do. just about to have dinner, will do that later
[11:41] <jam1> sure, just setting a general policy that if it is after-hours for someone, and you can fix their patch, its fine, unless you think it is controversial, go ahead and propose and land the fixed versio.n
[11:41] <rogpeppe> axw-afk: i could easily propose it as a separate branch - it's independent of yours
[11:41] <rogpeppe> axw-afk: TestAddressChange was quite broken before
[11:42] <rogpeppe> axw-afk: (i should've picked it up)
[11:52] <wallyworld_> jam: i +1'ed your key-file branch
[12:01] <jam1> wallyworld_: thx, want to do a quick followup on :https://code.launchpad.net/~jameinel/juju-core/1.18-private-key-path-1301315/+merge/213818
[12:02] <wallyworld_> sure
[12:02] <axw-afk> rogpeppe: finished dinner, I'll merge it in now.
[12:02] <rogpeppe> axw-afk: you don't need to - i'm just proposing it as a separate fix
[12:03] <axw-afk> ok
[12:05] <wallyworld_> jam: done, perhaps with a comment fix
[12:05] <perrito666> brb
[12:07] <rogpeppe> axw-afk: https://codereview.appspot.com/83590043
[12:07] <natefinch> fwereade: aren't we working on getting rid of using git with charms?  re: the fat charm thread in email?
[12:09] <axw-afk> rogpeppe: thanks for that. reviewed
[12:09] <rogpeppe> axw-afk: ta
[12:10] <jam1> natefinch: it won't be in 1.18 for sure, it may not be in trusty
[12:10] <jam1> there is some code out there that fwereade might get done.
[12:10] <natefinch> jam1: ok, I remember he'd mentioned working on it, but didn't know the status.
[12:12] <wwitzel3> natefinch: https://codereview.appspot.com/83150043/ when you can
[12:12] <jam1> wallyworld_: you mentioned changing the MANTA_KEY_FILE env var.
[12:12] <jam1> should we?
[12:12] <jam1> or is that coming from Joyent as the recommended way of setting it?
[12:13] <wallyworld_> jam: nah, that was us. i think it needs to be consistent
[12:13] <jam1> (like we just use the standard OS_ENV* for openstack/ec2, we didn't come up with our own.)
[12:13] <jam1> wallyworld_: k, if we created it, I'm happy to set it to something else.
[12:13] <wallyworld_> i created it :-) to match the attr name
[12:15] <jam1> wallyworld_: MANTA_PRIVATE_KEY_PATH or MANTA_PRIVATE_KEY ?
[12:15] <wallyworld_> path i think to match the attr?
[12:16] <rogpeppe> axw-afk: are you doing "HA: make APIAddresses use state.APIAddresses, not state.APIAddressesFromMachines" ?
[12:16] <jam1> wallyworld_: yeah, I'm not really sure what a standard env var would be, so I'll go with just matching the var name.
[12:16] <jam1> wallyworld_: PATH in env vars tends to be a list of paths to search
[12:16] <jam1> but , meh
[12:16] <wallyworld_> i'm hopeless at naming things
[12:17] <wallyworld_> hmm, maybe just MANTA_PRIVATE_KEY_FILE
[12:17] <wallyworld_> i sorta with the ca stuff used -file as well
[12:17] <wallyworld_> wish
[12:20] <mgz> dimitern: I need to pick something up on the vlan work, what do you want me to do?
[12:23] <dimitern> mgz, well, the thing is most of what's left depend on changes around StartInstance
[12:23] <dimitern> mgz, except maybe the add-machine card
[12:23] <dimitern> mgz, that's can be done in parallel with the other related CLI card
[12:23] <axw-afk> rogpeppe: not tonight, but I will tomorrow if it's still up for grabs
[12:23] <mgz> I can take that one
[12:25] <rogpeppe> mgz: if you have a moment to do it, that would be great
[12:26] <mgz> rogpeppe: I'll have a quick look
[12:26] <rogpeppe> mgz: it *should* be fairly trivial, but it may affect tests
[12:28] <mgz> rogpeppe: whihc APIAddresses?
[12:29] <rogpeppe> mgz: common.APIAddresses.APIAddresses
[12:29] <rogpeppe> mgz: in state/apiserver/common
[12:29] <mgz> k
[12:36] <jam1> wallyworld_: proposal updated, care to have another pass ?
[12:36] <wallyworld_> sure
[12:36] <jam1> wallyworld_: https://codereview.appspot.com/83530044/
[12:38] <wallyworld_> jam: land it i reckon
[12:39] <jam1> wallyworld_: done, thanks
[12:39] <jam1> sinzui: if you have a CI test for Joyent, you'll need to update your config. the config entry "key-file" is now named "private-key-path".
[12:39] <jam1> (at least, once this branch lands in the bot)
[12:40] <sinzui> thank you. I will
[12:40] <jam1> That will be in the 1.17.8 release, and I'll merge it into 1.19
[12:41] <sinzui> jam, is private-key still valid
[12:42] <jam1> sinzui: yes
[12:42] <jam1> the rename was just to make it more consistent with other "youcan specify the file or the content"
[13:00] <mgz> rogpeppe: something like http://paste.ubuntu.com/7194149/
[13:00] <mgz> running tests now
[13:01] <bodie_> greetings
[13:01] <mgz> hey bodie_
[13:02] <mgz> tyop...
[13:04] <mgz> rogpeppe: actualy compiles http://paste.ubuntu.com/7194162/
[13:04] <rogpeppe> mgz: that's the general idea
[13:05] <rogpeppe> mgz: it's not quite right though
[13:05] <rogpeppe> mgz: i think it should be addrs := make([]string, 0, len(apiHostPorts))
[13:05] <mgz> do we want multiple addresses per state server if they exist?
[13:05] <rogpeppe> mgz: good question.
[13:06] <rogpeppe> mgz: well, we don't need them currently, and we want to deprecate APIAddresses
[13:06] <rogpeppe> mgz: so i'd say just stick with the existing semantics from APIAddressesFromMachines
[13:08] <mgz> good call on make, legacy of first version where I forgot "" was a valid return value but not something we wanted to pass down
[13:08] <jam1> can I get a review of the trivial patch: https://code.launchpad.net/~jameinel/juju-core/1.18-always-ensure-curl-1300321
[13:09] <mgz> jam: looking
[13:09] <mgz> noooooo
[13:09] <mgz> not again
[13:09] <jam1> mgz: ?
[13:10] <mgz> I wish we could just freakin' apt
[13:11] <mgz> jam1: dimitern had that line, I told him to remove it as it's in the base image, and hey, without apt sanity that turns out to have been bad advice
[13:11] <jam1> mgz: well, we're apt installing all of them
[13:11] <jam1> mgz: :)
[13:13] <jam1> mgz: note that "juju-local" doesn't depend on curl, because we didn't realize we needed it (being installed in base)
[13:13] <jam1> mgz: as such, we *still* would have been broken for manual
[13:13] <mgz> right, but we can fix that dep in the juju-local package :)
[13:14] <jam1> mgz: and we can fix this dep in the place where it is given :)
[13:14] <mgz> jam1: lgtm'd
[13:14] <jam1> thx
[13:16] <jam1> I guess I need to go get a drobox account now: http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services/
[13:33] <mgz> why am I getting test functions not defined...
[13:33] <mgz> http://paste.ubuntu.com/7194249/
[13:33] <ahasenack> is there a scenario where config-get would fail with "settings not found"?
[13:33] <ahasenack> http://pastebin.ubuntu.com/7194251/
[13:33] <ahasenack> that is inside config-changed (!)
[14:11] <natefinch> jam1, mgz: what do we use curl for?
[14:11] <jam1> natefinch: downloading the juju .tgz
[14:13] <natefinch> jam1: ahh, yeah
[14:20] <mgz> anyone got any idea on my test build error with trunk above? ^
[14:21] <natefinch> mgz: this, I think: https://github.com/juju/testing/blob/master/patch.go
[14:22] <natefinch> I think we've moved to only using github for that package?
[14:22] <mgz> ...why does godeps not complain...
[14:22] <natefinch> I think the problem is that godeps only knows what dependencies you tell it about
[14:22] <natefinch> you're using a dependency it doesn't know about
[14:23] <natefinch> (launchpad.com/juju-core/testing)
[14:23] <mgz> but it's trunk, I've not touched anything about this...
[14:23] <natefinch> oh weird
[14:24] <natefinch> ok, so trunk is still using the one from launchpad
[14:28] <natefinch> mgz: is that on your local machine?  Try blowing away $GOPATH/pkg ... sometimes old stuff gets stuck in there
[14:28] <mgz> sounds like a good plan
[14:28] <mgz> r2448 seems like a lie
[15:22] <wwitzel3> rogpeppe: https://codereview.appspot.com/83150043/
[15:23] <natefinch> wwitzel3: sorry I missed that review earlier
[15:23] <rogpeppe> fwereade, dimitern, wwitzel3, natefinch, mgz: here's the singular worker implementation. reviews much appreciated:  https://codereview.appspot.com/83300047
[15:25] <natefinch> rogpeppe:  looking
[15:27] <wwitzel3> natefinch: np
[15:32] <rogpeppe> voidspace: lp:~rogpeppe/juju-core/536-machineconfig-stateservinginfo
[15:35] <wwitzel3> https://codereview.appspot.com/83130045/ reviews welcomed from anyone with a moment, pretty straightfoward.
[15:40] <rogpeppe> natefinch: how's tricks?
[15:46] <voidspace> rogpeppe: https://pastebin.canonical.com/107661/
[15:58] <natefinch> rogpeppe: sorry, had to do an early lunch, because I'm doing an interview in 3 minutes.  So.... yeah.  I updated the namespace proposal to include the changes to check the contents of the upstart config instead of using a version.
[15:58] <natefinch> rogpeppe: https://codereview.appspot.com/81980043/
[15:58] <natefinch> rogpeppe:  I didn't get a chance to totally review the singeular stuff... I'll finish up after the interview
[15:59] <rogpeppe> natefinch: ta
[16:13] <sinzui> jam, fwereade, juju-gui see this bug as a blocker for 1.18.0 1301464
[16:13] <sinzui> bug 1301464
[16:13] <_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Triaged> <https://launchpad.net/bugs/1301464>
[16:14] <sinzui> I will also invite thumper to comment on it when he comes online
[16:14] <perrito666> I am supposed to implement a failure if a requested service machine does not have the networks requested in the networks/not-networks params, but I cannot know that until the machine is up, what should I do with the machine in case it fails?
[16:15] <perrito666> (I feel I might be missing something)
[16:53] <mgz> perrito666: so, add-unit and deploy are both in the context of a service, where we have networks/exclude-networks as context
[16:54] <mgz> and with --to we are specifying a machine
[16:54] <mgz> which, now in the case of maas, we can look up the networks it actually has
[16:54] <perrito666> ahh, indeed
[16:54] <mgz> beccause that machine must already exist for --to to make sense
[16:55] <mgz> I agree it's a bit confusing without add-machine having the networks/exclude-networks params yet, so there's no clear two-step process
[17:00] <bodie_> I don't understand why state/api/client_test.go is so different from client.go
[17:01] <bodie_> is it just not fully implemented?
[17:02] <bodie_> oh, this bug is mentioned
[17:02] <bodie_> https://bugs.launchpad.net/juju-core/+bug/1217282
[17:02] <_mup_> Bug #1217282: api.Client tests should be in api not state/apiserver/client/ <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1217282>
[17:04] <mgz> bodie_: yeah, it's mostly just an arrangement thing
[17:07] <fwereade> sinzui, do you overlap with wallyworld_?
[17:07] <fwereade> sinzui, we talked about that a little bit this morning with him, I think he's poised to do more tonight
[17:08] <sinzui> fwereade, I do. I will show him the bug
[17:08] <fwereade> sinzui, brilliant, tyvm
[17:08] <jam> sinzui: so for bug #1301464... I'm pretty sure we've never had it working the way they described, so it doesn't seem like a regression.
[17:08] <_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1301464>
[17:09] <jam> I can see why it could be important, but it is a little bit late, unless someone other than myself has an obvious way of fixing it.
[17:09] <fwereade> jam, isn't the problem that we *used* to have unit addresses... but now that we don't, the lack of machine addresses is a stark and serious problem
[17:10] <rick_h_> jam: fwereade this is the bug frankban is going to work on. We need it for quickstart. This has broken quickstart
[17:10] <jam> rick_h_: so i'd like to understand what the regression is
[17:10] <jam> what *was* working that now isn't
[17:11] <frankban> fwereade, jam: that's my understanding. either we reinstate unit addresses (for local envs, ec2 seems to have them) or we include containers addresses in the MachineInfo AFAICT
[17:11] <rick_h_> frankban: it was the lxc ip address fetching right?
[17:12] <frankban> we used to have PublicAddress on the UnitInfo: with the 1.18 branch it seems an empty string is returned by the mega-watcher if the local provider is used
[17:13] <frankban> rick_h_, jam, fwereade: from our perspective, reintroducing them on unit info is ok for now. IIUC the path is to remove the addresses from the UnitInfo though. So the problem might be solved including containers addresses in the MachineInfo.
[17:15] <frankban> rick_h_, jam, fwereade: I am not sure about that, but I guess the problem there is that MachineInfo.Addresses only include addresses obtained from the provider. I'd expect containers ones to be included if we also merge in the slice the machine addresses (in a way similar to what's done in *state.Machine.Addresses()).
[17:16] <fwereade> frankban, am I right in thinking you were already in communication with wallyworld_ about this general issue?
[17:16] <frankban> fwereade: yes
[17:16] <fwereade> frankban, I'm hoping it's easier, because we can now get lxc containers' addresses from the provider, iirc
[17:17] <fwereade> frankban, lxc-ls --fancy
[17:17] <fwereade> or whatever it is
[17:17] <rick_h_> fwereade: yes, wallyworld sent an email on the matter last night and he and frankban have been in communication on requirements
[17:18]  * rick_h_ checks what list that thread was in
[17:18] <fwereade> frankban, just to be clear: if all machines reported all their addresses in the AllWatcher (including scope, ie public/private), that would be sufficient?
[17:19] <frankban> rick_h_: is in the private emails
[17:21] <frankban> fwereade: I think so, at that point we need to fix quickstart and the GUI to use the new source of information if available. The important thing is that info to be available to API clients in some way. MachineInfo already has an Addresses field as a slice of instance.Address, so merging all the addresses there should be sufficient
[17:23] <fwereade> frankban, ok, that is *hopefully* a relatively trivial bug then
[17:26] <fwereade> frankban, ...or maybe not so much, gaah
[17:27] <frankban> fwereade: I am checking my assumption wit this change: http://pastebin.ubuntu.com/7195189/ (that's not a fix, just a check for the contents of MachineAddresses)
[17:28] <fwereade> frankban, yeah, the issue appears to be that local instances still don't report addresses
[17:31] <bodie_> can anyone help me understand what's going on in state/apiserver/client/ ?
[17:31] <frankban> fwereade: with that change the watcher reports the ipv4 address for machine 1 (lxc): http://pastebin.ubuntu.com/7195204/
[17:31] <bodie_> I think I get that the api client is using 'call' to trigger methods from those files on the apiserver, but I'm not following how that relates to state/api/client
[17:32] <voidspace> g'night all
[17:32] <voidspace> EOD
[17:33] <fwereade> bodie_, state/api/client is the minimal implementation necessary to get the CLI to work
[17:33] <frankban> fwereade: the real fix could be something like: 1) have a function receiving a machine doc and returning the merged addresses, 2) make Machine.Addresses use that function (passing m.doc) and 3) update the megaewatcher to use that function (passing the backingMachine)
[17:33] <fwereade> frankban, ha, yes, ofc, that sounds like exactlythe right thing to do
[17:34] <fwereade> frankban, I'd forgotten we stored machine-reported addresses separately from provider-reported addresses
[17:34] <fwereade> frankban, the plan was basically to grab all the info we can and do our best to merge the two into something sane
[17:35] <fwereade> bodie_, sorry, actually, I'm not 100% sure I understand your question, would you restate please?
[17:35] <bodie_> thinking about how to do so
[17:35] <fwereade> frankban, clearly that last step got missed somehow :/
[17:35] <frankban> fwereade: yeah, the only change seems to be: dong that at the document level and not at the state.Machine level.
[17:36] <fwereade> frankban, I'm not keen on discarding any of that info, I think it's a matter of a func for the megawatcher rather than something at machineDoc level
[17:36] <wwitzel3> natefinch: you free?
[17:37] <bodie_> I see a bunch of methods in /state/api/client.go which are used by Commands in /cmd/juju/ via their 'call' method to signal the API server to do things
[17:37] <frankban> fwereade: I was just thinking about having a function that can be used both by Machine.Addresses and by the megawatcher, the former at that point being just a wrapper
[17:37] <fwereade> bodie_, yeah; they map to methods on the Client type in apiserver
[17:37] <fwereade> frankban, ah, gotcha: yes, that sounds ideal
[17:38] <bodie_> OK
[17:39] <jam> fwereade: frankban: you realize the reason we store them separately is because otherwise you'd only end up with private addresses (what you can read from eth0 != public address).
[17:39] <bodie_> so the files in /state/apiserver/client/* are where those Client functions are defined
[17:39] <bodie_> I think I'm confused between the apiclient "Client" and the apiserver "Client"
[17:39] <jam> bodie_: so state/apiserver/* is the server-side of an RPC, and state/api/* is a wrapper around those RPCs to make them look like just function calls.
[17:40] <fwereade> jam, yes, we definitely need to store those differently-sourced addresses separately
[17:40] <jam> bodie_: so cmd/juju/add.go makes a "myconnection.GiveMeSomething()" which under the covers does a RPC Call() to 'MyObject.GiveMeSomething'
[17:41] <jam> bodie_: it is called "Client" because it is the API for GUI/CLI Clients, not because it is the actual client portion of a client-server relationship.
[17:41] <bodie_> OK.  so if, for example, I want to understand how Set works, I would start in /cmd/juju/set.go -- which calls /state/api/client.go 's "ServiceSet" function, which calls NewServiceSetForClientAPI via RPC on the apiserver
[17:42] <frankban> jam: yeah, I know that. My proposal would only merge them when they are sent by the mega-watcher. API client can then just ignore the address they are not interested in by looking at the NetworkScope
[17:42] <bodie_> jam, I see.  I think that helps clarify things for me in terms of what "Client" means
[17:42] <jam> bodie_: (may not be the greatest example because we had to do bad things with the RPC names there, but yes)
[17:42] <bodie_> heh
[17:42] <jam> frankban: right, that seems fine. I don't think we need to expose it externally as separate.
[17:43] <jam> we just need to not overwrite them
[17:43] <bodie_> jam: since the remote function is being called by name, do I just need to find the function of that name in apiserver/client/* ?
[17:43] <bodie_> er, by string
[17:44] <jam> bodie_: in general the state/api/client is going to map 1:1 with state/apiserver/client. It happens that we couldn't do that for SetService, but the string in the Call() is always the exact name on the apiserver.
[17:45]  * fwereade needs to spend a bit of time with his family, will bbl
[17:49] <bodie_> gotcha, which in the case of "Set" (or rather NewServiceSetForClientAPI) is defined in apiserver/client/client.go
[17:49] <bodie_> but in other cases, might be defined in one of those other files in client
[17:49] <bodie_> thanks
[17:51] <natefinch> wwitzel3: just got off the interview, will write it up and then be free
[17:52] <wwitzel3> natefinch: sounds good
[17:55] <frankban> fwereade, jam: something like this? http://pastebin.ubuntu.com/7195287/
[17:59] <jam> frankban: for genericity, would it make sense to just have a mergeAddresses(...[]addresses) ?
[18:00] <jam> otherwise seems ok to me
[18:01]  * rogpeppe is done for the day
[18:01] <rogpeppe> g'night all
[18:02] <natefinch> night rog
[18:05] <wwitzel3> see ya rogpeppe
[18:07] <frankban> jam: sounds good yeah, that's just a quick prototype. it seems to work. the only problem I see is that NetworkScope is empty: http://pastebin.ubuntu.com/7195357/  This is a local env and I expected the scope to be "public"
[18:09] <frankban> jam, fwereade should we assume empty scope == public? Or this is a bug?
[18:28] <natefinch> wwitzel3: want to hang out, or was there something specific you wanted to talk about?
[18:29] <wwitzel3> natefinch: hangout, catchup on HA, etc
[18:29] <natefinch> ok
[18:52] <sinzui> I think we have user backlash over the changes to juju-local and juju-mongodb. Most victims are canonical staff too. They don't have juju-local installed, they didn't get the new deps, they blame juju to for not telling them what the deps are.
[18:53] <sinzui> I suggest juju checks is juju-local is installed when bootstrapping the juju local env. stop and tell the user to install the right packages before reporting bugs or complaining to the release manager
[19:07] <natefinch> heh, that seems like a reasonable position, sinzui
[19:46] <bodie_> I'm trying to understand this ServiceSetYAML method in /state/api/client.go
[19:46] <bodie_> I think it's for the "set" command which sets config options on a remote service or unit
[19:46] <bodie_> but there's also ServiceSet
[19:46] <bodie_> and I noticed ServiceSetYAML is reading its values from the command context
[19:47] <bodie_> but I'm assuming that's just for set --config=file.yaml
[19:47] <natefinch> bodie_: IIRC, the only difference is that one takes YAML and one takes key value pairs
[19:47] <bodie_> I just don't want to leave it out if it's important for setting up flags on the command in a general sense or some such
[19:49] <natefinch> bodie_: it probably gets used by somebody, yes.
[19:50] <bodie_> so not just Set.
[19:50] <bodie_> I think I'll leave it out and see what happens.  ^_^
[19:52] <natefinch> Depends on what you mean by "leaving it out".  If this is for new code (actions), it's probably fine to leave it out. No one likes yaml.
[19:53] <jcw4> natefinch there are no plans to move away from yaml on the backend though right?
[19:53] <natefinch> jcw4: define backend and I can answer the question (possibly)
[19:53] <jcw4> haha
[19:54] <jcw4> natefinch my keyhole view of the world separates the UI as the front end, and everything else (jujud as well as workers) as backend
[19:54] <jcw4> UI [19:55] <jcw4> natefinch, as I understand it the config for each charm is held in a yaml file... that's not going to change any time soon right?
[19:56] <natefinch> jcw4: there's no plans to change that, no.  We were just disappointed in the difference between the ease of hand editing that yaml promotes and how it actually works in practice.
[19:57] <jcw4> natefinch interesting.  That makes sense.  I initially thought that plans were afoot to move to JSON, but then realized that the migration of all the existing Charms would be impractical.
[19:59] <natefinch> Right. We don't mind parsing the yaml in the code, that's trivial.  It's more from a end user perspective, it's not very fun to try to write correct yaml in a text editor.... which is honestly true of pretty much any structured text file.
[20:00] <jcw4> I see.
[20:14] <marcoceppi> why move to json? yaml is wayyyy easyer. It's like moving from python to php
[20:17] <thumper> fwereade: are you around?
[20:18] <natefinch> marcoceppi: we're not
[20:18] <marcoceppi> natefinch: okay, cool
[20:19] <natefinch> marcoceppi: I actually prefer json, personally.  there's a little less magic around the edges, it's a little more uniform, even if it's a little more cumbersome in general. There definitely are benefits to yaml, the main one I like is support for comments.
[20:20] <marcoceppi> natefinch: I love json for a machine format, but to type it out by hand it pisses me off
[20:20] <natefinch> marcoceppi: heh, typing out any structured format pissed me off :)
[20:21] <natefinch> marcoceppi: the one thing I'm thinking about in particular with yaml is getting bitten by the fact that you don't need to put key names in quotes.... unless you run into a keyword, like null, which bit us several times with the null provider.
[20:23] <marcoceppi> natefinch: well, the name null for a provider wasn't the best choice ;)
[20:23] <marcoceppi> immho
[20:23] <natefinch> marcoceppi: well, yes, definitely.  but that's not the point :)
[20:24] <marcoceppi> sure
[20:30] <mwhudson> there is a need for something kinder to humans than json
[20:30] <mwhudson> and yaml is kinder to humans, mostly
[20:30] <mwhudson> but, man, it has it's screwy bits
[20:30] <mwhudson> -'
[20:30] <natefinch> yep
[20:31] <mwhudson> (i do _not_ want my configuration language to support recursive objects!)
[20:31] <natefinch> yaml is a lot easier to read and somewhat easier to write than json
[20:32] <marcoceppi> why not an ini file
[20:32] <jcw4> or a properties file
[20:33] <mwhudson> jcw4: what's a properties file?
[20:33] <jcw4> java
[20:33] <mwhudson> oh right
[20:33] <jcw4> some.long.scoped.variable=value
[20:36] <natefinch> ini is pretty good, actually, though no support for lists of things
[20:38] <rharper> is there a way to set default-series as a constraint instead of configuring multiple environments with different series values ?
[20:45] <fwereade> rharper, would you explain your use case? it can be specified at env level, like constraints, but if you want services to run on a particular series you'll probably want to just explicitly name a charm that uses that series
[20:45] <fwereade> rharper, I'm not sure how multiple environments come in?
[20:46] <mwhudson> natefinch: yeah, it feels like there is a venn diagram with an empty set where i want there to be something :/
[20:49] <natefinch> mwhudson: same here.  I want it to be all powerful, but somehow super easy to read and write.
[20:50] <mwhudson> yaml with some of the crazy filed off would be ok i /think/
[20:52] <natefinch> I might be ok with ini style key value pairs and yaml style lists
[20:52] <natefinch> EOD, kid is bugging me for food.  Swear I fed her yesterday.
[20:53] <rharper> fwereade: I have a jenkins setup which bootstraps environments for openstack installs, the ubuntu releases is one of the parameters;   if I need to change which series is used (precise or trusty) then I have to two entries in environments.yaml which differ only in the default-series value (and name)
[20:55] <rharper> if I add additional releases, then I need to update the environment yaml on jenkins; if it were a parameter passed to bootstrap, then I don;'t have keep updating each time we add a new release to the tests;
[20:58] <fwereade> rharper, ah, got you
[20:59] <fwereade> rharper, I don't suppose it'd be easier to ignore default-series and just be explicit about what charms you're running?
[20:59] <fwereade> rharper, (I am not pooh-poohing your use case, just uncomfortably aware that I don;t think I'll be fixing it in the next few weeks)
[21:00] <rharper> fwereade: we have control over the charm names; I'm new to juju stuff, so, if I specified the charm location in such a way that would force the image that is booted on the allocated node to run a specific release?
[21:00] <rharper> fwereade: and it's OK to have say a precise bootstrap node, but then trusty "service" nodes?
[21:01] <fwereade> rharper, cross-series environments should be fine, yeah
[21:01] <fwereade> rharper, charms are series-specific
[21:01] <fwereade> rharper, so you should be fine to just `deploy precise/foo` or `trusty/foo` or whatever
[21:02] <fwereade> rharper, assuming you have charms for the series you care about, which I think you must :)
[21:02] <rharper> hrm, ok
[21:02] <fwereade> thumper, ping
[21:02] <thumper> fwereade: hey
[21:02] <rharper> yeah, charms for both (openstack)
[21:02] <thumper> fwereade: wondering if you read my email
[21:03] <fwereade> thumper, I did, and hoped to look at the code, but didn't
[21:04] <perrito666> hey, suppose I have a ToMachineSpec, how can I get an instance of the machine from that?
[21:04] <fwereade> thumper, my only comment on the mail was that I think we *do* need lines-of-context, but I will not be overly bothered if it only searches back so far
[21:04] <thumper> the problem is that it doesn't make sense when combined with filteres
[21:04] <thumper> if you don't care, then that's fine
[21:04] <thumper> I was going to keep the 'replay' function from pyjuju
[21:05] <thumper> that replayed the entire log
[21:05] <fwereade> thumper, it's mainly a gui use case
[21:05] <thumper> also keeping --lines to mean "output that number and stop"
[21:05] <thumper> yeah, but that is still wrong
[21:05] <thumper> lets say the gui has debug log for 'machine-1'
[21:05] <thumper> and wants previous 2000 lines
[21:05] <fwereade> thumper, I am aware that we can't guarantee N lines of output when filtering
[21:05] <thumper> it is possible that none of the previous 2000 lines are for machine-1
[21:06] <thumper> if you are fine with that, then ok
[21:06] <thumper> we can keep it
[21:06] <thumper> I'm trying to work out why the stream isn't dying when I think it should be
[21:07] <fwereade> thumper, which branch again? I can take a quick look now
[21:08] <thumper>  lp:~thumper/juju-core/debug-log-api
[21:27] <fwereade> thumper, so, I'm not sure why closing the file you're writing to would be expected to stop the stream
[21:27] <thumper> fwereade: oh fuck
[21:27] <thumper> you are right
[21:27] <thumper> hang on
[21:28] <thumper> let me test something
[21:28] <fwereade> thumper, closing the reader gives all sorts of exciting errors
[21:28] <thumper> thanks
[21:29] <thumper> I wondered WTF was going on...
[21:29] <thumper> a hang over from when I was trying to read on the writing file
[21:29] <thumper> that didn't work either
[21:29] <thumper> why is it a "bad file descriptor" when it is a closed file?
[21:30] <thumper> is there a way to check for closed?
[21:31] <fwereade> thumper, hm, not sure
[21:31] <fwereade> thumper, I feellike having the file closed underneath yu is ground for an error though, in general
[21:32] <thumper> I guess...
[21:32] <thumper> from the reader point of view sure
[21:32] <thumper> I guess I was trying to simulate how it would happen
[21:32] <thumper> normally the user will hit ctrl-c
[21:32] <thumper> which will close the websocket
[21:32] <thumper> I think
[21:32] <thumper> which would cause an error on the *next* write
[21:33] <thumper> so it would clean up *eventually*
[21:37] <fwereade> thumper, hmm, ofc, we can't register it for cleanup in the usual way
[21:37] <thumper> yeah...
[21:37] <thumper> i think it'll be ok
[21:37] <thumper> my test is now good
[21:37] <thumper> so I'm happy
[21:38] <thumper> ish
[21:38] <fwereade> cool
[21:39] <fwereade> thumper, and about the lines-of-context -- we're *never* guaranteed to have N lines available for a given target anyway
[21:39] <thumper> fwereade: any pointers on testing the actual websocket bit?
[21:39] <fwereade> thumper, I think it's fine to explicitly say that it means "up to N lines"
[21:39] <thumper> or just more boiler-plate
[21:39] <thumper> and auth?
[21:39] <fwereade> thumper, and iterate on less sucky implementations
[21:39] <thumper> do we have tests somewhere?
[21:39] <thumper> ack re liens
[21:40] <thumper> fwereade: hmm... thought about an interesting implementation detail, but it is kinda crazy
[21:40] <fwereade> thumper, I would hope you'd be able to reuse the tests for the auth stuff used in charm.go in that package, butmaybe context differs annoyingly
[21:40] <thumper> but it can wait until later
[21:40] <thumper> ok...
[21:41] <thumper> I'll muddle along
[21:41] <fwereade> thumper, don;t have much to offer re websockets I'm afraid
[21:41] <fwereade> thumper, but I'm sorta falling asleep, so I might bow out now
[21:42] <thumper> kk
[21:42] <thumper> night
[21:43] <fwereade> thumper, when he's online, please poke ian re lp:1301464 -- there's a big chunk of context about 4-5hours back in this channel that would be easily missed
[21:44] <fwereade> thumper, I think he knows about the bug anyway though
[21:44]  * fwereade away
[21:44] <thumper> ack
[21:52] <perrito666> go question, can I know if a group of elements (in this case in an array) is subset of a larger group (also in an array) without iterating them ? (something like set.issubset in python)
[22:25] <sinzui> wallyworld_, is bug 1301464 also bug 1301331?
[22:25] <_mup_> Bug #1301464: The mega-watcher for machines does not include containers addresses <addressability> <api> <juju-gui> <juju-core:In Progress by wallyworld> <juju-core (Ubuntu):Triaged> <juju-quickstart (Ubuntu):Triaged> <https://launchpad.net/bugs/1301464>
[22:25] <_mup_> Bug #1301331: Remote machine addresses API required <api> <juju-gui> <juju-core:Triaged> <https://launchpad.net/bugs/1301331>
[22:25] <wallyworld_> sinzui: maybe
[22:25] <wallyworld_> the latter may not be required
[22:26] <wallyworld_> i'll know more soon
[22:26] <sinzui> wallyworld_, okay
[22:26] <wallyworld_> sinzui: it all got messed up with the move to machine addresses instead of unit addresses i think
[22:28] <wallyworld_> sinzui: also, one of the bugs i fixed yesterday only got exposed when deploying to a container on say ec2. it would be good to include such a test in CI
[22:29] <davechen1y> this PSA was about to you by the words "killall mongod"
[22:30] <davechen1y> s/about/bought/
[22:30] <sinzui> wallyworld_, Can you describe the situation in more detail in an email after you have sorted out the bug?
[22:43] <davechen1y> waigani: how you doing today ?
[22:43] <davechen1y> waigani: do you need help with your charm fix ?
[22:51] <thumper> davechen1y: waigani has just left my house, he'll probably be online again after lunch
[22:51] <thumper> 'tis thumpen time
[22:51]  * thumper heads to the gym
[22:52] <davechen1y> thumper: right o
[22:52] <davechen1y> you guys buddy breathing the internet ?
[22:52] <thumper> wallyworld_: <fwereade> thumper, when he's online, please poke ian re lp:1301464 -- there's a big chunk of context about 4-5hours back in this channel that would be easily missed
[22:52] <thumper> wallyworld_: <fwereade> thumper, I think he knows about the bug anyway though
[22:52] <thumper> davechen1y: we are in the same city, so it makes sense to get together periodically
[22:52] <thumper> a bit of pairing this moring
[22:52] <wallyworld_> thumper: yep, saw it :-) otp
[22:53] <thumper> sharing knowledge and all that
[22:53] <thumper> wallyworld_: ack
[23:59] <perrito666> sinzui: if you want to chime in https://codereview.appspot.com/83370043/ there is an interesting debate going on there :)