| 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:22 |
| 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:26 |
| 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:44 |
| 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> | 01:47 |
| davecheney | thumper: ping | 02:02 |
| 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 | 02:58 |
| 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:06 |
| axw | wallyworld: when you have time, I've updated http://reviews.vapour.ws/r/2298/ to address your comments | 03:26 |
| wallyworld | looking | 03:27 |
| wallyworld | axw: lgtm, ty for adding clock implementation | 03:28 |
| axw | wallyworld: cool, thanks | 03:29 |
| 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 | 03:54 |
| axw | wallyworld: would it be reasonable to only support non-persistent volumes in the current version of the azure provider? | 05:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| wallyworld | so long as limitations are documented... | 05:39 |
| * thumper out | 05:39 | |
| dimitern | axw, (if still around), voidspace, mgz, can you please review this https://github.com/go-amz/amz/pull/60 ? | 06:44 |
| voidspace | dimitern: wow, that's big | 06:52 |
| voidspace | dimitern: I can take a look - but it will take a while | 06:52 |
| 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:53 |
| 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:54 |
| voidspace | git config --global core.excludesfile ~/.gitignore_global | 06:55 |
| dimitern | voidspace, good to know, thanks! :) | 07:01 |
| dimitern | voidspace, if it makes you feel better there are both vim and emacs rules in there :P | 07:02 |
| voidspace | dimitern: :-p | 07:02 |
| dimitern | jam, hey, 1:1? | 07:04 |
| jam | dimitern: omw | 07:07 |
| 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:54 |
| voidspace | kk | 07:56 |
| axw | wallyworld: https://code.launchpad.net/~axwalk/gwacl/gwacl-disks/+merge/267477 when you can, please | 08:07 |
| === dooferlad_ is now known as dooferlad | ||
| dimitern | voidspace, responded to your comments so far | 08:54 |
| voidspace | dimitern: the comment about extra methods makes sense | 08:57 |
| voidspace | dimitern: I should have checked! | 08:57 |
| dimitern | voidspace, np, the ec2test code is only slightly more familiar to me, but it's still confusing in some places | 08:58 |
| voidspace | making coffee | 08:59 |
| voidspace | brb | 08:59 |
| dimitern | voidspace, i'm ready | 09:37 |
| dimitern | voidspace, dooferlad, we need to sync up net-cli with master today I think | 09:37 |
| dimitern | it's been a whil | 09:38 |
| dimitern | while | 09:38 |
| voidspace | yep | 09:39 |
| 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:40 |
| voidspace | dimitern: sorry, omw | 09:41 |
| voidspace | dimitern: so the admin space, and the routing we need for that, *is* part of the MVP I think | 10:03 |
| 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:04 |
| TheMue | dimitern: you like the explicit interface more? fine, it indeed "feels" better ;) | 10:08 |
| 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:09 |
| dimitern | TheMue, cheers | 10:10 |
| 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:29 |
| voidspace | dimitern: structurally all sound, good work getting through all that | 10:30 |
| dimitern | voidspace, yes, numerous times | 10:30 |
| 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:31 |
| TheMue | dimitern: ok, good to know | 10:32 |
| voidspace | great work | 10:32 |
| dimitern | voidspace, thanks :) | 10:35 |
| dimitern | TheMue, reviewed | 10:53 |
| TheMue | dimitern: thanks | 10:55 |
| dimitern | mgz, are you about? | 10:56 |
| 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:28 |
| mgz | dimitern: hey | 11:45 |
| dimitern | mgz, hey, can you some time for a second review on https://github.com/go-amz/amz/pull/60 please? | 11:46 |
| 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:47 |
| dimitern | mgz, it is released | 11:49 |
| 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:50 |
| 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:51 |
| mgz | I'd hope they would, but most other uses of goamz I've seen are pretty limited | 11:52 |
| dimitern | mgz, not that I know of, but the compatibility promise should be respected when possible | 11:54 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| voidspace | dimitern: go for it | 12:21 |
| 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:22 |
| voidspace | dimitern: yep, I'm writing the method now | 12:28 |
| voidspace | dimitern: dammit | 12:42 |
| 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:43 |
| 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:50 |
| voidspace | dimitern: so all these changes can be done as part of the subnet ticket | 12:51 |
| voidspace | dimitern: otherwise this one balloons | 12:51 |
| dimitern | voidspace, yes, please - add SpaceName on subnetDoc | 12:53 |
| dimitern | voidspace, hmm | 12:54 |
| voidspace | dimitern: I can't just do that | 12:54 |
| dimitern | voidspace, why not? | 12:54 |
| 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:55 |
| 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:56 |
| voidspace | let me go read the model doc again for how subnets are added | 12:57 |
| perrito666 | morning | 12:57 |
| voidspace | perrito666: 'ning | 12:57 |
| 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:58 |
| 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 | 12:59 |
| 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:00 |
| dimitern | voidspace, well, what's clear is that you shouldn't be able to use a subnet without a space for deployments | 13:02 |
| dimitern | voidspace, so creating it with an empty space should be fine | 13:03 |
| 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:04 |
| voidspace | dimitern: so you need a space to create a subnet, but you need a subnet to create a space | 13:05 |
| dimitern | voidspace, this is a better point | 13:06 |
| dimitern | voidspace, but there should always be a pre-created "default" space | 13:06 |
| voidspace | dimitern: in which case you have to be able to move a subnet | 13:07 |
| 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:08 |
| dimitern | voidspace, we have juju space update CIDRs.. | 13:10 |
| voidspace | dimitern: that replaces *the whole list* | 13:10 |
| 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:11 |
| 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:14 |
| voidspace | dimitern: so subnet moving is an implicit part of space creation | 13:20 |
| dimitern | voidspace, I think so - when safe, that is unused | 13:39 |
| dimitern | jam, how do you feel about allowing the creation of "empty" spaces, but not allowing them as deployment targets until they have subnets? | 14:49 |
| TheMue | dimitern: instead of creating them with at least one initial subnet? | 15:01 |
| 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:08 |
| TheMue | dimitern: from UX perspective I agree, yes | 15:09 |
| TheMue | dimitern: it allows me to setup my network environment step by step | 15:10 |
| dimitern | TheMue, exactly | 15:10 |
| voidspace | dimitern: that sounds good to me | 15:12 |
| dimitern | dooferlad, voidspace, let's do it then, we could change it later, if at all needed | 15:14 |
| 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:15 |
| 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:18 |
| 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:19 |
| 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:30 |
| TheMue | voidspace: ok, thx for info | 15:31 |
| TheMue | voidspace: enjoy your evening | 15:31 |
| 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:45 |
| mgz | dooferlad: sure | 15:47 |
| === arosales_ is now known as arosales | ||
| 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:30 |
| TheMue | thx | 16:31 |
| dimitern | dooferlad, cheers, will have a look | 16:43 |
| 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:00 |
| mgz | dooferlad: are you still working? | 17:25 |
| 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:14 |
| perrito666 | wwitzel3: ericsnow I was thinking even developer notes | 19:15 |
| perrito666 | ericsnow: wwitzel3 working on gce storage | 19:15 |
| ericsnow | perrito666: ah | 19:15 |
| 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:16 |
| 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:17 |
| ericsnow | perrito666: haha | 19:18 |
| sinzui | ericsnow: do you have a moment to review http://reviews.vapour.ws/r/2339/ | 20:10 |
| sinzui | katco: Can you review ^ | 20:20 |
| katco | sinzui: you have 2 ship-its | 20:20 |
| katco | sinzui: now 3 | 20:20 |
| katco | :) | 20:20 |
| sinzui | thank you for using the cluex4 | 20:21 |
| perrito666 | bbl | 20:52 |
| wallyworld | alexisb: you able to make release standup? | 21:33 |
| alexisb | yes will be there soon | 21:34 |
| thumper | waigani: back in the standup? | 21:37 |
| waigani | thumper: yep | 21:38 |
| mup | Bug #1483421 opened: Can not install juju-local on precise Ubuntu <juju-core:New> <https://launchpad.net/bugs/1483421> | 21:59 |
| mup | Bug #1483421 changed: Can not install juju-local on precise Ubuntu <juju-core:New> <https://launchpad.net/bugs/1483421> | 22:05 |
| mup | Bug #1483421 opened: Can not install juju-local on precise Ubuntu <juju-core:New> <https://launchpad.net/bugs/1483421> | 22:11 |
| perrito666 | wallyworld: axw our talks sound a lot like the restaurant at the end of universe | 23:03 |
| axw | perrito666: I'm a bad nerd, I've never read hitchhiker's guide (I just know references...) | 23:04 |
| 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:22 |
| davechen1y | thumper: https://github.com/golang/go/issues/10628 | 23:47 |
| davechen1y | upstream issue for ppc | 23:47 |
| thumper | cheers | 23:50 |
| thumper | that is the sort of problem that I'm pleased others are looking into | 23:50 |
| * thumper runs to physio appt | 23:51 | |
| * thumper actually walks to the car... | 23:51 | |
| davechen1y | thumper: eh ? | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!