[00:04]  * thumper sighs
[00:04] <thumper> tests failed because other people landed code...
[00:04]  * thumper merges and updates
[02:19] <axw> wallyworld__: actually, before tmpfs it would be more useful to have "loop"
[02:20] <axw> wallyworld__: so we have the fallback case covered
[02:23] <wallyworld__> axw: yes, i was hoping we'd churn out tmpfs, loop more or less together
[02:23] <wallyworld__> but loop first, i agree
[03:36] <menn0> thumper, wallyworld__ : holy crap there's lots of crazy duplication of test helpers in state
[03:36] <thumper> :)
[03:36] <menn0> thumper, wallyworld__ : fixing a bunch of it now
[03:36] <thumper> cheers
[03:36] <wallyworld__> \o/
[03:37] <menn0> thumper, wallyworld__ : it's tricky because some tests in state are internal, but I see a path to making a lot of it better
[03:48] <axw> wallyworld__: http://reviews.vapour.ws/r/757/
[03:48] <wallyworld__> looking
[04:15] <thumper> menn0: I'm getting there with the tests but I have one leaving a dirty socket around
[04:15] <thumper> a mongo connection
[04:15] <thumper> it is definitely the test where we have a different connection from state
[04:15] <thumper> but I can see that my resource cleanup is getting called
[04:15] <thumper> so not sure where
[04:16] <thumper> if you are good with it, perhaps we could go through it in the morning to see WTF is going on?
[04:23] <menn0> thumper: happy to
[04:28] <thumper> menn0: good, I think I've looked at it too long this afternoon, pushing up current
[04:29] <menn0> thumper: this state testing refactoring is going really well btw
[04:29] <menn0> thumper: tons of lines being removed
[04:29] <thumper> cool
[04:32] <thumper> night folks
[04:33] <axw> wallyworld__: mind seeing my comments before I land?
[04:34] <wallyworld__> axw: yah, looking now
[04:44] <wallyworld__> axw: commented, not sure if you wsnt to discuss
[04:47] <axw> wallyworld__: LVM is at a higher level. there's nothing stopping you from creating a volume group across different providers. I'm not sure if we should be using quite the same machinery for them. how do you tell it which device(s) to operate on?
[04:51] <axw> wallyworld__: I could well see an LVM storage provider that creates "disks" as logical volumes for you, but I think the relationship between the LV and the disks in its volume group is outside this model
[04:54] <axw> wallyworld: not sure where you saw up to...
[04:54] <axw> wallyworld: LVM is at a higher level. there's nothing stopping you from creating a volume group across different providers. I'm not sure if we should be using quite the same machinery for them. how do you tell it which device(s) to operate on?
[04:54] <axw> wallyworld: I could well see an LVM storage provider that creates "disks" as logical volumes for you, but I think the relationship between the LV and the disks in its volume group is outside this model
[04:55] <wallyworld> axw: sigh, freenode hates me, keeps kicking me off :-(
[04:57] <wallyworld> axw: instead of LV, what about loopback? i guess the point for me is that the provisioner etc sees a block device and it's outside of its interest how that is provider, physical disk or otherwise
[04:58] <wallyworld> axw: afk, bbiab
[04:59] <axw> wallyworld: the name Disk is probably just a poor one. what I mean is "block device that the provider manages", as opposed to "block device that a machine sees"
[05:29] <axw> wallyworld: let me know when you're back
[05:30] <axw> -_-
[05:34] <wallyworld> axw: yeah, that's how i think of it too. Disk though gives the opposite connotation. gad i hate naming things
[05:37] <axw> wallyworld: it's really "volume" and "attachment", but that doesn't marry with discovered devices
[05:42] <wallyworld> should or could we go with Volume instead of Disk for what we have currently? that would still work with discovered devices i think?
[05:43] <wallyworld> i *think* that may remove the current ambiguity?
[05:44] <wallyworld> anastasiamac: it's clear these a mix of approaches wrt api param naming :-( let's go with what you have so we can get it landed
[05:46] <axw> wallyworld: I'm fine with calling it Volume, though I don't see much of a difference
[05:48] <axw> except that it might be a little clearer that it's not necessarily a physical or dedicated disk
[05:48] <wallyworld> axw: perhaps i'm being too pedantic wrt naming. or confused. or both. I think of Disk as a physical device, whereas Volume is an abstraction that better applies to various device types loopback vs VG vs disk etc
[05:48] <wallyworld> yes
[05:49] <wallyworld> that's where i'm coming from
[05:49] <axw> wallyworld: fair enough. I'll change it. I'll need to update juju/names too, but I'll do that later
[06:05] <axw> wallyworld: PTAL
[06:06] <wallyworld> sure
[06:09] <wallyworld> axw: thanks, i think the naming is clearer now. well to me it is :-)
[06:09] <axw> wallyworld: cool
[06:09] <menn0> wallyworld: you might like this: http://reviews.vapour.ws/r/759/
[06:10] <wallyworld> looking
[06:10] <wallyworld> oooh refactoring
[06:10] <axw> wallyworld: in case you missed it, I added a TODO to rename the results of {Create,Describe}Volumes to return something other than BlockDevice, since it will want to convey information that isn't pertinent to the machine level
[06:10] <axw> such as detachability, persistence, etc.
[06:10] <menn0> wallyworld: see what happens when you make a single review comment about extracting some test helpers out
[06:10] <wallyworld> axw: yep, sounds good
[06:10] <menn0> wallyworld: I then went and noticed all the awful duplication and felt the need to fix it
[06:10] <wallyworld> menn0: \o/ thank you
[06:11] <wallyworld> axw: short term goal is to get collaboration possible, i think this branch enables that
[06:12] <menn0> wallyworld: dealing with kids now so no rush
[06:12] <axw> wallyworld: yep. I will land and get back to juju deploy
[06:12] <wallyworld> menn0: ok, will finish a few things and then look, really appreciate the work to do this
[06:13] <wallyworld> axw: we still need some glue to plug it all in, but at least the storage sources for eg loopback can be written and tested
[06:50] <dimitern> morning all
[07:01] <anastasiamac> dimitern: morning :D
[07:02] <dimitern> anastasiamac, o/
[07:04] <dimitern> anastasiamac, nice new facade btw :)
[07:08] <menn0> wallyworld_: thanks for the review. i'll add that comment and then get it in.
[07:08] <wallyworld_> awesome
[07:25] <anastasiamac> dimitern: thnx :)
[07:27] <wallyworld__> axw: got a few minutes? hangout in our 1:1?
[07:27] <axw> wallyworld__: sure
[07:32] <jam1> morning dimitern
[07:32] <dimitern> jam1, morning, sorry - omw :)
[07:32] <jam1> just grabbing a coffee, but I joined the hangout
[08:04] <axw> wallyworld__: are you there still?
[08:04] <axw> can't hear you on hangouts...
[09:10] <TheMue> dimitern: so, system is started
[09:11] <dimitern> TheMue, great! i'll be in the hangout shortly
[09:11] <TheMue> dimitern: fine
[10:24] <voidspace> dimitern: I'll be back in 5 minutes as well
[10:27] <dimitern> voidspace, ok
[10:30] <voidspace> dimitern: and back...
[11:03] <dimitern> voidspace, I've reviewed your subnets PR btw
[12:14] <voidspace> dimitern: you've suggested using a string set, which I would *love*
[12:14] <voidspace> dimitern: which packge is that from
[12:14] <voidspace> dimitern: import "set" does not work...
[12:19] <dimitern> voidspace, it's in juju/utils/set IIRC
[12:19] <voidspace> ah....
[12:19] <voidspace> *great*
[12:22] <voidspace> dimitern: ah, I can't use the set, because I'm using the underlying value (true/false) to carry meaning
[12:22] <voidspace> dimitern: (did we actually find the subnet)
[12:26] <perrito666> morning to the few of you who are here
[12:27] <voidspace> perrito666: morning
[12:34] <dimitern> voidspace, well, you could construct the set initially with all ids, then remove ones that are not found..
[12:34] <dimitern> voidspace, but i'll leave it up to you
[12:35] <voidspace> well, I *can't* remove the ones not found
[12:35] <voidspace> I use the set to track *found* ones :-)
[12:35] <voidspace> knowing which ones I haven't found is the problem I'm trying to solve :-)
[12:36] <voidspace> but I've switched the map to string[bool] as it involves less casts
[12:36] <voidspace> one instead of three
[12:36] <voidspace> dimitern: I've hit $$merge$$ and am onto the next task
[12:40] <dimitern> voidspace, ok, fair enough
[12:40] <dimitern> voidspace, cheers! :)
[12:50] <anastasiamac> voidspace: merge failed :(
[13:08]  * dimitern needs to step out for ~45m
[13:10]  * perrito666 is still drinking mate trying to swallow the news from his govt
[13:15] <perrito666> fwereade: sweeeeeeet 666 additions  :p
[13:15] <perrito666> that is your last patch
[13:15] <fwereade> perrito666, lol, awesome
[13:15]  * perrito666 imagines fwereade adding blank lines to get there
[13:16] <fwereade> perrito666, if I'd noticed I was near I probably would have done, yeah ;p
[14:55] <voidspace> anastasiamac: thanks, fixed
[15:06] <voidspace> dimitern: ping
[15:06] <dimitern> voidspace, pong
[15:07] <voidspace> dimitern: should I work on (first) either a) NetworkInterfaces for MaaS
[15:07] <voidspace> dimitern: or b) filling in the missing bits of the ec2 implementation?
[15:07] <voidspace> or c) it doesn't matter which order...
[15:07] <voidspace> if b) I have some follow up questions :-D
[15:08] <dimitern> voidspace, well :)
[15:08] <dimitern> voidspace, i'm not quite done with the ec2test filtering for NICs, so I suppose a) is best for now
[15:08] <voidspace> ...
[15:08] <voidspace> ah, cool
[15:08] <voidspace> that's what I wanted to hear...
[15:08] <voidspace> dimitern: thanks
[15:09] <dimitern> voidspace, :)
[15:09] <dimitern> voidspace, and I think splitting up the ec2 and maas implementations in separate PRs is good
[15:10] <voidspace> dimitern: yeah
[15:12] <voidspace> parsing lshw, yay!
[15:13] <dimitern> voidspace, :/ I sympathize
[15:14] <voidspace> dimitern: I created separate cards for EC2/MaaS implementation
[15:14] <voidspace> dimitern: and assigned MaaS to me and EC2 to you
[15:14] <voidspace> doesn't have to stay like that but will do for now
[15:16] <dimitern> voidspace, thanks!
[15:18] <voidspace> although, extractInterfaces pretty much does it all already
[15:18] <voidspace> might need to extend it a bit, but not much
[15:25] <dimitern> voidspace, while doing that would you mind adding ProviderSubnetId network.Id to InterfaceInfo ?
[15:26] <voidspace> dimitern: ok
[15:26] <voidspace> dimitern: ProviderSubnetId instead of SubnetId ?
[15:26] <dimitern> voidspace, and rephrase ProviderId's doc comment to clarify it's the NIC id
[15:26] <voidspace> ok
[15:26] <dimitern> voidspace, yeah, let's make it obvious
[15:26] <voidspace> okeydokey
[15:26] <dimitern> voidspace, cheers
[15:29] <voidspace> dimitern: looks like I'll be visiting friends on the Monday and Tuesday of our sprint week
[15:29] <voidspace> dimitern: so Wednesday for team meal would be ideal please :-)
[15:30] <dimitern> voidspace, sure, will keep that in mind
[15:30] <voidspace> dimitern: thanks, sorry to be a pain
[15:30] <dimitern> voidspace, no trouble at all :)
[15:30] <voidspace> dimitern: I don't get down to London often, so have a couple of friends keen to see me
[15:30] <voidspace> dimitern: and I was already booked for a meal there on Thursday!
[15:31] <dimitern> voidspace, of course, sgtm
[15:38]  * TheMue will also visit a friend, but not date yet fixed ;)
[15:39] <voidspace> TheMue: don't make it Wednesday please :-)
[15:40] <TheMue> voidspace: hehe, sure, just seen
[15:40] <voidspace> cool
[15:40] <voidspace> otherwise we have a dilemna
[15:40] <voidspace> and dimitern has to decide who he loves more ;-)
[15:40] <TheMue> *rofl*
[15:40] <dimitern> :D
[15:42] <TheMue> dimitern: do we have a kind of definition how we extend the provider interface for networking? or is it currently just a loose coupled set of functions?
[15:42] <voidspace> TheMue: we add new Environ methods ad-hoc as we need them...
[15:42] <voidspace> TheMue: the current "entry point" for new networking stuff is the SupportAddressAllocation method
[15:43] <voidspace> TheMue: if a provider returns True for this then it must support all the new networking methods
[15:43] <voidspace> TheMue: this is only true for MaaS and EC2 currently
[15:43] <TheMue> voidspace: ok
[15:43] <voidspace> TheMue: the other providers return false for SupportAddressAllocation and errors.NotImplemented for the other new networking methods
[15:43] <TheMue> voidspace: so do those methods have an own interface and where needed we we do a type assertion?
[15:44] <voidspace> TheMue: they *don't*, they *could*
[15:44] <TheMue> voidspace: or do the others have to implement "empty" methods?
[15:44] <voidspace> TheMue: they're just part of the Environ interface
[15:44] <voidspace> so yes, at the moment all providers implement them
[15:45] <voidspace> a separate interface that extends Environ would probably be clearer
[15:45] <TheMue> voidspace: so all providers have to provide them, even w/o address allocation?
[15:45] <voidspace> yep
[15:45] <voidspace> you can see that they do
[15:45] <voidspace> e.g. for NetworkInterfaces Subnets (etc)
[15:45] <TheMue> voidspace: yeah, then I would prefer one or more extra interfaces
[15:45] <dimitern> TheMue, I had a sort of plan 9 months ago - everything changed since then, so now it's ad-hoc until we get it done :)
[15:46] <voidspace> TheMue: that would be a great initial contribution :-)
[15:46] <TheMue> voidspace: hah
[15:46] <voidspace> TheMue: or did you mean you would prefer it if someone else did it?
[15:46] <voidspace> in which case, me too! :-)
[15:46] <voidspace> TheMue: just teasing, but yes I agree in principle
[15:47] <TheMue> voidspace: no, would be fine to me, so I'm forced to take a look at each networking method
[15:47] <voidspace> go for it
[15:47] <voidspace> would be quite easy, and then you'd see the new methods
[15:47] <TheMue> dimitern: how is p9 doing it?
[15:47] <voidspace> AllocateAddress and ReleaseAddress too
[15:47] <voidspace> I believe
[15:47] <dimitern> TheMue, I have no idea frankly :)
[15:47] <TheMue> dimitern: *rofl*
[15:48] <TheMue> dimitern: what I once liked is the idea of "everything is a device"
[15:49] <dimitern> TheMue, I do like this - nice and polymorphic, but alas..
[18:06] <dimitern> voidspace, ping
[18:07] <dimitern> voidspace, have a look at https://github.com/go-amz/amz/pull/20 later if you have time
[18:07] <voidspace> dimitern: ok
[18:07] <voidspace> dimitern: not long before I leave, but I can take a look
[18:07] <dimitern> wallyworld___, axw, katco , rogpeppe, can any of you please review the above PR for goamz that improves ec2test server? ^^
[18:08] <voidspace> dimitern: cool, nice work
[18:08] <dimitern> voidspace, cheers! the important part is that now we can filter NICs by "attachment.instance-id"
[18:08] <rogpeppe> dimitern: am finished for the day now and doing a sprint this week, so it might be a little while until i get around to it
[18:09] <voidspace> rogpeppe: hey, I don't suppose you can remember the name of that restaurant we went to in London?
[18:09] <voidspace> rogpeppe: we're back in London next week...
[18:09] <dimitern> rogpeppe, np, I'm just mass-pinging in the hope someone might have a look :)
[18:09] <rogpeppe> voidspace: hmm, it was nice, wasn't it?
[18:09] <rogpeppe> voidspace: i'm in london now...
[18:09] <voidspace> rogpeppe: yep...
[18:09] <rogpeppe> voidspace: no, sorry, i can't remember at all
[18:09] <voidspace> rogpeppe: heh, cool :-)
[18:09] <voidspace> never mind, shame
[18:09] <rogpeppe> voidspace: we probably found it through tripadvisor
[18:10] <voidspace> ah, I'll try searching for restaurants near Blue Fin
[18:10] <voidspace> there's probably only about 200 to check in that radius...
[18:10] <rogpeppe> dimitern: from a quick skim, it looks reasonable
[18:11] <rogpeppe> voidspace: istr it might've been north of the river
[18:12] <voidspace> ah yes, I vaguely remember crossing the river
[18:16] <voidspace> I'm signing off for the day
[18:16] <voidspace> time to go jogging
[18:16] <voidspace> g'night all
[18:18] <dimitern> rogpeppe, cheers
[20:00] <thumper> jw4: are you working or taking the day off?
[20:06] <jw4> thumper: working, but I was just about to break for the gym
[20:06] <thumper> jw4: just wanted to make sure you were aware: https://bugs.launchpad.net/juju-core/+bug/1412292
[20:06] <mup> Bug #1412292: Intermittent test failure in ActionSuite.TestActionsWatcherEmitsInitialChanges <action> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1412292>
[20:07] <jw4> thumper: yeah I saw that.  Thanks for filing it.  I need to figure out what causes it.  I thought that test was isolated well enough but obviously not.
[20:11] <thumper> coolio
[22:11] <hazmat> how do we set feature flags ?
[22:14] <hazmat> looks like via env var on client
[22:28] <hazmat> thumper, re env manager, how does one get access to it? its not showing up in the client api facades on logged in conn
[22:29] <thumper> hazmat: no, it isn't hooked up
[22:30] <thumper> and yes, feature flags are set by env var
[22:30] <hazmat> thumper, ah, that would explain it
[22:30] <hazmat> JUJU_DEV_FEATURE_FLAGS valid values storage,actions
[22:30] <hazmat> yeah
[22:30] <thumper> hazmat: I have a branch, but got derailed
[22:30] <thumper> found two kinda critical things that were more important
[22:30] <thumper> and now I'm banging my head against the fucking dummy provider
[22:31] <hazmat> thumper, no worries was just looking at restructuring the jujuclient to automatically expose facades as objects off the conn, corresponding to those actually present
[22:31] <thumper> I do feel like we are getting close though
[22:31] <hazmat> thumper, there's a couple of interesting integrations around envmanager(obviously) mostly looking to get those rolling end of feb
[22:31]  * thumper nods
[22:32] <thumper> should be well hooked up before then :)
[22:54] <thumper> ah mah gaad
[22:54] <thumper> finally have the test failing the way I expect
[22:54] <thumper> what a freaking mission
[22:55]  * thumper must remember to reset the branch before proposing to remove expletives
[22:57] <thumper> so... apart from that panic, we're good
[22:57]  * thumper grumbles
[22:58] <thumper> meh
[23:04]  * thumper head desks
[23:20] <thumper> fark!!!!!
[23:21]  * thumper wonders if he has broken anything else
[23:21] <perrito666> thumper: feeling like colombian revolution?
[23:21] <thumper> perrito666: I don't get it
[23:21] <perrito666> thumper: farc is the name the colombian "revolutionary" group that drives narcotrafic calls them selves
[23:22] <thumper> ah
[23:22] <perrito666> iirc fuerzas armadas revolucionarias de colombia
[23:22] <thumper> no I was mentally bitching about why the common.Resources didn't stop things in the reverse order they were registered
[23:22] <thumper> but rather randomly
[23:23] <thumper> which ment my pinger died because the state connection was closed already
[23:23] <perrito666> by design?
[23:23] <thumper> by not caring
[23:23] <thumper> now they do work that way
[23:23] <thumper> before there wasn't any dependency between resources
[23:23] <thumper> now there can be
[23:23] <thumper> before it didn't matter
[23:23] <thumper> now it does
[23:27] <perrito666> changes, i hate those
[23:29] <thumper> menn0: I think I have this ready to go now
[23:29] <thumper> menn0: all the tests are running and passing except for one "bad record MAC:
[23:31] <menn0> thumper: orrsum
[23:33] <thumper> menn0: although to get it fully working, there is more work needed in the apiserver code
[23:33] <thumper> but for the other handlers
[23:33] <thumper> like tools, charms, iamges, debuglog
[23:35] <menn0> wallyworld_: i've updated http://reviews.vapour.ws/r/754/ in response to your review comments.
[23:35] <anastasiamac> thumper: what's worng with charms handlers?..
[23:35] <wallyworld_> menn0: ty, looking
[23:35] <menn0> wallyworld_: there's a couple of things that i need your feedback on
[23:35] <thumper> anastasiamac: they don't support the correct state connectino for non-state server environments
[23:35] <anastasiamac> thumper: :(
[23:36] <anastasiamac> thumper: what's correct state connection look like?
[23:36] <thumper> I'll fix it.   All the workers will need the same fix
[23:36] <menn0> wallyworld_: no rush. I'm about to have lunch and take Amelia to preschool.
[23:36] <anastasiamac> thumper: can't wait :D
[23:36] <wallyworld_> ok
[23:40] <thumper> menn0: http://reviews.vapour.ws/r/763/
[23:40] <thumper> 13 changed files  with 250 additions and 93 deletions.
[23:40] <thumper> never freakin easy, is it?
[23:50] <menn0> thumper: at least the diff still fits on one RB page :)
[23:50] <thumper> :)
[23:51] <thumper> I think I hit the same problem waigani did before
[23:51] <thumper> where I was wanting to add machines to an environment that isn't the state server one
[23:51] <thumper> that required the provider.Prepare in the factory
[23:52] <waigani> thumper: how did you solve that?
[23:52] <thumper> waigani: take a look at the review above
[23:53] <thumper> wallyworld_: nested errors.Trace call are preferable
[23:53] <thumper> otherwise you don't get a stack
[23:54] <thumper> that's the whole point
[23:54] <thumper> wallyworld_: there is no harm in returning 'return errors.Trace(err)' over 'return err'
[23:54] <thumper> wallyworld_: and I would say it is preferable to a bare return err
[23:55] <anastasiamac> thumper: would
[23:55] <wallyworld_> thumper: ok, wasn't sure of the preferred usage
[23:55] <anastasiamac> wouldn't u want to trace once and then annotate as u come up?
[23:55] <thumper> anastasiamac: you either trace or annotate or wrap
[23:55] <thumper> anastasiamac: if there is no useful context to add with an annotation, tracing is fine
[23:56] <wallyworld_> why not trace and then annotate at layer boundary
[23:56] <anastasiamac> thumper: what wallyworld_ said^^
[23:56] <thumper> wallyworld_: it depends where the useful context is
[23:56] <thumper> context isn't always at the boundary
[23:56] <wallyworld_> and i maintain tracing is not always necessary
[23:56] <thumper> wallyworld_: it is *never* necessary
[23:56] <thumper> wallyworld_: but it is very useful for debugging
[23:57] <thumper> and it doesn't hurt
[23:57] <thumper> so why not?
[23:57] <wallyworld_> can be, but not always needed
[23:57] <wallyworld_> code clutter
[23:57] <thumper> dude, it is *never* needed
[23:57]  * thumper challenges that
[23:57] <wallyworld_> you know what i mean
[23:58] <menn0> thumper: so, I'm fairly sure i've added machines to the non-initial env using the factory before
[23:58] <thumper> bah humbug, actions test failure  - the intermittent one I filed that bug for yesterday
[23:58] <menn0> thumper: so why is the prepare stuff req'd
[23:58] <menn0> ?
[23:58] <thumper> menn0: ah... because I'm using the dummy provider
[23:58] <thumper> not an unregistered 'someprovider'
[23:59] <jw4> thumper: sorry :)
[23:59] <menn0> thumper: cool.
[23:59] <thumper> dummy needs to be registered
[23:59] <thumper> sorry, prepared
[23:59] <menn0> thumper: i've had a quick look over your PR and it looks good. but I need to have a closer look once i've done the school run etc