[00:04] * thumper sighs [00:04] tests failed because other people landed code... [00:04] * thumper merges and updates [02:19] wallyworld__: actually, before tmpfs it would be more useful to have "loop" [02:20] wallyworld__: so we have the fallback case covered [02:23] axw: yes, i was hoping we'd churn out tmpfs, loop more or less together [02:23] but loop first, i agree === kadams54 is now known as kadams54-away [03:36] thumper, wallyworld__ : holy crap there's lots of crazy duplication of test helpers in state [03:36] :) [03:36] thumper, wallyworld__ : fixing a bunch of it now [03:36] cheers [03:36] \o/ [03:37] 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] wallyworld__: http://reviews.vapour.ws/r/757/ [03:48] looking === kadams54-away is now known as kadams54 [04:15] menn0: I'm getting there with the tests but I have one leaving a dirty socket around [04:15] a mongo connection [04:15] it is definitely the test where we have a different connection from state [04:15] but I can see that my resource cleanup is getting called [04:15] so not sure where [04:16] if you are good with it, perhaps we could go through it in the morning to see WTF is going on? [04:23] thumper: happy to [04:28] menn0: good, I think I've looked at it too long this afternoon, pushing up current [04:29] thumper: this state testing refactoring is going really well btw [04:29] thumper: tons of lines being removed [04:29] cool [04:32] night folks [04:33] wallyworld__: mind seeing my comments before I land? [04:34] axw: yah, looking now [04:44] axw: commented, not sure if you wsnt to discuss [04:47] 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] 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] wallyworld: not sure where you saw up to... [04:54] 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] 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] axw: sigh, freenode hates me, keeps kicking me off :-( [04:57] 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] axw: afk, bbiab [04:59] 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] wallyworld: let me know when you're back [05:30] -_- [05:34] axw: yeah, that's how i think of it too. Disk though gives the opposite connotation. gad i hate naming things [05:37] wallyworld: it's really "volume" and "attachment", but that doesn't marry with discovered devices [05:42] 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] i *think* that may remove the current ambiguity? [05:44] 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] wallyworld: I'm fine with calling it Volume, though I don't see much of a difference [05:48] except that it might be a little clearer that it's not necessarily a physical or dedicated disk [05:48] 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] yes [05:49] that's where i'm coming from [05:49] wallyworld: fair enough. I'll change it. I'll need to update juju/names too, but I'll do that later [06:05] wallyworld: PTAL [06:06] sure [06:09] axw: thanks, i think the naming is clearer now. well to me it is :-) [06:09] wallyworld: cool [06:09] wallyworld: you might like this: http://reviews.vapour.ws/r/759/ [06:10] looking [06:10] oooh refactoring [06:10] 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] such as detachability, persistence, etc. [06:10] wallyworld: see what happens when you make a single review comment about extracting some test helpers out [06:10] axw: yep, sounds good [06:10] wallyworld: I then went and noticed all the awful duplication and felt the need to fix it [06:10] menn0: \o/ thank you [06:11] axw: short term goal is to get collaboration possible, i think this branch enables that [06:12] wallyworld: dealing with kids now so no rush [06:12] wallyworld: yep. I will land and get back to juju deploy [06:12] menn0: ok, will finish a few things and then look, really appreciate the work to do this [06:13] 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] morning all [07:01] dimitern: morning :D [07:02] anastasiamac, o/ [07:04] anastasiamac, nice new facade btw :) [07:08] wallyworld_: thanks for the review. i'll add that comment and then get it in. [07:08] awesome [07:25] dimitern: thnx :) [07:27] axw: got a few minutes? hangout in our 1:1? [07:27] wallyworld__: sure [07:32] morning dimitern [07:32] jam1, morning, sorry - omw :) [07:32] just grabbing a coffee, but I joined the hangout === jam2 is now known as jam1 [08:04] wallyworld__: are you there still? [08:04] can't hear you on hangouts... === mthaddon` is now known as mthaddon [09:10] dimitern: so, system is started [09:11] TheMue, great! i'll be in the hangout shortly [09:11] dimitern: fine [10:24] dimitern: I'll be back in 5 minutes as well [10:27] voidspace, ok [10:30] dimitern: and back... [11:03] voidspace, I've reviewed your subnets PR btw === urulama_ is now known as urulama [12:14] dimitern: you've suggested using a string set, which I would *love* [12:14] dimitern: which packge is that from [12:14] dimitern: import "set" does not work... [12:19] voidspace, it's in juju/utils/set IIRC [12:19] ah.... [12:19] *great* [12:22] dimitern: ah, I can't use the set, because I'm using the underlying value (true/false) to carry meaning [12:22] dimitern: (did we actually find the subnet) [12:26] morning to the few of you who are here [12:27] perrito666: morning [12:34] voidspace, well, you could construct the set initially with all ids, then remove ones that are not found.. [12:34] voidspace, but i'll leave it up to you [12:35] well, I *can't* remove the ones not found [12:35] I use the set to track *found* ones :-) [12:35] knowing which ones I haven't found is the problem I'm trying to solve :-) [12:36] but I've switched the map to string[bool] as it involves less casts [12:36] one instead of three [12:36] dimitern: I've hit $$merge$$ and am onto the next task [12:40] voidspace, ok, fair enough [12:40] voidspace, cheers! :) [12:50] 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] fwereade: sweeeeeeet 666 additions :p [13:15] that is your last patch [13:15] perrito666, lol, awesome [13:15] * perrito666 imagines fwereade adding blank lines to get there [13:16] perrito666, if I'd noticed I was near I probably would have done, yeah ;p [14:55] anastasiamac: thanks, fixed [15:06] dimitern: ping [15:06] voidspace, pong [15:07] dimitern: should I work on (first) either a) NetworkInterfaces for MaaS [15:07] dimitern: or b) filling in the missing bits of the ec2 implementation? [15:07] or c) it doesn't matter which order... [15:07] if b) I have some follow up questions :-D [15:08] voidspace, well :) [15:08] voidspace, i'm not quite done with the ec2test filtering for NICs, so I suppose a) is best for now [15:08] ... [15:08] ah, cool [15:08] that's what I wanted to hear... [15:08] dimitern: thanks [15:09] voidspace, :) [15:09] voidspace, and I think splitting up the ec2 and maas implementations in separate PRs is good [15:10] dimitern: yeah [15:12] parsing lshw, yay! [15:13] voidspace, :/ I sympathize [15:14] dimitern: I created separate cards for EC2/MaaS implementation [15:14] dimitern: and assigned MaaS to me and EC2 to you [15:14] doesn't have to stay like that but will do for now [15:16] voidspace, thanks! [15:18] although, extractInterfaces pretty much does it all already [15:18] might need to extend it a bit, but not much [15:25] voidspace, while doing that would you mind adding ProviderSubnetId network.Id to InterfaceInfo ? [15:26] dimitern: ok [15:26] dimitern: ProviderSubnetId instead of SubnetId ? [15:26] voidspace, and rephrase ProviderId's doc comment to clarify it's the NIC id [15:26] ok [15:26] voidspace, yeah, let's make it obvious [15:26] okeydokey [15:26] voidspace, cheers [15:29] dimitern: looks like I'll be visiting friends on the Monday and Tuesday of our sprint week [15:29] dimitern: so Wednesday for team meal would be ideal please :-) [15:30] voidspace, sure, will keep that in mind [15:30] dimitern: thanks, sorry to be a pain [15:30] voidspace, no trouble at all :) [15:30] dimitern: I don't get down to London often, so have a couple of friends keen to see me [15:30] dimitern: and I was already booked for a meal there on Thursday! [15:31] voidspace, of course, sgtm [15:38] * TheMue will also visit a friend, but not date yet fixed ;) [15:39] TheMue: don't make it Wednesday please :-) [15:40] voidspace: hehe, sure, just seen [15:40] cool [15:40] otherwise we have a dilemna [15:40] and dimitern has to decide who he loves more ;-) [15:40] *rofl* [15:40] :D [15:42] 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] TheMue: we add new Environ methods ad-hoc as we need them... [15:42] TheMue: the current "entry point" for new networking stuff is the SupportAddressAllocation method [15:43] TheMue: if a provider returns True for this then it must support all the new networking methods [15:43] TheMue: this is only true for MaaS and EC2 currently [15:43] voidspace: ok [15:43] TheMue: the other providers return false for SupportAddressAllocation and errors.NotImplemented for the other new networking methods [15:43] voidspace: so do those methods have an own interface and where needed we we do a type assertion? [15:44] TheMue: they *don't*, they *could* [15:44] voidspace: or do the others have to implement "empty" methods? [15:44] TheMue: they're just part of the Environ interface [15:44] so yes, at the moment all providers implement them [15:45] a separate interface that extends Environ would probably be clearer [15:45] voidspace: so all providers have to provide them, even w/o address allocation? [15:45] yep [15:45] you can see that they do [15:45] e.g. for NetworkInterfaces Subnets (etc) [15:45] voidspace: yeah, then I would prefer one or more extra interfaces [15:45] 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] TheMue: that would be a great initial contribution :-) [15:46] voidspace: hah [15:46] TheMue: or did you mean you would prefer it if someone else did it? [15:46] in which case, me too! :-) [15:46] TheMue: just teasing, but yes I agree in principle [15:47] voidspace: no, would be fine to me, so I'm forced to take a look at each networking method [15:47] go for it [15:47] would be quite easy, and then you'd see the new methods [15:47] dimitern: how is p9 doing it? [15:47] AllocateAddress and ReleaseAddress too [15:47] I believe [15:47] TheMue, I have no idea frankly :) [15:47] dimitern: *rofl* [15:48] dimitern: what I once liked is the idea of "everything is a device" [15:49] TheMue, I do like this - nice and polymorphic, but alas.. [18:06] voidspace, ping [18:07] voidspace, have a look at https://github.com/go-amz/amz/pull/20 later if you have time [18:07] dimitern: ok [18:07] dimitern: not long before I leave, but I can take a look [18:07] wallyworld___, axw, katco , rogpeppe, can any of you please review the above PR for goamz that improves ec2test server? ^^ [18:08] dimitern: cool, nice work [18:08] voidspace, cheers! the important part is that now we can filter NICs by "attachment.instance-id" [18:08] 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] rogpeppe: hey, I don't suppose you can remember the name of that restaurant we went to in London? [18:09] rogpeppe: we're back in London next week... [18:09] rogpeppe, np, I'm just mass-pinging in the hope someone might have a look :) [18:09] voidspace: hmm, it was nice, wasn't it? [18:09] voidspace: i'm in london now... [18:09] rogpeppe: yep... [18:09] voidspace: no, sorry, i can't remember at all [18:09] rogpeppe: heh, cool :-) [18:09] never mind, shame [18:09] voidspace: we probably found it through tripadvisor [18:10] ah, I'll try searching for restaurants near Blue Fin [18:10] there's probably only about 200 to check in that radius... [18:10] dimitern: from a quick skim, it looks reasonable [18:11] voidspace: istr it might've been north of the river [18:12] ah yes, I vaguely remember crossing the river [18:16] I'm signing off for the day [18:16] time to go jogging [18:16] g'night all [18:18] rogpeppe, cheers === robbiew1 is now known as robbiew [20:00] jw4: are you working or taking the day off? [20:06] thumper: working, but I was just about to break for the gym [20:06] jw4: just wanted to make sure you were aware: https://bugs.launchpad.net/juju-core/+bug/1412292 [20:06] Bug #1412292: Intermittent test failure in ActionSuite.TestActionsWatcherEmitsInitialChanges

[20:07] 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] coolio [22:11] how do we set feature flags ? [22:14] looks like via env var on client [22:28] 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] hazmat: no, it isn't hooked up [22:30] and yes, feature flags are set by env var [22:30] thumper, ah, that would explain it [22:30] JUJU_DEV_FEATURE_FLAGS valid values storage,actions [22:30] yeah [22:30] hazmat: I have a branch, but got derailed [22:30] found two kinda critical things that were more important [22:30] and now I'm banging my head against the fucking dummy provider [22:31] 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] I do feel like we are getting close though [22:31] 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] should be well hooked up before then :) [22:54] ah mah gaad [22:54] finally have the test failing the way I expect [22:54] what a freaking mission [22:55] * thumper must remember to reset the branch before proposing to remove expletives [22:57] so... apart from that panic, we're good [22:57] * thumper grumbles [22:58] meh [23:04] * thumper head desks [23:20] fark!!!!! [23:21] * thumper wonders if he has broken anything else [23:21] thumper: feeling like colombian revolution? [23:21] perrito666: I don't get it [23:21] thumper: farc is the name the colombian "revolutionary" group that drives narcotrafic calls them selves [23:22] ah [23:22] iirc fuerzas armadas revolucionarias de colombia [23:22] no I was mentally bitching about why the common.Resources didn't stop things in the reverse order they were registered [23:22] but rather randomly [23:23] which ment my pinger died because the state connection was closed already [23:23] by design? [23:23] by not caring [23:23] now they do work that way [23:23] before there wasn't any dependency between resources [23:23] now there can be [23:23] before it didn't matter [23:23] now it does [23:27] changes, i hate those [23:29] menn0: I think I have this ready to go now [23:29] menn0: all the tests are running and passing except for one "bad record MAC: [23:31] thumper: orrsum [23:33] menn0: although to get it fully working, there is more work needed in the apiserver code [23:33] but for the other handlers [23:33] like tools, charms, iamges, debuglog [23:35] wallyworld_: i've updated http://reviews.vapour.ws/r/754/ in response to your review comments. [23:35] thumper: what's worng with charms handlers?.. [23:35] menn0: ty, looking [23:35] wallyworld_: there's a couple of things that i need your feedback on [23:35] anastasiamac: they don't support the correct state connectino for non-state server environments [23:35] thumper: :( [23:36] thumper: what's correct state connection look like? [23:36] I'll fix it. All the workers will need the same fix [23:36] wallyworld_: no rush. I'm about to have lunch and take Amelia to preschool. [23:36] thumper: can't wait :D [23:36] ok [23:40] menn0: http://reviews.vapour.ws/r/763/ [23:40] 13 changed files with 250 additions and 93 deletions. [23:40] never freakin easy, is it? [23:50] thumper: at least the diff still fits on one RB page :) [23:50] :) [23:51] I think I hit the same problem waigani did before [23:51] where I was wanting to add machines to an environment that isn't the state server one [23:51] that required the provider.Prepare in the factory [23:52] thumper: how did you solve that? [23:52] waigani: take a look at the review above [23:53] wallyworld_: nested errors.Trace call are preferable [23:53] otherwise you don't get a stack [23:54] that's the whole point [23:54] wallyworld_: there is no harm in returning 'return errors.Trace(err)' over 'return err' [23:54] wallyworld_: and I would say it is preferable to a bare return err [23:55] thumper: would [23:55] thumper: ok, wasn't sure of the preferred usage [23:55] wouldn't u want to trace once and then annotate as u come up? [23:55] anastasiamac: you either trace or annotate or wrap [23:55] anastasiamac: if there is no useful context to add with an annotation, tracing is fine [23:56] why not trace and then annotate at layer boundary [23:56] thumper: what wallyworld_ said^^ [23:56] wallyworld_: it depends where the useful context is [23:56] context isn't always at the boundary [23:56] and i maintain tracing is not always necessary [23:56] wallyworld_: it is *never* necessary [23:56] wallyworld_: but it is very useful for debugging [23:57] and it doesn't hurt [23:57] so why not? [23:57] can be, but not always needed [23:57] code clutter [23:57] dude, it is *never* needed [23:57] * thumper challenges that [23:57] you know what i mean [23:58] thumper: so, I'm fairly sure i've added machines to the non-initial env using the factory before [23:58] bah humbug, actions test failure - the intermittent one I filed that bug for yesterday [23:58] thumper: so why is the prepare stuff req'd [23:58] ? [23:58] menn0: ah... because I'm using the dummy provider [23:58] not an unregistered 'someprovider' [23:59] thumper: sorry :) [23:59] thumper: cool. [23:59] dummy needs to be registered [23:59] sorry, prepared [23:59] 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