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