[00:38] wallyworld: spice bar is pretty nice [00:38] mwhudson: i think i saw that, along the esplanade? [00:38] yeah, at the north end of the main drag iirc [00:39] not cheap, mind [00:39] cool, will check it out, there's a lot of choices, but everything closes at 9 or 9:30 [00:39] That's because we have to get up early to get out while the surfing's good [00:40] true, i woke up today at 5:30 and was sorely tempted [00:40] * blahdeblah was up at 4:50 today for a run [00:40] australia outside of the capital cities is bascially a wasteland, right? [00:40] :-) [00:40] pretty much :-) [00:40] mwhudson: If you like nightclubs and doof doof music, yes [00:40] i actually really liked mooloolaba [00:41] (we holidayed there a year and a bit ago) [00:41] * blahdeblah prefers more active passtimes like surfing, running, fishing [00:42] i also sprinted there with the bzr team but that was years ago now [00:55] mwhudson: that was with ian clatworthy? [01:17] sinzui, mgz, cherylj: the current merge run appears to be wedged running get_ami.py [01:17] menn0: I can help [01:19] sinzui: thank you [01:20] menn0: killed and requeued. I don't think anyone needs to twiddle the mp that was stalled [01:47] wallyworld: social director approval received - sign me up! :-) [01:48] blahdeblah: awesome, to make it easier for us at the sprint, i'm just going to find a place along moolooabah esplanade that can accommodate the numbers [01:48] no worries - you know where to find me [01:49] there's an italian place i'll ask today [01:49] indded i do [01:49] wallyworld: yes [01:50] mwhudson: yeah, that would have been when ian was sick and couldn't travel :-( [01:50] yep [01:50] around 2007 maybe [01:51] how goes wallyworld [01:51] 2009 i think [01:51] rick_h_: living the dream [01:51] wallyworld: wheeeee :) [01:51] 2007 was before i moved to the southern hemisphere :-) [01:51] lol, wheeee indeed [01:51] mwhudson: ah yeah, 2009 sounds right [02:11] axw_: could you take a look at http://reviews.vapour.ws/r/3392/ ? [03:14] waigani: I think your merge is wedged. it's been running for 45 mins when they normally take about 20 mins [03:15] really? shit :/ [03:16] menn0: the console output is moving ... [03:18] waigani: never mind. it just finished with a failure. I mixed up my times. it was about 20 mins. [03:18] menn0: the one before panicked with no reachable servers. Maybe you're referring to that one? [03:18] waigani: I was looking at multiple jobs at the same time and must have mixed up the time stamps [03:18] sorry for the confusions [03:19] menn0: ah right. np. I'll just merge that one again as it doesn't look like it was me. [03:19] menn0: unless you want to get something in? [03:19] menn0: happy to merge mine after ;) [03:20] waigani: mine's merging now. your failure is the occasional mongodb segfault we sometimes see. I've had that today as well. [03:20] webscale [03:20] lol [05:16] axw_: http://reviews.vapour.ws/r/3395/ === ashipika1 is now known as ashipika === prabhugs is now known as prabhugs_ === prabhugs_ is now known as prabhugs [09:01] dimitern: I see your branch landed [09:01] dimitern: $$suckerpunch$$ ! [09:09] dooferlad, ping. I'm back. [09:09] voidspace, hey, yeah :) finally - just replied to your mail as well [09:10] dimitern: the PR you landed on maas-spaces doesn't pass the pre-push checks by the way [09:10] dimitern: or at least I had a bug after I rebased which I had to fix [09:10] frobware: not quite ready [09:10] I haven't seen the email yet [09:10] dimitern: just grabbing coffee and I'll see it [09:10] dooferlad, ok [09:10] voidspace, oh? what issues are you seeing? [09:14] dimitern: line 1824 of provider/maas/environ.go [09:14] dimitern: two extra parameters to the Debugf call but only one %v [09:20] dimitern: next issue: error creating subnet Zones cannot be discovered from the provider and must be set [09:21] frobware: ok, lets try now. The people I am trying to call are engaged. [09:21] dooferlad, "but your call is important to us" [09:21] voidspace, oops sorry :/ I should've run go vet [09:21] voidspace, that's known - for now the workaround is to pass the default zone explicitly [09:22] ok [09:22] dimitern: don't you have the pre-push checks set for git? [09:22] dimitern: I have them set, but if I need to push code that doesn't pass you can just use --no-verify [09:22] voidspace, but I guess the better solution will be to just not require a zone for maas subnets (they're orthogonal) [09:22] dimitern: yep [09:23] dimitern: what do I use for the default zone? [09:23] voidspace, it used to be a pain on the old laptop as everything (or so it seems) was so slow, so I didn't use the pre-push scripts [09:24] heh [09:24] voidspace, well, maas provider does support AvailabilityZones() already [09:25] yeah, which is why I'm surpised by this error [09:25] voidspace, just doesn't provide subnet-to-zone(s) mapping, like we have in ec2 [09:25] ah [09:26] is there an example of code setting the default zone I can look at [09:26] this was mostly needed for ec2, to populate SubnetsToZones and use zone+subnetID when distributing units of a service across zones, when spaces constraints are given [09:27] dimitern: what do I pass for the default zone? [09:28] well, you *could* just hard code it to "default" I guess, but ultimately what I think is needed is just to make AllZones() in apiserver/subnets work with MAAS [09:29] dimitern: right, thanks [09:35] voidspace, looking at the code, the subnets facade tries to get all zones from state first, then the provider and caches them [09:36] dimitern: right, that's your code :-) [09:36] dimitern: you mean that call might be failing? [09:36] I don't have any zones set on my maas [09:37] voidspace, :) yeah, unhelpfully complicated, but I see a simple solution [09:37] voidspace, you always have at least 1 zone - "default" (cannot be deleted) [09:38] dimitern: I've hardcoded default for now and am trying it [09:38] but to land in production the zones need to be right I think [09:38] voidspace, I think all that's needed (and should work with providers like maas and openstack, which don't constrain subnets to specific zones)... [09:40] voidspace, ...is just to assume "all zones were explicitly given for each subnet we're about to add" i.e. as if $ juju subnet add CIDR space zone1 zone2 zone3 ... was called [09:41] dimitern: we can talk about it later [09:41] dimitern: with that change subnets import too [09:41] voidspace, and we get the already-cached list of zones and pass them instead of subnetInfo.AvailabilityZones as a first argument of validateZones in addOneSubnet (when the former is empty) [09:41] \o/ [09:42] dimitern: so put each subnet in all zones? [09:42] s/former/subnetInfo.AZs/ [09:43] cool [09:43] dimitern: if you try my branch now it might work for you... :-) [09:43] if not you can tell me what fails [09:43] voidspace, yeah, because that's what it comes down to - since provider does not impose specific constraints which zones a subnet can span, any subnet can span all zones, and it's up to juju to decide which exactly (i.e. we impose the constraint in order to be able to do unit distribution) [09:43] dimitern: I have to go now, back in a bit [09:43] voidspace, well do, cheers [09:44] still a fair bit to do in the branch (tests!) but the happy path works... [09:45] \o/ [10:01] dooferlad, voidspace frobware, otp will join in 3m [10:02] dimitern: nobody here at the moment anyway... [10:40] back [10:48] voidspace, how did it go? [10:58] frobware: hah, very cute [10:58] lovely, a bit cute overdose for me but still lovely [10:58] Irina did some of the actions, not sure she actually sang though [11:11] frobware, so it turned out it the existing code already worked with subdomain.domain.tld sort of hostnames coming from MAAS [11:11] frobware, but adding a few tests proves it and acts also as documentation/examples [11:13] frobware, and it did work because SplitN(s, ".", 2) does exactly what it says on the godoc -> return up to 2 elements, second one always containing the unsplitted remainder of s [11:15] dimitern, good to know. sorry for the noise. :) [11:15] frobware, np :) I wasn't sure off hand, so better check [11:31] voidspace, I just verified the tip of your maas-spaces-networking-api3 branch works perfectly on my 1.9RC4 maas - spaces & subnets imported as expected. deployment with spaces constraints works! [11:32] I only commented a few lines in my test script - http://paste.ubuntu.com/14048778/ [11:32] * dimitern \o/ it's coming together now! :) [11:33] dimitern, could you put "~/Documents/spaces-demo/spaces-demo-bundle-simplified.yaml [11:33] watch juju status --format tabular [11:33] " in the pastebin? [11:34] dimitern, excusing my bad cut&paste [11:34] frobware, sure - http://paste.ubuntu.com/14048794/ [11:35] dimitern, thx [11:36] here's some more: $ juju status (http://paste.ubuntu.com/14048801/); $ juju space list (http://paste.ubuntu.com/14048803/) [11:38] dimitern: awesome!!! [11:38] dimitern: as I work on it I'll try and keep that branch in a useable state [11:40] voidspace, tyvm [11:42] voidspace, trying a similar script + bundle might help with that fwiw [11:45] dimitern: right, I only have two spaces and two subnets in this setup [11:45] dimitern: so I'll have to put together a simple bundle [12:02] dimitern, standup HO? [12:03] frobware, omw - 2m [12:59] dooferlad, ping [13:00] dooferlad, whenever you're ready we try pairing on the uniter api [13:23] dooferlad, voidspace: can somebody drive-by http://reviews.vapour.ws/r/3388/ [13:23] dooferlad, voidspace, dimitern: I did some light testing on maas 1.8 and 1.9 and saw the new node names in the UI [13:24] dooferlad, voidspace: this needs to land today so taking a look would be appreciated. [13:24] frobware, great! thanks for confirming [13:25] dimitern, did you try 1.7 at all? [13:27] frobware, no, I didn't - we should at least check it once I guess; it shouldn't matter as 1.7 doesn't have devices api and none of that code around hostnames will be used [13:34] dimitern, "failed to prepare container "0/lxc/0" network config: failed to allocate an address for "0/lxc/0": address allocation not supported" [13:34] dimitern, that's from 1.7 [13:35] frobware, where do you see that? [13:35] dimitern, let's HO [13:35] if it's just in the logs, that's fine for 1.7 - no regression at least [13:36] dimitern, OK [13:36] frobware, I'd be worried if it caused the provisioning to fail [13:36] frobware, it's not worthy of a HO I think ,but I can join if you like [13:36] dimitern, agreed [13:37] dimitern, so my sanity test on 1.7 was add-machine lxc:0 and I can juju ssh 0/lxc/0 [13:38] frobware, and status shows the container as "started" ? [13:38] dimitern, yep [13:38] frobware, it's fine then - it works (not worse than before) [14:14] dimitern: you have a review [14:19] dimitern: sorry that I didn't get back to you earlier. Today has been like a slapstick comedy, but without the comedy. At this moment in time things aren't falling apart, which is nice. === admcleod1 is now known as admcleod [14:26] dooferlad, thanks! [14:26] dooferlad, it's ok - do you think you can get on with the uniter api task? [14:27] dimitern: I need a bit of guidance, but once I have that, yes. [14:29] dimitern: are you free to jump in c9.io and a hangout? [14:30] dooferlad, sure, just give me 2m and I'll join the standup HO [14:30] dimitern: see you in https://plus.google.com/hangouts/_/canonical.com/juju-sapphire in a moment then [14:31] dooferlad, omw [14:33] dooferlad, i'm in === natefinch-afk is now known as natefinch [15:20] dimitern, heh - I can't land the script change only as this will bust containers. :( [15:20] frobware, why? [15:21] dimitern, previously we did something like: eth0 -> juju-br0 [15:21] dimitern, so we effectively replace everthing up until digit [15:22] dimitern, which is great until you get to bonds. for bonds we end up with: bond0 -> juju-br0, which can clash with eth0 -> juju-br0 [15:22] dimitern, so I made it a prefix, giving us: juju-br-eth0, juju-br-bond0, et al. [15:23] dimitern, however. the container stuff is absolutely demanding juju-br0. [15:23] dimitern, as it stands that is. once we have the complete change flushed through this wouldn't be a problem. [15:24] frobware, yeah, that sounds right [15:24] frobware, so why not take the rare chance of doing it the right way this time (just in maas-spaces) first? [15:24] dimitern, so we could land the script change but if you had a bond0 expect containers to break. [15:25] frobware, well, if this is the only drawback if we land the improved script into 1.25, and master [15:26] dimitern, yes - if in maas-spaces you use a bond0 ... well sorry... wip. [15:26] frobware, I still think it's fine - it's not like we *used* to work with bonds + juju-br0 and now we regressed [15:26] dimitern, so we're saying let's just land the script, it will get some exposure and we can move on with the bigger change for interface_set, et al. yes? [15:27] dimitern, there's no way the script should go beyond maas-spaces at this point. [15:33] frobware, I think since the script is strictly better and simpler, even without handling bonds properly, we should land it, while continuing to iterate over it in maas-spaces to make it solid [15:34] maas-spaces will end up in master eventually, but we'll have more time to improve the script there first [15:38] natefinch: wwitzel3: ericsnow: forgot to mention, i'm going to close out the iteration this friday in terms of points, so make sure to get any cards you want included moved across to done before EOD friday. [15:40] katco: well I want all of them included .. [15:40] katco: so I'll move all of them, lol [15:40] wwitzel3: =| [15:40] wwitzel3: you wound me, sir. [16:23] dimitern: is there a right way to call the NetworkerAPI from the uniter API? With that we just create a names.MachineTag and call (n *NetworkerAPI) MachineNetworkConfig... [16:24] dooferlad, why would you do that? [16:24] dimitern: to avoid writing the same function again. [16:24] dooferlad, hmm I see where you're going [16:25] dimitern: or we just do it client side - generate the machine tag there and call the networker API. [16:25] dimitern: that would probably make more sense [16:25] dooferlad, but please do it separately, as 1) the networker is not working for a long time now, and 2) I'm seriously considering to remove it in maas-spaces [16:26] dimitern: ah, OK [16:26] dimitern: copy and paste time then :-) [16:28] dooferlad, yeah - that's only due to time constraints though (and because of 2) above) - there are ways to reuse code safely across facades and in other cases I'd have suggested it :) [16:54] dimitern: changes so far: https://github.com/juju/juju/compare/maas-spaces...dooferlad:uniter-network-config?expand=1 [16:54] dooferlad, cheers, looking [16:54] dimitern: back in a bit. Let me know if you think this is the right direction. [16:57] dooferlad, looks mostly fine - please add a test in api/uniter and apiserver/uniter for NetworkConfig and I think it's ready for revew [16:57] review even [17:17] dimitern: OK. May not get to it tonight, but will get it done ASAP. [17:17] dimitern: thanks for taking a look. [17:20] dooferlad, cheers - will have a look tomorrow [17:44] * dimitern whew... after 4 hour long battle with state - now not only the build succeeds, but only the expected 2 tests out of 1240 fail! getting closer.. [17:49] dimitern, should eth1.3 be bridged? http://pastebin.ubuntu.com/14053466/ [17:51] frobware, it looks like it's not up, is it? [17:51] dimitern, correction, look at this one: http://pastebin.ubuntu.com/14053499/ [17:51] dimitern, so the raw dev is no up, but the vlan is. [17:51] frobware, both look like they should be up [17:52] frobware, they are both "auto eth..." [17:53] dimitern, so my notion of active is based on: self.is_active = self.method == "dhcp" or self.method == "static" [17:53] dimitern, maybe that's simply wrong. [17:53] dimitern, or not enough. maybe it should take into account the auto stanza. [17:54] frobware, it all depends on how ifup treats these cases [17:55] frobware, I'd expect anything without "auto" to be down [17:56] dimitern, given our machine generated /e/n/i - what would change to make eth1 ^^ get an IP address? [17:56] dimitern, in the previous example [17:58] dimitern, if I had 10 of eth$N, each manual, would we expect 10 bridges? [17:58] dimitern, I only really ran into this because I forgot to assign an IP addr in the UI for eth1. [18:05] frobware, didn't we decide to make bridges only on the physical NICs which are up and leave any VLAN NICs - so that traffic for vlans will get tagged but still end up on the bridge ? === natefinch is now known as natefinch-afk [18:06] dimitern, I think the issue is determining what constitutes 'up'. I'm beginning to think it should be based on the presence of auto. [18:07] dimitern, the experiment we did yesterday we bridged vlans. [18:07] dimitern, I still think we should do that. [18:10] frobware, yeah - also it's the simplest approach [18:10] dimitern, for now I'm going to treat the presence of 'auto' as an active interface. [18:11] dimitern, if you just had 'iface eth20 inet manual' then that can never be up so is there any point in creating a bridge? [18:11] dimitern, it's the vlan case that is confusing though. [18:12] dimitern, the raw device need not have an IP address but the vlan can. in those cases should the raw device have its own bridge? [18:18] frobware, let me think.. [18:19] frobware, so w.r.t. VLANs, even if their raw device is not "auto" or even up, if the vlan device is itself "auto", IIRC that *will* bring the parent up as well [18:19] dimitern, it will, but if it is 'manual' it won't (obviously!) have an IP address. [18:20] frobware, that sounds correct, but I'd suggest doing a quick experiment to verify [18:21] dimitern, and if it is 'manual' then have no bridge for 'eth1', but we would have a bridge for eth1.789 [18:21] frobware, with iface eth0 inet manual (no auto eth0), and auto eth0.42, iface eth0.42 inet static [18:21] dimitern, you'll get juju-br-eth0.42 (i.e., bridged) [18:22] frobware, I don't think that last is correct though [18:22] frobware, it all depends on if no-auto + manual and no address, coupled with auto+static vlan on top of it actually works [18:24] dimitern, so going back to http://pastebin.ubuntu.com/14053499/ [18:24] dimitern, we would not create a bridge for eth1.3 [18:29] frobware, I think this is correct [18:30] dimitern, right now if this is not correct, then change eth1 from manual to dhcp/static [18:30] frobware, I've just tried here with auto ethX, iface ethX inet manual; auto ethX.42; iface ethX.42 inet static; address 10.42.10.0/24; vlan-raw-device ethX; vlan_id 42 [18:31] frobware, I think it will be much easier in maas-spaces [18:31] dimitern, because? this is in maas-spaces. I was just doing some testing before submitting a PR for the script [18:32] dimitern: hmm... I thought (like you) that new facade versions should start at 1 [18:32] frobware, as right after acquire node + bindings we get all NICs we asked for and we'll know we need a bridge for *each* one [18:32] dimitern: however, there is a test that they should start at zero (TestFacadeVersionsMatchServerVersions) [18:32] dimitern: so I'm setting it to 0 [18:33] voidspace, that test seems wrong [18:33] dimitern: it passes for everything else... [18:33] voidspace, are you sure it's not about facade version before login? [18:33] dimitern, going back to "each one". If you forgot to make eth1 dhcp/static then what we are currently saying is you would not get a bridge for eth1.789 - is that right? [18:33] dimitern: it tests that the version number for each facade is the len of the different versions -1 [18:33] dimitern: i.e. if there is only one version it must be zero [18:34] dimitern: starting some at 1 would require special casing them all in the test [18:34] frobware, ideally we should detect misconfigured interfaces early and report it [18:34] dimitern: gp/afacadeversions_test.go [18:35] frobware, but for now let's assume the network config on the maas node is as expected (in maas-spaces) [18:35] dimitern, ok - let's settle on if the underlying raw device is 'auto' but 'manual' any vlans of that will not be bridged. OK? [18:35] voidspace, where? [18:36] frobware, I can live with that :) [18:36] dimitern: gp/afacadeversions_test.go [18:36] dimitern, It's trivial to fix either way. was just testing... :) [18:36] dimitern: TestFacadeVersionsMatchServerVersions [18:38] voidspace, that sounds like it expects api/ and apiserver/ facades to match, not that all facades need to start from 0 [18:39] voidspace, e.g. api.FacadeVersions["Spaces"] is only at V1 [18:41] voidspace, apiserver/cleaner is another example (of a agent facade, inlike Subnets) also only with V1 [18:44] dimitern: ah [18:44] dimitern: my misunderstanding then [18:45] voidspace, check if you're using RegisterStandardFacade in discoverspaces init() [18:45] *not* RegisterFacade instead [18:45] dimitern: hah, I was using 0 :-) [18:45] dimitern: uhm, sorry about that [18:46] :) np [18:46] dimitern: go on holiday... [18:46] I know a lot of our tests are bad, but at least we should try to grant them some chance to actually fail for the right reasons :D [18:47] :-p [19:13] dooferlad, voidspace, dimitern: if you have the time - http://reviews.vapour.ws/r/3398/ [19:16] Bug #1526926 opened: Controllers cannot be destroyed or killed

[19:19] frobware, will have a look in a moment [19:21] dimitern, thanks. off-hand, do you know if it is possible for the cloudinit config to add a file to the node. I was just looking and it seems that might be so. it woud be better if our script was added as a file (somewhere) so that we don't see the output in the run cmds from cloudinit- [19:21] frobware, yes - there's a AddBootFiles() which does that [19:21] dimitern, aha. [19:23] frobware, your PR looks nice, but I'd like to do a quick test with it and a few configs I found to cause issues; focusing on the demo reqs [19:26] all state tests pass! [19:27] I'm proposing what I have so far as WIP [19:42] frobware: EOD [19:42] frobware: can look tomorrow if it's still needed [19:42] g'night all === BradCrittenden is now known as bac [21:21] frankban: urulama: mothing new from this end, still working on final branch to enable add-relation (writing tests). will be landed by your SOD [21:22] wallyworld: kk [21:23] urulama: frankban: have a good evening and we'll catch up in several hours [21:24] wallyworld: sounds good, on the JS side I have a branch in review with the impl of the mega-watcher remote service consumer and the CrossModelRelations.ServiceOffers API call: https://github.com/juju/juju-gui/pull/1091 will ping Jeff later for review. hopefully that stuff would look familiar to you [21:25] wallyworld: ok. jeff and huw have some tasks on GUI anyway, and frankban made things available in case you finish before we get up. [21:25] frankban: awesome, ty, will take a look [21:25] wallyworld: ty, have a good day! [21:25] frankban: can jeff etc review that branch? or does someone else need to look too? [21:26] wallyworld: yes Jeff and Huw are definitely I'd like to review that branch [21:26] are definitely the ones [21:26] ok, will do, thanks for doing it :-) [21:27] wallyworld: and in case something is not working, please check it with them, so that we can isolate where things get wrong. you'll love JS :) [21:27] (and appreciate golang a bunch more later) [21:27] urulama: oh, i have done a lot of js on the past on launchpad :-) [21:28] perfect then :) [21:28] been a few years :-) [21:28] was all in yui [21:28] which is now dead [21:29] wallyworld: the GUI has still some YUI bits, but we are gradually moving away [21:29] to React I hear [21:29] yes [21:37] cherylj: i'll finish release notes first thing this morning within an hour or so, didn't quite get finished yesterday with everything else [21:37] thanks, wallyworld [23:39] is there someone around that can help point me in the right direction regarding details of the status command implementation ? [23:41] I might, then again, I might not [23:41] heya perrito666 ! [23:41] * perrito666 is the cheshire cat [23:41] :) [23:41] how can I help you suffer status? [23:42] do you mind jumping on a hangout with me, it would be faster I think [23:42] I just need some help navigating the waters [23:42] alexisb: sure, gimme a sec [23:45] fairly easy review anyone? http://reviews.vapour.ws/r/3404/diff/