[00:26] <katco> does juju have a wrapper around exec.Command?
[00:30] <perrito666> katco: iirc there is one in utils
[00:30] <perrito666> sadly there is more than one around
[00:30] <katco> perrito666: ty sir
[00:31] <perrito666> it does little to wrap it :)
[00:31] <perrito666> yw
[00:31]  * perrito666 wonders why is he even reading this channel at thos hour
[00:32] <jw4> perrito666: because you love it here - admit it
[00:32] <katco> :)
[00:32] <perrito666> jw4: well have no life :p
[00:32] <jw4> :)
[00:32] <katco> code is life!
[00:32] <katco> (of course there are more important things, but coding is a lot of fun :))
[00:32]  * jw4 whispers "don't tell katco any different"
[00:33] <katco> lol
[00:33] <jw4> :)
[00:33] <katco> well right now my daughter is asleep by 6:30
[00:33] <katco> 18:30
[00:33] <jw4> wow - how old is she?
[00:33] <katco> i'm sure when that changes i'll be a little more scarce
[00:33] <katco> she is 8 months
[00:33] <jw4> awww
[00:34] <jw4> does she sleep through the night though?
[00:34] <katco> most of the time
[00:34] <jw4> nice!
[00:34] <katco> she's a good little baby :)
[00:34] <jw4> yeah; our first slept through the night at 8 weeks, but our son (second born) took much much longer
[00:35] <katco> how many do you have john?
[00:35] <jw4> two
[00:35] <jw4> daughter 13 and son 9
[00:35] <katco> wow, how nice :)
[00:35] <katco> the teenage years haha
[00:35] <jw4> don't envy the daipers and sleepless nights even though some monster occasionally replaces my daugter
[00:36] <katco> well, i'm having fun so far :)
[00:36] <jw4> good
[00:36] <jw4> I get nostalgic until I think about some of the practicalities of infants
[00:37] <katco> hehe
[00:37] <jw4> perrito666: I forget - you don't have kids right?
[00:38] <jw4> he took himself seriously
[00:38] <katco> haha
[00:41] <menn0> katco, jw4: we make baaad sleepers
[00:41] <menn0> katco, jw4: my son is 19 months and he's only /just/ started sleeping through
[00:42] <katco> oh man
[00:42] <katco> menn0: i feel lucky for sure
[00:42] <jw4> menn0: yeah? That's not unusual I think... but it's a long time to have disruptive sleep
[00:43] <jw4> menn0: for the parents I mean
[00:46] <perrito666> jw4: nope, it shows right?
[00:47] <jw4> perrito666: you don't look weary? ;)
[00:47] <perrito666> well if when I have kids they are anything like me the will begin to be good sleepers around 21
[00:48] <perrito666> years that is
[00:48] <jw4> perrito666: lol
[00:52] <thumper> menn0: are you close to merging your env worker branch  ?
[00:53] <perrito666> wallyworld: you are a hard client to please :p
[00:53] <wallyworld> :-(
[00:54] <wallyworld> did what i say make sense though?
[00:54] <perrito666> wallyworld: not really but I havent read the last review just the email
[00:54] <wallyworld> the review is just a note or two
[00:55] <wallyworld> we have existing code to set machine/unit status
[00:55] <wallyworld> so we need to use that instead of duplicating new code
[00:55] <perrito666> lets go priv so logs dont suck later
[00:55] <wallyworld> we add the agent status setter and the apiserver layer thunks accordingly
[00:55] <wallyworld> ok
[02:11] <katco> axw: wallyworld: boom! 2015-01-29 02:10:34 INFO juju.storage.provisioner provisioner.go:128 block devices created: [{1 1771eb70-b0ca-49e3-84d4-7b73b1401d18 /dev/loop1
[02:11] <katco>     1  false}]
[02:11] <axw> katco: sweet :)
[02:11] <wallyworld> whoot
[02:11] <katco> going to sanity check the image rq, but we might be good
[02:11] <wallyworld> seems so
[02:12] <axw> katco: are you generating a UUID for the volume ID now?
[02:12] <katco> axw: currently, yes. with todos to use the algorithm you suggested
[02:12] <katco> axw: i just didn't have a machine id to hang off of
[02:12] <axw> UUID would probably be fine TBH
[02:13] <axw> assuming you're creating the image file with that too
[02:14] <katco> yes
[02:14] <katco> axw: i think we'll still have to put some thought into how to name these things so persisting across reboots isn't a pain
[02:14] <katco> axw: but that is trivial i think
[02:14] <katco> /dev/loop1: [0801]:51515891 (/var/lib/juju/storage/block/loop/var/lib/juju/storage/block/loop/1771eb70-b0ca-49e3-84d4-7b73b1401d18)
[02:14] <katco>  
[02:15] <axw> cool
[02:15] <katco> charm is hello worlding along just fine, i'm going to push these changes and have dinner
[02:15] <katco> i'll check back in after to see if there are any issues
[02:18] <katco> axw: https://github.com/wallyworld/juju/pull/4
[02:18] <wallyworld> looking
[02:18] <katco> axw: fair warning, the lxc tests are not passing (stupid trivial stuff to fix)
[02:18] <katco> wallyworld: ^^
[02:19] <katco> ok i'm eating some dinner. bbiab
[02:21] <wallyworld> ty
[02:30] <rick_h_> mattyw: let me know when the data is loaded and will check it out. It needs rating info because that's the api we hit
[02:30] <rick_h_> mattyw: so it needs the sub, the plan, and a starting rating data so that the my accout page in the UI had some records to it
[02:31] <mattyw> rick_h_, stop
[02:31] <rick_h_> mattyw: party
[02:33] <mattyw> thumper, ping?
[02:33] <thumper> mattyw: hey
[02:34] <thumper> mattyw: wwitzel3 reviewed that branch :)
[02:34] <mattyw> thumper, hey there, ok cool - I didn't get around to much reviews yesterday so I'm going to try to get to some today
[02:34] <mattyw> thumper, quick question for you
[02:34] <thumper> shoot
[02:35] <mattyw> thumper, recently I've been wanting to find the envuuid from juju via the command line - I don't think we have one at the moment, and it feels like it might be something that would be useful to have in juju status
[02:35] <mattyw> thumper, wanted to know what thoughts/ plans you had for that kind of thing
[02:35] <thumper> mattyw: there is one
[02:35]  * thumper bootstraps to check
[02:36] <thumper> $ juju api-info environ-uuid
[02:36] <thumper> 607aa9ab-dd2e-4943-86c3-3fc65b800450
[02:36] <thumper> mattyw: ^^
[02:36] <thumper> although, in status?
[02:36] <thumper> maybe
[02:37] <mattyw> thumper, awesome!
[02:37] <mattyw> thumper, that certainly makes me happy for now
[02:37] <mattyw> thumper, I didn't know about the api-info command - feels like Christmas :)
[02:37] <mattyw> thumper, thanks for the help :)
[02:37] <thumper> np
[02:38] <mattyw> thumper, as along as it's available somewhere I'm happy for now
[02:39] <thumper> kk
[02:46] <wallyworld> axw: another oarsum hack https://github.com/wallyworld/juju/pull/16
[02:46] <axw> wallyworld: looking
[02:49] <axw> wallyworld: reviewed
[02:49] <wallyworld> ty
[03:01] <katco> wallyworld: i've addressed your concerns. ok if i merge?
[03:01] <wallyworld> katco: would be awesome
[03:02] <katco> wallyworld: i think you might have to do it since i don't have write access
[03:02] <wallyworld> katco: oh ffs i keep forgetting
[03:02] <wallyworld> katco: merged \o/ tyvm
[03:03] <wallyworld> i'll try it out now
[03:03] <wallyworld> after meeting
[03:03] <katco> wallyworld: i would feel a lot better if you or axw could poke at things and make sure this is working (multiple block devices etc.)
[03:03] <wallyworld> will do
[03:03] <katco> wallyworld: i'm not familiar enough yet to know what edges there are
[03:03] <axw> katco: sure, I'll have a play with it
[03:03] <katco> axw: tyvm
[03:04] <katco> ok, i'm going to take care of a few things... please ping me if you find something!
[03:53] <axw> wallyworld: FYI, the loop devices won't get cleaned up if you destroy the machine
[03:54] <axw> wallyworld: we should be marking these as "persistent" later, and preventing env destruction till they're gone
[03:54] <wallyworld> axw: i just noticed that
[03:54] <wallyworld> i ate my disk with a large loop device
[04:01] <thumper> axw,wallyworld: either of you remember where is the cloud-init.log file is on cloud machines?
[04:01] <axw> thumper: I thought it was just /var/log/cloud-init-output.log ?
[04:02] <thumper> axw: ta
[04:02] <wallyworld> what he said
[04:13] <wallyworld> axw: sorta works, but something is not quite wired up - attached hooks complaining storage foo/0 is not provisioned, just digging into that now
[04:13] <wallyworld> this is for loop on local
[04:13] <axw> wallyworld: yeah, I'm having some issues too but I've modified the provisioner
[04:14] <wallyworld> so close
[04:33] <anastasiamac> axw: wallyworld: there r separate discussion going on..
[04:34] <anastasiamac> axw: wallyworld: is it pool manager responsibility to vaidate provider type supplied
[04:34] <anastasiamac> axw: wallyworld:?
[04:34] <anastasiamac> axw: wallyworld: on pool create that is...
[04:35] <wallyworld> depends if we think pool manager should know about envieons
[04:35] <axw> I guess not
[04:35] <axw> it should validate the storage provider type, but probably not whether it is valid for the current environment
[04:35] <wallyworld> that is my initial thought, but i'm happy to be wrong
[04:36] <axw> it does make me a little nervous that something else will come along and use the pool manager without validating, that's all
[04:36] <wallyworld> may need another component - EnvironPoolManager
[04:37] <wallyworld> or maybe that's overkill
[04:37] <axw> that might make it clearer, but you could still go through the PoolManager directly (unless that gets hidden)
[04:37] <wallyworld> yes
[04:37] <wallyworld> not too fussed either way
[04:38] <wallyworld> was just trying to reduce external dependencies of pool manager
[04:38] <wallyworld> would i think prefer an EnvironPoolManager to live in /environ/storage
[04:38] <wallyworld> and the api calls that
[04:39] <axw> I vote we defer this decision, and do validation in the apiserver code for now
[04:39] <wallyworld> yep, sounds good
[04:39] <wallyworld> was about to say that :-)
[04:40] <wallyworld> am annoyed we have so much business logic in apiserver layer - need to fix that sometime
[04:44] <thumper> heh
[04:45] <thumper> wallyworld: I'm sure it is because we don't have a business layer
[04:45] <thumper> we have apiserver and state
[04:45] <thumper> and people didn't want it in state
[04:45] <thumper> so guess where it goes
[04:45] <wallyworld> thumper: i know too well the reason - been annoyed about it for ages as you know
[04:45] <thumper> yeah.... I know
[04:45]  * thumper has the munchies
[04:49] <wallyworld> thumper: if i just install django, is there a default page like for apache or tomcat etc?
[04:50] <thumper> kinda
[04:50] <thumper> you mean locally or the charm?
[04:50] <axw> wallyworld: sorry, I think your SetProvisionedBlockDevices method is broken. it's only calling state.DemoSetProvisionedBlockDeviceInfo if err != nil above
[04:51] <wallyworld> thumper: i just want to expose the service and point a browser to it to see it worked
[04:51] <thumper> wallyworld: it might work, but not entirely sure
[04:51] <wallyworld> kk
[04:51] <wallyworld> axw: ffs i'm stupid
[04:52] <axw> wallyworld: I'm changing the storage provisioner to periodically check for unprovisioned storage instances
[04:53] <axw> wallyworld: not using a watcher because the entities are in the wrong places (not associated with machine, but units)
[04:53] <wallyworld> can you fix that stuff up while you're there?
[04:53] <axw> yes
[04:53] <wallyworld> ta
[04:53] <axw> just testing now
[04:53] <wallyworld> dontcha love hacks for demos
[04:58] <menn0> wallyworld: you too huh? :)
[04:58] <wallyworld> noooooo, we aren't using *any* dirty hacks
[04:59] <wallyworld> we're far better than that
[05:00] <menn0> wallyworld: of course not. we aren't either. ;-/
[05:00] <wallyworld> glad to hear it
[05:38] <axw> wallyworld: I think we should be running those LXC changes by someone, could be opening up security holes
[05:39] <axw> wallyworld: in particular, looks like we're dropping all AA protection
[05:39] <wallyworld> i think we can tighten up the rules
[05:39] <wallyworld> after the demo :-)
[05:39] <axw> of coursed
[08:45] <wallyworld> axw: nice branch. we should also be able to register the new providers for ec2 as well as local i would expect?
[08:45] <axw> wallyworld: yep
[08:45] <wallyworld> wanna add that real quick?
[08:46] <axw> wallyworld: sure, just testing a tmpfs provider.. I think it needs more lxc config hacks to work
[08:46] <axw> likewise with formatting/mounting block devices in local, I think
[08:46] <wallyworld> ah bollocks
[08:47] <axw> wallyworld: actually I think I've just mucked up the mount syntax, but could still be broken... will come back to it
[08:47] <wallyworld> righto
[08:50] <axw> wallyworld: testing rootfs on ec2, will take a few mins
[08:50] <wallyworld> sure, np
[08:50] <wallyworld> my connection has been shit today, so ec2 testing is painful
[09:02] <axw> wallyworld: updated
[09:03] <wallyworld> ty looking
[09:06] <wallyworld> thanks axw, i'll merge
[09:06] <axw> cool
[09:13] <axw> wallyworld: I was worried about nothing, tmpfs works on local
[09:13] <wallyworld> farking oarsum
[09:19] <axw> wallyworld: https://github.com/wallyworld/juju/pull/19
[09:19] <wallyworld> looking
[09:20] <wallyworld> sigh, ec2 is slooooow right now
[09:20] <anastasiamac> axw:wallyworld: running tests after rebasing, m getting
[09:20] <anastasiamac> cmd/juju/storage/listformatters.go:11:2: cannot find package "github.com/dustin/go-humanize"
[09:20] <anastasiamac> axw: ?
[09:20] <axw> anastasiamac: godeps -u dependencies.tsv
[09:20] <wallyworld> axw: i did have a way of registering common providers but removed it due to import loops
[09:21] <wallyworld> i plan on adding it back later
[09:21] <axw> wallyworld: cool
[09:21]  * anastasiamac rolles eyes
[09:21] <anastasiamac> axw: of course :D
[09:22] <axw> wallyworld: unless you think there's anything else we need for next week, I'm going to take a step back from code and go back to the model rework
[09:27] <wallyworld> axw: should storage-dir in tmpfs default to <libdir>/storage or similar?
[09:27] <axw> libdir?
[09:27] <wallyworld> the juju lib dir setting
[09:27] <wallyworld> can't remember the name
[09:27] <wallyworld> comes from agentconfig
[09:28] <axw> wallyworld: data-dir?
[09:28] <axw> wallyworld: as in /var/lib/juju/storage?
[09:28] <wallyworld> yeah
[09:28] <axw> isn't that where I put them?
[09:28] <axw> /var/lib/juju/storage/fs
[09:29] <wallyworld> ah, haven't seen that in the diff yet
[09:30] <wallyworld> ah there it is
[09:30] <axw> wallyworld: I really think we need to change the way that works, since (as I noted in a TODO) the data-dir isn't necessarily the same on all machines
[09:30] <wallyworld> at the bottom
[09:30] <wallyworld> it should be decided late
[09:30] <axw> so it can't be a property of the pool, but of the provider as instantiated in the agent
[09:30] <wallyworld> yep
[09:31] <wallyworld> will do for now :-)
[09:31] <axw> yep
[09:32] <wallyworld> axw: i'll fix that failing test anastasia mentioned. on my machine the cmd/juju tests *always* hang and time out :-(
[09:33] <axw> okey dokey
[09:33] <axw> thanks
[09:36] <axw> wallyworld: actually before I go off to do model things, one more thing... we should be able to use the storage subordinate now
[09:36] <wallyworld> axw: only web app i can find that works with postgres is discourse and it fails to install - apt issues, fixed, but now sig verification failure. just seems too out of date
[09:37] <axw> :(
[09:37] <wallyworld> oh storage subordinate
[09:37] <wallyworld> hmmm
[09:37] <wallyworld> if there were a bundle with that with a web app charm, might be good
[09:38] <wallyworld> i'd still like to find a web apps just just uses postgres like wordpress uses mysql
[09:38] <wallyworld> i might see about making mysql chamr use storage
[09:39] <wallyworld> but first food
[09:40] <axw> wallyworld: https://jujucharms.com/rails-example-single/6 ?
[09:40] <axw> I'll test it out..
[09:40] <wallyworld> nice, how'd you find that?
[09:40] <wallyworld> my charm store search foo must be bad
[09:40] <axw> wallyworld: jujucharms.com, bundles
[09:41] <axw> looked for one with an elephant :)
[09:41] <wallyworld> :-)
[09:41] <wallyworld> right, i need to eat first then charms
[10:14] <voidspace> TheMue: https://github.com/voidspace/juju/compare/dimitern:wip-ec2-addressable-containers...wip-preparecontainerinterfaceinfo
[10:16] <voidspace> TheMue: there's a comment in there "// TODO: (mfoord) we should add the machine ID to the IP"
[10:16] <voidspace> TheMue: that's out of date and can  be removed (the call to addr.AllocateTo does this)
[10:24] <wallyworld_> axw: data=rootfs,10M   <- forces the use of the 10M or else it errors. we shouldn't need that for filesystemmounts
[10:25] <axw> wallyworld_: that's not always true. Ceph will need it...
[10:25] <wallyworld_> rightio, so it needs to be optional
[10:26] <axw> wallyworld_: yep. it should default to 1G anyway, which will then be ignored
[10:26] <wallyworld_> yep
[10:33] <wallyworld_> axw: loop file systems, as accessed from inside container, are owned by root. we will need to make the ownership ubuntu.ubuntu
[10:33] <axw> wallyworld_: do we? the charms run as root
[10:33] <wallyworld_> unity also notified me of a new device and showed the disk icon in the launcher. and i can see what files i create from inside the container
[10:33] <axw> nice :)
[10:33] <wallyworld_> ah yeah, fair enough
[10:34] <axw> wallyworld_: that fails app fails when I try to install it...
[10:34] <wallyworld_> joy
[10:34] <axw> wallyworld_: apparently you can use django, but I have nfi about it
[10:34] <wallyworld_> me either
[10:34] <wallyworld_> i was hoping django had a welcome page
[10:34] <wallyworld_> like apache, tomcat etc
[10:35] <wallyworld_> but i didn't see one
[10:39] <wallyworld_> axw: i think juju storage list should be sorted by owner. thoughts? i had a few units and would prefer to see storages for the units listed together
[10:39] <menn0> anyone able to look at this one line fix: http://reviews.vapour.ws/r/820/
[10:39] <axw> wallyworld_: yeah, probably
[10:39] <axw> wallyworld_: in the tabular format anyway
[10:39] <wallyworld_> menn0: oh, you ask all the hard questions
[10:40] <wallyworld_> axw: yep
[10:40] <menn0> wallyworld_: sorry :)
[10:40] <menn0> wallyworld_, axw: thanks guys
[10:42] <wallyworld_> anastasiamac: can you please sort the tabular storage list by owner? when you are free
[10:52] <perrito666> morning
[11:21] <voidspace> perrito666: morning
[11:26] <wallyworld__> axw: this fixes some tests (yours and mine :-) and also makes default size 1G and default count 1 always https://github.com/wallyworld/juju/pull/20
[11:27] <menn0> wallyworld__, axw: pushing a branch now that fixes the panic that's currently being frequently seen during merge attempts
[11:28] <wallyworld__> which test?
[11:29] <menn0> wallyworld__: the leadership feature tests are failing frequently
[11:30] <menn0> the problem isn't actually with those tests but with my recent change to how the machine agent workers are started
[11:30] <menn0> subtle race
[11:30] <wallyworld__> ok, i hadn't noticed as ee've been landing to a feature branch
[11:30] <wallyworld__> great that you caught it
[11:30] <menn0> wallyworld__: http://reviews.vapour.ws/r/821/
[11:31] <menn0> wallyworld__: funnily enough, this related to a review comment you made :)
[11:31] <wallyworld__> oh, i hate to ask, which one?
[11:32] <menn0> wallyworld__: where we were discussing whether the envWorkerManager should clean up the returned runner even when an error was returned
[11:32] <wallyworld__> ah right
[11:32] <menn0> wallyworld__: I was using an unusual pattern, which you picked up on
[11:32] <wallyworld__> ancient history, > 1 week ago :-)
[11:32] <menn0> wallyworld__: this fix in the same area
[11:34] <wallyworld__> menn0: done, ty for fix
[11:35] <menn0> wallyworld__: thanks. good idea re the comment
[11:35] <wallyworld__> menn0: i can't recall, maybe even a comment next to where singular runner is used if it's releavnt to do so
[11:36] <menn0> wallyworld__: I actually have a better idea which is clearer and reduces the assumptions about the singular runner's behaviour
[11:36] <wallyworld__> ok
[11:43] <menn0> wallyworld__: pls take a look again. this is much clearer IMO. http://reviews.vapour.ws/r/821/diff/
[11:43] <wallyworld__> ok
[11:44] <wallyworld__> menn0: can we remove "&& singularRunner != nil" now?
[11:45] <wallyworld__> looks much nicer
[11:45] <menn0> wallyworld__: probably but I've been bitten by not have a guard like that before
[11:45] <menn0> wallyworld__: let me try it
[11:45] <wallyworld__> menn0: i can't see that it's needed as we exit above with an err before the defer
[11:46] <menn0> wallyworld__: yeah I know, but I've thought that before and had problems
[11:46] <menn0> wallyworld__: that was in a slightly different case though
[11:46] <wallyworld__> menn0: runner and singular runner usage looks the same and runner has no guard
[11:47] <wallyworld__> oh wait
[11:47] <wallyworld__> sorry
[11:47] <wallyworld__> can't read
[11:47] <menn0> wallyworld__: it does for the defer that cleans
[11:47] <wallyworld__> LGTM
[11:47] <menn0> wallyworld__: i'm going to remove them and re-run the tests and my little tester that was triggering the panics
[11:47] <menn0> wallyworld__: the guards irk me too
[11:47] <wallyworld__> ok
[11:49] <menn0> wallyworld__: yep, doesn't work. panics due to nil pointer dereference
[11:49] <wallyworld__> doh
[11:49] <menn0> wallyworld__: I don't get why... something special about defers perhaps and how they get executed?
[11:49] <wallyworld__> nfi right now
[11:50] <menn0> wallyworld__: I don't care right now. bed awaits and I still have some other (non-work) jobs to do
[11:50] <wallyworld__> yep, land tha sucker
[12:15] <menn0> wallyworld__: that's in. thanks for the late night review.
[12:15] <wallyworld__> np, catch you later
[12:15] <wallyworld__> really late for you
[12:15] <menn0> yeah :)
[12:18] <jam> wallyworld__: anything to go over before I see you in Capetown ?
[12:19] <jam> fwereade: ^^
[12:19] <wallyworld__> jam: nothing urgent - just need go over storage, health etc prior to seeing mark
[12:20] <wallyworld__> jam: there's a few things re: storage we can disuss over there
[13:23] <katco> wallyworld__: axw: hey, just waking up. how are things with storage?
[13:23] <wallyworld__> katco: good :-)
[13:23] <katco> wallyworld__: woohoo!
[13:23] <wallyworld__> loop provider works
[13:23] <wallyworld__> was tweaked a bit
[13:23] <katco> wallyworld__: cool
[13:24] <wallyworld__> axw added tmpfs and rootfs
[13:24] <katco> wallyworld__: anything i should know going into today?
[13:24] <katco> very cool
[13:25] <wallyworld__> katco: we do need to 1. evaluate the permissions, especially the aa ones on the container (but that can wait); 2. loop at mounting an external block device
[13:25] <wallyworld__> look not loop
[13:26] <axw> and bind mounting into local provider
[13:26] <katco> wallyworld__: understood on both accounts. 1 is part of a lot of cleanup we'll have to do
[13:26] <wallyworld__> yep
[13:26] <katco> wallyworld__: axw: i was planning on looking at 2 today
[13:26] <wallyworld__> doesn't matter for demo of course
[13:26] <wallyworld__> great :-)
[13:26] <axw> cool
[13:27] <katco> wallyworld__: axw: ok i'm off to get ready. you guys rock!
[13:27] <katco> anastasiamac: and you as well if you're around
[13:27] <axw> katco: later, hope you have a good day
[13:28] <wallyworld__> axw: not sure if you saw before, i fixed some tests and added default size handling https://github.com/wallyworld/juju/pull/20
[13:28] <axw> wallyworld__: I didn't. looking now
[13:28] <wallyworld__> i made count default to 1 regardless of size
[13:28] <wallyworld__> if count wasn't specified
[13:37] <axw> wallyworld__: reviewed
[13:37] <wallyworld__> ty
[13:44] <wallyworld__> axw: changes pushed
[13:45] <axw> wallyworld__: LGTM, thanks
[13:45] <wallyworld__> merged
[13:48] <wallyworld__> katco: also, if you're bored, there's also investigating how to provision block devices on openstack (as we do with EBS volumes on AWS)
[14:04] <dimitern> jam, hey, as OCR can you have a look at this please? http://reviews.vapour.ws/r/822/
[14:16] <dimitern> wallyworld__, axw, ^^
[14:16] <dimitern> well not as OCRs but if you have some time :)
[15:08] <alexisb> wallyworld__, axw you guys must be robots that don't need sleep
[15:17] <jamestunnicliffe> dimitern: Could you review http://reviews.vapour.ws/r/823/ please?
[15:17] <dimitern> jamestunnicliffe, sure, looking
[15:18] <mgz> ....snow
[16:05] <ericsnow> perrito666: are we having standup? (no natefinch, no wwitzel3)
[16:05] <perrito666> ericsnow: we can wave it
[16:05] <perrito666> ericsnow: yet Ill priv you a question
[16:05] <ericsnow> perrito666: k
[16:10] <TheMue> voidspace: why do you think so?
[16:10] <voidspace> TheMue: no reason...
[16:16] <jamestunnicliffe> dimitern: http://reviews.vapour.ws/r/824/ should work. Deleted the old merge and review request
[16:25] <dimitern> jamestunnicliffe, reviewed
[17:14] <dimitern> mgz, ping
[17:15] <mgz> dimitern: hey
[17:16] <dimitern> mgz, hey! so a quick question about the merge bot
[17:16] <mgz> hit me
[17:16] <dimitern> mgz, jamestunnicliffe - our new team mate wants to land a PR - https://github.com/juju/juju/pull/1502 - and he is in juju Hackers group on GH, has access to RB and all
[17:16] <dimitern> mgz, but it seems the bot is not picking up his $$merge$$ comment
[17:17] <mgz> jamestunnicliffe: have you set your membership of the juju group to public?
[17:17] <dimitern> mgz, ah! that might be it :)
[17:17] <dimitern> mgz, he went for some tea - will ask him in a moment :)
[17:18] <mgz> cool, poke if that doesn't help
[17:18] <dimitern> mgz, cheers! I can see his membership is private, that should be it
[17:28] <dimitern> voidspace, http://reviews.vapour.ws/r/822/diff/
[19:34] <perrito666> wallyworld__:  you are going to hate me when you are back
[19:53] <wwitzel3> ericsnow: I'm back btw, just trying to finish up this final once over I promised for the cloudsigma provider
[19:54] <ericsnow> cool
[19:54] <ericsnow> wwitzel3: how'd it go?
[19:54] <wwitzel3> ericsnow: how is the services stuff going? also we should probably start poking people to have another look at GCE now that the first set of review fixes are up.
[19:54] <alexisb> wwitzel3, so are you officially moved in?
[19:54] <ericsnow> wwitzel3: I'm wrapping things up (hope to have an initial patch up soon)
[19:55] <ericsnow> wwitzel3: the systemd stuff on top of that will be almost trivial :)
[19:55] <wwitzel3> ericsnow, alexisb: went great, keys in hand, we are going to take some stuff over tonight and tomorrow evening and stay the night tomorrow :)
[19:55] <ericsnow> \o/
[19:55] <wwitzel3> ericsnow: yeah, I was thinking I would do that, no better test of an abstraction than having someone who didn't write it, us it :)
[19:55] <wwitzel3> s/us/use
[19:55] <ericsnow> wwitzel3: perfect
[19:56] <alexisb> wwitzel3, sweet, first nights are always fun
[19:56] <wwitzel3> alexisb: yeah, pizza on the floor as been my tradition since my first house ~12 years ago, so probably do that again
[20:25] <menn0> thumper, waigani: that CI blocker details are a little off but there is a problem
[20:25] <menn0> thumper, waigani: I suspect this is unrelated to the issue I already fixed
[20:25] <waigani> yay
[20:25] <menn0> thumper, waigani: for whatever reason it seems much more likely on i386 than other archs
[20:26] <menn0> thumper, waigani: in fact it hasn't happened yet on amd64
[20:26] <menn0> waigani: you haven't committed any presence changes yet have you?
[20:26] <waigani> menn0: nop
[20:26] <menn0> waigani: cause it's now the presence pinger that's dying
[20:26] <waigani> oh really?
[20:26] <menn0> waigani: I have a theory that the presence pinger is still active when state is shut down
[20:28] <waigani> menn0: could it be one of our multi-env tests - sets up two states, and the pinger for each will currently listen to everything from all envs?
[20:28] <menn0> thumper, waigani : even though from a quick look at the code that doesn't seem possible
[20:28] <menn0> thumper, waigani : I'll keep digging post-kids swimming. I have to go now.
[20:28] <waigani> menn0: cool.
[20:40] <sinzui> menn0: Right, you branch fixed some of the panics CI saw, but not all :(
[21:09]  * thumper sad-face
[21:12] <wallyworld__> perrito666: that maas issue is easy to fix - i can do it. the time to wait is more than sufficient on vmaas but clearly not on hardware so i'll increase it
[21:25] <perrito666> wallyworld__: isnt there a better way?
[21:25] <wallyworld__> sadly no
[21:25] <wallyworld__> the deployment process involves a reboot
[21:25] <wallyworld__> and all juju can do is poll
[21:26] <wallyworld__> i discussed the approach with the maas guys
[21:47] <thumper> waigani, menn0, cherylj, davecheney: http://paste.ubuntu.com/9943662/
[21:47] <wallyworld__> trivial review for 1.22 maas fix http://reviews.vapour.ws/r/825/
[21:48] <thumper> huh...
[21:48] <thumper> why am I surprised that this is working?
[21:48] <waigani> thumper: is that juju status of another env? Nice!
[21:48] <thumper> waigani: yep
[21:48] <thumper> and I just did 'juju ssh 0'
[21:48] <thumper> and got in to it
[21:49] <waigani> sweet
[21:50] <waigani> thumper: next test would be to expose a service, i.e. wordpress/mysql and visit it
[21:50] <thumper> there are problems with the rsyslog worker
[21:51] <thumper> hmm...
[21:51] <thumper> inside the machine, the logdir is /var/log/juju
[21:51] <thumper> however on the host it is /var/log/juju-tim-another
[21:51] <thumper> and the rsyslog worker is looking for the host log dir not the machine log dir
[21:54] <waigani> thumper: extend RsyslogConfig to hold the dir path?
[21:55] <thumper> I'll be looking into it next
[21:56] <thumper> huh
[21:56] <thumper> I now have ubuntu deployed in both environments
[21:56] <thumper> time for some wordpress/mysql action
[21:57] <waigani> =D
[22:17] <thumper> :(
[22:17] <thumper> now I have machines for the secondary environment, we need waigani's destroy branch
[22:17]  * thumper taps fingers
[22:18]  * thumper does things manually
[22:30] <menn0> thumper: that's awesome that it's working
[22:30] <menn0> jw4: ping
[22:31] <menn0> thumper: can you push what you have to your repo soon so I can grab it?
[22:32] <sinzui> wallyworld_: I am fighting google
[22:37] <jw4> menn0: yep
[22:42] <thumper> menn0: pushing it up now
[22:46] <thumper> menn0: https://github.com/howbazaar/juju/tree/juju-environment-create
[22:48] <menn0> thumper: cheers
[23:08] <menn0> davecheney: do you know if "go test" run tests in parallel by default?
[23:14] <waigani> menn0: I asked davecheney the same question a while ago: answer was no
[23:15] <menn0> waigani: interesting. one of the stacktraces i'm looking had has teardowns running from different test suites in different packages (in separate goroutines)
[23:15] <waigani> menn0: with pingInfo, do we need to add a docID and leave Slot as an int64? i.e. the same as you suggested for beingInfo?
[23:16] <waigani> oh really?
[23:16] <davecheney> menn0: the answer is yes
[23:16] <davecheney> and no
[23:16] <davecheney> tests inside a package are run in sequence
[23:16] <menn0> waigani: re pingInfo, yeah that sounds right (so change the underlying field name for Slot)
[23:16] <davecheney> multiple packages are tested in parallel, just like they are built in parallel
[23:17] <menn0> davecheney: ok, that explains that then. thanks.
[23:17] <waigani> ah right
[23:17] <menn0> davecheney: I hadn't noticed that before so it wierded me out
[23:21] <davecheney> menn0: you've not noticed that running the tests uses all your cores ?
[23:23] <davecheney> sorry, that sounded passive agressive
[23:23] <davecheney> what i meant to say is
[23:23] <davecheney> go test .../juju/... would take over an hour if packages were not tested in parallel
[23:25] <menn0> davecheney: I wasn't offended :)
[23:26] <menn0> davecheney: I run tests for the package i'm working on most of the time which just uses one core
[23:26] <menn0> davecheney: for full runs I often start it and walk away so don't really notice core usage