[01:22] thumper: can you please review https://github.com/juju/juju/pull/2888? apparently a RB review never got created [01:22] ack [01:22] axw: on some calls for a while, but I'll get to it [01:22] thumper: no rush, thank you [01:26] Bug #1483082 opened: provider/maas: volume source won't work for physical machines/disks

[01:26] Bug #1483083 opened: worker/storageprovisioner: unnecessary Attach just after a Create that creates attachment [01:44] Bug #1483082 changed: provider/maas: volume source won't work for physical machines/disks

[01:44] Bug #1483083 changed: worker/storageprovisioner: unnecessary Attach just after a Create that creates attachment [01:47] Bug #1483082 opened: provider/maas: volume source won't work for physical machines/disks

[01:47] Bug #1483083 opened: worker/storageprovisioner: unnecessary Attach just after a Create that creates attachment [01:47] Bug #1483086 opened: storage/provider: managedfs fails to create fs on full disks

[02:02] thumper: ping [02:58] wallyworld: can you please review this fairly trivial PR: https://github.com/juju/utils/pull/147 [02:58] sure [02:58] wallyworld: I bit the bullet and added a common clock package/interface [02:58] yay [03:06] wallyworld: btw I got disks working on azure, but I need to spend some more time figuring out the best way to represent volume IDs so we can attach/detach. as usual, the representation of resources is not like other providers... :) [03:06] sigh, love azure [03:06] also need to make some changes to prevent disks being destroyed when machines are destroyed [03:06] good news on the progress though :-) [03:26] wallyworld: when you have time, I've updated http://reviews.vapour.ws/r/2298/ to address your comments [03:27] looking [03:28] axw: lgtm, ty for adding clock implementation [03:29] wallyworld: cool, thanks [03:54] thumper: here's the majority of the state changes for the cross env watcher: http://reviews.vapour.ws/r/2328/ [03:54] thumper: there's still a few little bits coming but it's worth getting this reviewed and merged at this point [05:34] wallyworld: would it be reasonable to only support non-persistent volumes in the current version of the azure provider? [05:35] wallyworld: it'll avoid some complication around deleting VMs and possibly leaking disks [05:35] axw: i think so, we can deliver that and then see where we stnd wrt the new apis etc [05:36] cool, saves a bunch of work [05:36] although if we were to be able to list disks that have been allocated, we can then clean them up [05:36] we can do that as a stretch goal perhaps [05:38] wallyworld: we can, but the problem is more to do with OS disks. when you delete a VM you either delete *all* the attached disks or *none* of them. we can do it, but it's just a bit messy... so yes, stretch goal [05:39] so long as limitations are documented... [05:39] * thumper out [06:44] axw, (if still around), voidspace, mgz, can you please review this https://github.com/go-amz/amz/pull/60 ? [06:52] dimitern: wow, that's big [06:52] dimitern: I can take a look - but it will take a while [06:53] dimitern: the stuff in .gitignore - can't you get your git to globally ignore those [06:53] dimitern: rather than polluting the project with emacs [06:53] voidspace, thanks [06:53] :-) [06:53] voidspace, perhaps I can but don't know how :) [06:54] voidspace, that .gitignore is more or less the same as juju/juju/.gitignore [06:54] dimitern: heh, ok [06:54] dimitern: https://help.github.com/articles/ignoring-files/ [06:55] git config --global core.excludesfile ~/.gitignore_global [07:01] voidspace, good to know, thanks! :) [07:02] voidspace, if it makes you feel better there are both vim and emacs rules in there :P [07:02] dimitern: :-p [07:04] jam, hey, 1:1? [07:07] dimitern: omw [07:54] dimitern: I think I found a bug in srv.SetAvailabilityZones [07:54] dimitern: see the first comment [07:54] dimitern: still reading [07:54] voidspace, will do, in a call now [07:56] kk [08:07] wallyworld: https://code.launchpad.net/~axwalk/gwacl/gwacl-disks/+merge/267477 when you can, please === dooferlad_ is now known as dooferlad [08:54] voidspace, responded to your comments so far [08:57] dimitern: the comment about extra methods makes sense [08:57] dimitern: I should have checked! [08:58] voidspace, np, the ec2test code is only slightly more familiar to me, but it's still confusing in some places [08:59] making coffee [08:59] brb [09:37] voidspace, i'm ready [09:37] voidspace, dooferlad, we need to sync up net-cli with master today I think [09:38] it's been a whil [09:38] while [09:39] yep [09:40] dimitern: I'm in the hangout [09:40] voidspace, me too - which one are you in? [09:40] dimitern: hah [09:40] dimitern: I'm in the wrong one [09:40] :-) [09:40] :) [09:41] dimitern: sorry, omw [10:03] dimitern: so the admin space, and the routing we need for that, *is* part of the MVP I think [10:04] dimitern: for MAAS I think the user will need to create a real space and setup routing themselves [10:04] dimitern: as we don't control routing on MAAS [10:04] dimitern: for EC2 we can put the routing in place [10:08] dimitern: you like the explicit interface more? fine, it indeed "feels" better ;) [10:09] TheMue, yeah, I think it's better [10:09] dimitern: fine, and I found the error you talked about and will now introduce it [10:10] TheMue, cheers [10:29] dimitern: did you run the tests against live ec2? [10:29] dimitern: a couple more trivial comments added, nearing the end now [10:30] dimitern: structurally all sound, good work getting through all that [10:30] voidspace, yes, numerous times [10:31] voidspace, thanks, will respond soon [10:31] dimitern: right, done - no further comments [10:31] dimitern: LGTM, modulo those minor points [10:31] dimitern: hangout? [10:31] TheMue, RB somehow stopped working half way through the review, so I've sent my comments so far, but I'm still on it [10:31] dooferlad, omw [10:31] voidspace, thanks! [10:32] dimitern: ok, good to know [10:32] great work [10:35] voidspace, thanks :) [10:53] TheMue, reviewed [10:55] dimitern: thanks [10:56] mgz, are you about? [11:28] jam, voidspace, dooferlad, I've updated the model with comments and a few text changes. Most important new bits are on the comment about Discovering VPC support at bootstrap [11:45] dimitern: hey [11:46] mgz, hey, can you some time for a second review on https://github.com/go-amz/amz/pull/60 please? [11:47] ah, I saw the mail with that over the weekend, looks interesting [11:47] dimitern: v3 is not yet released? I'm not sure where we are on goamz versioning [11:49] mgz, it is released [11:50] mgz, that's building on top of it, v4-unstable is not released [11:50] dimitern: isn't renaming methods a compat break then? [11:50] mgz, I knew you'll say that :) [11:51] mgz, ok, I'll add an alias SetInitialAttributes for SetAccountAttributes [11:51] dimitern: I mean, it may well not be something we care about, do we know if anyone except juju uses ec2test? [11:52] I'd hope they would, but most other uses of goamz I've seen are pretty limited [11:54] mgz, not that I know of, but the compatibility promise should be respected when possible [12:06] dimitern: the space definition in state is the space name plus the list of associated subnet Ids [12:06] dimitern: the Space type needs a Subnets method that returns a slice of state.Subnet [12:07] dimitern: should I fetch those Subnets at the same time the Space is fetched [12:07] dimitern: or ok to fetch on demand when space.Subnets is called? [12:07] in terms of data integrity, it makes sense to fetch them at the same time [12:08] but then it's extra work that has to be done when a Space is constructed - and it may not be needed [12:08] so from that point of view it makes sense to only fetch them when needed [12:12] voidspace, well, during creation we should have all of the ids already, so it should be simple [12:12] dimitern: it is simple - it's the same either way [12:12] it's just where it's done [12:12] dimitern: so you're suggesting at creation time [12:13] voidspace, and since the subnet ids of a space cannot change underneath us, fetching the along with the space is ok I think [12:13] dimitern: why can't they change underneath us? [12:14] voidspace, but if you do that, and the list of ids is not updated on Refresh(), it should [12:14] dimitern: isn't there a race condition between fetching the space and adding / removing a subnet somewhere else? [12:14] dimitern: in which case doing at creation time is better as we're less likely to hit that [12:14] (that's what I meant by data integrity) [12:14] voidspace, spaces are a juju concept, unlike the instance status [12:14] dimitern: ah, right [12:15] voidspace, so the only way to change a space is to create or modify it [12:15] dimitern: but two clients could do that simultaneously :-) [12:15] these state objects should be ephemeral though [12:15] voidspace, that's true :) [12:16] voidspace, hmm what a asec [12:16] voidspace, wait even [12:16] voidspace, subnets have space name field, right? why should we store subnet ids in the space doc? [12:17] dimitern: so, Space.validate is already fetching them all [12:17] dimitern: well, true enough [12:17] dimitern: denormalisation? [12:17] dimitern: it's nice not to have to scan all subnets to find the ones associated with a space [12:17] dimitern: it means adding a subnet changes the Space definition too [12:18] voidspace, you're not scanning them - just Find({{space_name, "foo"}}).All() [12:18] dimitern: how do you think mongo finds them ;-) [12:18] voidspace, we'll add an index [12:19] voidspace, it should even be unique I think [12:19] dimitern: I can kill the subnetIds part of the Space doc [12:19] voidspace, yes, if it was added for convenience, it's not correct [12:20] voidspace, it should be a method returning ([]*state.Subnet, error) [12:20] voidspace, thanks for bringing this up btw! [12:20] voidspace, I have to look at what's our state model so far for spaces and subnets [12:20] np, of course [12:21] dimitern: go for it [12:22] voidspace, I remember adding something like BackingSpace.SubnetIds, but I fully intended in *state.Space to use a method for that, not a slice on the doc [12:28] dimitern: yep, I'm writing the method now [12:42] dimitern: dammit [12:43] dimitern: subnet doesn't *yet* have a SpaceName [12:43] dimitern: I guess I have to add it [12:43] dimitern: there's another card for subnet changes, so I'll just add the field for now [12:50] dimitern: *sigh*, and because there is no SpaceName field on Subnet, the Space.SubnetIds is currently *the canonical* list of subnets for the Space [12:50] AddSpace takes a list of subnets [12:51] dimitern: so all these changes can be done as part of the subnet ticket [12:51] dimitern: otherwise this one balloons [12:53] voidspace, yes, please - add SpaceName on subnetDoc [12:54] voidspace, hmm [12:54] dimitern: I can't just do that [12:54] voidspace, why not? [12:55] well, I can [12:55] it's just work that I think belongs to the subnets card we already have [12:55] AddSpace takes a slice of subnet ids [12:55] so AddSpace would then have to update the subnets too [12:56] so it becomes a lot more work that I think we already have a card for [12:56] voidspace, that's correct, but it seems that and your card are closely related [12:56] well, they are [12:57] let me go read the model doc again for how subnets are added [12:57] morning [12:57] perrito666: 'ning [12:58] voidspace, yes, and AddSpace should update the subnets docs, in a transaction, but it's tricky as it can change in the mean time, so think about using txn-revno [12:58] voidspace, also, as ref counting lands, we should not change the space of a subnet with refcount > 0 [12:59] dimitern: that definitely is in the other ticket [12:59] dimitern: as ref counting belongs there [12:59] dimitern: so, "juju create subnet " doesn't *require* a space name does it? [12:59] dimitern: we have a chicken and egg problem [13:00] dimitern: creating a space requires a subnet [13:00] dimitern: but if you create a subnet you either specify a space, or it get puts in the default one [13:00] dimitern: so I assume it must be possible to move a subnet from default space to another space, right? [13:00] (unless refcount > 0) [13:02] voidspace, well, what's clear is that you shouldn't be able to use a subnet without a space for deployments [13:03] voidspace, so creating it with an empty space should be fine [13:04] voidspace, what a sec [13:04] voidspace, it's "$ juju subnet create " actually [13:04] voidspace, so both the space and the zone are required when creating (or adding) a subnet [13:04] dimitern: ok - but you need a subnet (at least one) to create a space [13:05] dimitern: so you need a space to create a subnet, but you need a subnet to create a space [13:06] voidspace, this is a better point [13:06] voidspace, but there should always be a pre-created "default" space [13:07] dimitern: in which case you have to be able to move a subnet [13:08] dimitern: which is the cli command to move a subnet? [13:08] well, not quite [13:08] creating the new space with the existing subnet moves it [13:08] dimitern: I added a couple of comments to the model doc clarifying (slightly) about the moving of subnets [13:10] voidspace, we have juju space update CIDRs.. [13:10] dimitern: that replaces *the whole list* [13:11] the normal use case would be to add or remove a single one I expect [13:11] voidspace, and there's the new space creation moving (unused) subnets to it, yes [13:11] having to specify all of them is a nuisance and an invitation for errors [13:11] but ah well] [13:11] *well [13:14] voidspace, the update is intended only when you want to change all of them [13:14] voidspace, thanks for your feedback and comments on the doc [13:20] dimitern: so subnet moving is an implicit part of space creation [13:39] voidspace, I think so - when safe, that is unused [14:49] jam, how do you feel about allowing the creation of "empty" spaces, but not allowing them as deployment targets until they have subnets? [15:01] dimitern: instead of creating them with at least one initial subnet? [15:08] TheMue, yes, because it's convenient to create a few spaces first, then either create or add existing subnets to them; also not allowing this *force* you to create or add subnets to the "default" space first, then move them [15:09] dimitern: from UX perspective I agree, yes [15:10] dimitern: it allows me to setup my network environment step by step [15:10] TheMue, exactly [15:12] dimitern: that sounds good to me [15:14] dooferlad, voidspace, let's do it then, we could change it later, if at all needed [15:15] I'll update the docs to reflect this and add comments [15:15] dimitern: deploying to a space with no subnets will raise an error (needs adding to the doc) [15:18] voidspace, yeah - it will come naturally as it happens on StartInstance, and there we need all subnets anyway to do AZ distribution [15:18] voidspace: and in case of only one subnet this is the default? or does it always has to be specified explicitely? [15:19] voidspace, it's still OK though, I think to allow empty spaces in constraints, until they're actually used [15:19] voidspace, as constraints are eval'ed each time [15:30] dimitern: sounds good [15:30] TheMue: you don't have to specify a subnet, and if there is only one then it will be used [15:30] TheMue: in fact you don't specify a subnet usually, you specify the space [15:30] I gotta go [15:30] see you all tomorrow [15:31] voidspace: ok, thx for info [15:31] voidspace: enjoy your evening [15:45] mgz: hi, could you take a look at https://code.launchpad.net/~dooferlad/juju-ci-tools/juju-ci-tools-addressable-containers/+merge/267494 please? [15:47] dooferlad: sure === arosales_ is now known as arosales [16:30] dimitern, TheMue: EOD for me. I have a couple of review requests up that are both small (the merge trunk one looks big, but in reality I only changed a couple of lines) [16:30] http://reviews.vapour.ws/r/2333/ [16:30] dooferlad: will have a look [16:30] http://reviews.vapour.ws/r/2335/ [16:30] TheMue: thanks! [16:30] dooferlad: enjoy your evening [16:30] and you [16:31] thx [16:43] dooferlad, cheers, will have a look [17:00] Can I get a couple quick reviews? They're both just cherry-picks of already approved PRs: http://reviews.vapour.ws/r/2336/ http://reviews.vapour.ws/r/2334/ [17:25] dooferlad: are you still working? [19:14] hey wwitzel3 ericsnow is there a spec for gce provider? [19:14] perrito666: not really [19:14] :( [19:14] like an internal spec? we have a compatability spreadsheet [19:14] perrito666: what's up? [19:15] wwitzel3: ericsnow I was thinking even developer notes [19:15] ericsnow: wwitzel3 working on gce storage [19:15] perrito666: ah [19:16] ericsnow: wwitzel3 just looking for some reference, ill read the code and gce docs [19:16] perrito666: we didn't document the implementation in great detail, if that's what you mean [19:17] perrito666: that's you best bet (and ping either of us with questions) [19:17] i will, thank you :) [19:17] perrito666: we tried to write it in an obvious way :) [19:17] perrito666: yeah, if you run in to any sticking points don't hesitate [19:17] ericsnow: I do recall that yea :) and it has been praised for clarity so I am not worried [19:18] perrito666: haha [20:10] ericsnow: do you have a moment to review http://reviews.vapour.ws/r/2339/ [20:20] katco: Can you review ^ [20:20] sinzui: you have 2 ship-its [20:20] sinzui: now 3 [20:20] :) [20:21] thank you for using the cluex4 [20:52] bbl [21:33] alexisb: you able to make release standup? [21:34] yes will be there soon [21:37] waigani: back in the standup? [21:38] thumper: yep [21:59] Bug #1483421 opened: Can not install juju-local on precise Ubuntu [22:05] Bug #1483421 changed: Can not install juju-local on precise Ubuntu [22:11] Bug #1483421 opened: Can not install juju-local on precise Ubuntu [23:03] wallyworld: axw our talks sound a lot like the restaurant at the end of universe [23:04] perrito666: I'm a bad nerd, I've never read hitchhiker's guide (I just know references...) [23:22] axw: well by that part the good parts are almost over, but the conversations inside it look a lot like speaking to australians being in south america [23:22] by all, see you tomorrow [23:47] thumper: https://github.com/golang/go/issues/10628 [23:47] upstream issue for ppc [23:50] cheers [23:50] that is the sort of problem that I'm pleased others are looking into [23:51] * thumper runs to physio appt [23:51] * thumper actually walks to the car... [23:55] thumper: eh ?