[00:18] bdx: no [00:18] bdx: why do you ask ? [00:21] davechen1y: rebuild testing suggests that making 'real go' the default on ppc64 would lead to unhappiness [00:21] mostly because of the limited cgo [01:23] alexisb: FYI after wrestling around with a failed upgrade-juju its working and the cpu is behaving. will hit up that bug report if anything goes sideways again [01:31] mwhudson: why do we need cgo ? [01:31] davechen1y: "we" as in juju don' [01:31] t but lots of things in the archive do [01:32] when you say lots [01:32] can you quantify ? [01:32] 10,000 packages ? [01:32] 10 packages ? [01:32] i find it hard to believe that gccgo's cgo support is better ? [01:32] in between those [01:32] cgo on ppc64el is internal linking only [01:33] so it's pretty easy to step outside the bounds of what that can handle [01:33] i'll be able to quantify better tomorrow, still lots of builds going [01:33] some of these indeed don't build on ppc64el with gccgo either [01:33] http://paste.ubuntu.com/11997181/ [01:34] oh come on [01:34] mwhudson: i'm annoyed by this [01:34] this is a problem canonical has done to itself [01:34] davechen1y: i am also annoyed [01:34] and if that means we don't get go 1.5 everywhere [01:34] i will be more than just annoyed [01:35] a recent go 1.5 change breaks docker and my go tools packages are insane for reasons i don't understand [01:35] mwhudson: more practically [01:35] is now the time to suggest taht go versions be versioned in ubuntu in the same way gcc is ? [01:36] ie, go-1.4, go 1.5 [01:36] like we have gcc-4.8 [01:36] i think there is certainly merit in that idea [01:36] how do we make that a reality ? [01:36] it needs to happen immediately [01:36] ie, before the 20th [01:37] hmm that means they also need to be co installable [01:37] yeah [01:37] and it's going to widen the set of alternatives for who owns /usr/bin/go [01:37] it wouldn't be trivial [01:37] co installable is doable [01:38] who owns /usr/bin/go will be more complicated [01:38] yeah not super hard, just a bunch of pain [01:38] well that's managed by alternatives now [01:38] (which is not how gcc does /usr/bin/gcc) [01:38] yeah [01:39] mm [01:39] maybe i should retract my opening statement [01:39] so long as go 1.5 builds juju and lxd on ppc64el [01:40] i don't know how much of this other stuff we care about [01:45] oh [01:45] lxd fails to build :( [01:45] https://launchpadlibrarian.net/213514232/buildlog_ubuntu-wily-ppc64el.lxd_0.14-0ubuntu3_BUILDING.txt.gz [01:45] still if it's just that, we can build it with gccgo [01:45] (which does work) [01:47] it doesn't build because go-sqlite3 does not support ppc [01:47] oh [01:47] crap [01:47] fucking cgo [01:47] why does that encode a database ? [01:47] why does every fucking project have to have a database [01:48] how is that helping us, as a species ? [01:56] https://bugs.launchpad.net/juju-core/+bug/1481133 [01:56] Bug #1481133: version: tests fail on arm64 14.04 [01:57] if this is a test isolation problem I'm going to throw a shoe [01:58] davechen1y: i guess there was never a precise for arm64? [01:59] if that is the cause, i think shoe-throwing would still be appropriate [01:59] i'm going to throw both [02:02] https://bugs.launchpad.net/juju-core/+bug/1481133/comments/1 [02:02] FML [02:02] Bug #1481133: version: tests fail on arm64 14.04 [02:10] Bug #1481133 opened: version: tests fail on arm64 14.04 [02:13] Bug #1481133 changed: version: tests fail on arm64 14.04 [02:21] davechen1y: is the proto-plan to try juju on ppc64 next? [02:21] mwhudson: i guess [02:22] actually, yes [02:22] now I have the script [02:25] Bug #1481133 opened: version: tests fail on arm64 14.04 === moqq_ is now known as moqq [06:41] wallyworld: I'm wanting to add status to volumes and filesystems. what's the appropriate way to marshal that over the API? existing stuff is using api.AgentStatus, which doesn't seem quite right for a non-agent entity... but it is being used for workload and service status too [06:44] axw: from memory, that struct grew to accomodate the extra workload status info, somewhat avoiding api churn. it's messy because there's stuff from 1.18, different stuff added in 1.19 which is supposed to be removed, the legacy info for backwards compat, and the new stuff [06:44] maybe it's time to bite the bullet and add a new api [06:44] wallyworld: okey dokey. I'll look into that, thanks [06:45] kinda what I figured, was hoping I'd overlooked something [06:45] nah :-( [06:45] all a bit messy [07:05] we're using ErrorResults.Combine() now instead of OneError() ?! [07:06] ok, only in a few cases it seems, otherwise it would've been *insane* [07:13] fwereade just texted me they have a power cut and he'll come online when he can [07:20] dimitern: is it correct that in EC2 you can have multiple NICs, but only one subnet per machine (even if you have multiple NICs)? [07:23] voidspace, subnets in ec2 map 1:1 with AZs, so you definitely *can't* run an instance with multiple NICs attached to subnets in different AZs [07:23] voidspace, it's unclear though if you can run an instance with multiple NICs bound to separate subnets in the same VPC and AZ [07:24] voidspace, probably not, but it can be verified easily [07:27] dimitern: ok - the network model document states that machines and subnets map 1:1 and you *can't* have multiple NICs bound to different subnets [07:31] voidspace, we don't intend to allow this initially, yes [07:31] voidspace, to simplify the implementation, but effectively a machine can end up in multiple spaces and subnets [07:32] voidspace, so which subnet a machine is in is not the right question to ask, as NICs are bound to subnets, not machines directly [07:32] dimitern: there was a recent bug that made me think https://bugs.launchpad.net/juju-core/+bug/1478660 [07:32] Bug #1478660: juju uses proxy to access bootstrap node

[07:32] we should probably be adding the space to the no-proxy list [07:32] dimitern: ^ what do you think? [07:33] dimitern: right, it's fine to say we don't support it - the doc implies it's an EC2 restriction and that machines map to subnets 1:1 [07:33] dimitern: I'll add a comment [07:33] jam, is that what we want to do always? [07:34] voidspace, cheers [07:34] dimitern: I don't think you want to proxy for things that you consider on your local LAN do you ? [07:34] jam, is this for MAAS or in general? [07:34] dimitern: in general I'm thinking [07:34] jam, trying to think of scenarios - AWS is different from MAAS for example [07:34] dimitern: they mentioned working around wget, but ISTM that just fixing our wget is shortsighted [07:35] dimitern: still, if you're in a space, it seems to define that you have direct access to other things in that space [07:35] voidspace: I think the idea right now is that service endpoints map 1:1 to a space, not machines [07:35] jam, that's right, yes it seems we should do what you suggest [07:35] jam, I got confused by client-side proxies for a moment [07:36] dimitern: so in general, I think we should avoid proxies for things that want to talk to the state server (consider debug-log, or any future file downloads, etc). It may be that we explicitly ignore proxy settings in our code [07:36] jam, and that relates to voidspace's comment yesterday - *thou shalt always be able to connect to any state servers* [07:36] jam: the network model docs state that for EC2 machines map to subnets 1:1 - so a service can only be on one space [07:36] *in one space [07:37] jam: as a machine can only be on one subnet (even with multiple NICs) [07:38] voidspace: I do see that text, I haven't expiremented personally to know if it is true, though it might complicate (or maybe simplify) things. [07:39] voidspace, you mean a machine, not service, right? [07:39] voidspace, a service spans multiple units (machines in different subnets of the space) [07:39] dimitern: well, you deploy services not machines (well you do both) [07:40] dimitern: so the deploy command can only take one positive space for EC2 [07:40] dimitern: page 9 of Network Model Phase 1.1 says machines map to subnets 1:1 verbatim [07:40] dimitern: a service can only be in one space *because* machines can only be on one subnet (i.e. one space) [07:41] voidspace: dimitern: it should probably take as long as this discussion to bring up a machine, create 2 subnets in the same AZ, and see if you can attach 2 network interfaces from each subnet to it [07:41] :-) [07:41] probably longer for me, but it would be time well spent I think [07:41] * dimitern gets increasingly confused [07:41] voidspace: I do think that if that constraint is true, we need to think carefully about the ramifications to the network model [07:41] we need to chat about this at standup [07:42] I'm trying to review a bunch of things and am distracted right now [07:42] specifically, if you ever want to separate the ADMIN endpoint for MYSQL onto a separate space from the DB endpoint, then we need to know if that is actually possible. [07:42] jam: the space model seems to only be *really* useful when you can have some of your services on multiple spaces [07:42] jam: and you have firewalling between the spaces [07:43] voidspace: well, it can be useful between services (postgres is only in the DB space, and WebApp is in a different space) with custom routing/firewalling [07:43] right [07:43] we need to do the custom routing [07:43] fair enough [07:43] and we also need to do custom routing for the state server [07:44] so I thought for P1 we still had the flat space for Juju traffic. [07:44] jam: you mean no firewalling? [07:44] voidspace: we aren't directly controlling the firewall yet (relations != connections in all cases) [07:45] voidspace: but I mean that being in *a* space means you are actually in 2 (the Juju meta space and the explicit one for the service) [07:46] jam: "the Juju meta space" isn't something mentioned in the network doc [07:46] jam: can all machines in every space route to each other through the meta space? [07:47] as spaces are described as being "a security subdivision of a network" it seems that they only have any reason to exist if traffic between them is restricted / controlled (or am I wrong)? [07:48] is the "meta space" just a consequence of having no routing restrictions - or is it (or will it be) something else (a specific set of routing rules)? [07:50] voidspace: so I think it was a pragmatic decision in first phase to make sure everything can talk to the state server without requiring the server to have an address in every space. [07:50] but it may have been in conversations and not captured in the doc [07:50] right [07:51] it certainly does get us away from strong security if we don't have binding [07:51] (if your service always binds to all available interfaces, then having an interface on a globally routable space means you lost the security aspect) [07:52] which is the raison d'etre for spaces to exist at all :-) [07:55] jam: when I login to the AWS console and then navigate to EC2 I get a "Your service sign-up is almost complete!" message [07:55] I've tried us-east-1 and us-west-2 [07:55] jam: could you verify it works for you? (sorry to be a pain) [07:56] I can try from go-amz instead [07:56] voidspace: trying to go in [07:57] seems like I get the same response from all the AZs [07:57] voidspace: I see a juju-env machine running in us-east-1 [07:57] m1.small [07:57] ok, must be a problem with my account [07:57] though that is via the master account, if you are using an IAM role [07:57] voidspace: is it a personal account? [07:57] or shared? [07:57] I logged in with the wrong account first (and then signed out) - it maybe a cookie issue [07:58] jam: it's my canonical account [07:58] voidspace: interesting, your mfoord user in the shared account has password last used of 2014-11 [08:00] jam: odd, I get the same result from another browser too [08:01] jam: gah, user error [08:02] jam: I have a personal account with my canonical email address [08:02] jam: I wasn't using the shared account [08:11] jam: when launching an instance I can create multiple nics bound to different subnets (in the same AZ) [08:11] dimitern: ^^^ [08:18] voidspace, I can't say off hand, but should be easy to verify by using the AWS CLI commands [08:18] voidspace, or even the web UI [08:18] TheMue, I've responded on your review, but I'm afraid I found even more issues missed earlier, ping me if anything is unclear [08:19] dimitern: ah, great, thank you. just wanted to ping you that I added some questions/remarks. but the I found your mail about the sprint and currently answering it. [08:20] TheMue, cheers [08:22] axw, are you still around? [08:22] wallyworld, or you? [08:32] dimitern: I'm here, what's up? [08:33] axw, I'm reviewing your RB2295 and found out we're now using things like storage.XXXResults similarly to apiserver/params.XXXResults with Error fields [08:33] axw, but that's in the providers; wasn't clear at first, but I figured it out, sorry for the noise :) [08:34] dimitern: well, this is the first place it's done AFAIK. I'm trying to enable bulk provider API calls, even though the current ones mostly don't support it [08:34] dimitern: some do (DestroyVolumes for some), some don't (all CreateVolumes) [08:35] dimitern: cool, no worries [08:35] axw, we need this for sure - we can use it for ReleaseAddresses as well for example [08:36] dimitern: you might be interested in the next branch I put up, which does retries for failed operations. the storage provisioner will include a scheduler for operations, with failed ones being put back on the schedule to retry at a later date [08:36] axw, think about a few common cases there: retrying transient errors (how to make that easier to convey) as well as a few helpers on the results types that have errors to verify e.g. the number of results == number of args [08:37] axw, nice! I'll definitely be interested in looking at that [08:37] hm yes I suppose it should check those things [08:37] I'm currently relying on the fact that it's all in the same process, so we *should* be able to rely on them doing the right thing [08:38] but I could make it more pedantic [08:39] might be worth it in the face of future extensions to the behavior/implementation [08:40] axw, it seems a bit unwieldy how ([]error, error) returns are handled - a some common Combine() helper might be useful [08:41] dimitern: that's a stop-gap. in a follow-up, the individual errors will be used to decide whether or not to reschedule, and they won't surface. a further follow-up will propagate the errors to status [08:41] so you can see the provisioning error from the CLI [08:41] I had it as one big branch, but it was >1200 LOC :) [08:42] wow :) [08:42] axw, ok, I'll follow the follow-ups then [08:52] dimitern: thanks for the review [08:53] axw, thanks for starting to solve the retrying in general for providers :) [08:57] dimitern: I have verified it! [08:57] dimitern: I was saying I *can* create an instance with multiple nics on different subnets [08:59] voidspace, ah, I see [09:00] voidspace, well that's AWS, in other clouds we'll have different constraints like this, OpenStack being an example of almost "all is allowed" sort of cloud [09:02] TheMue: dooferlad: stdup? [09:02] voidspace: omw, fetch a coffee [09:02] fetched === Spads_ is now known as Spads [11:02] morning all [11:06] heya perrito666 [11:09] perrito666, hey, my fellow OCR :) [11:10] * perrito666 feels something coming his way [11:10] perrito666, I've left you the best review of all - william's final leadership one [11:10] * dimitern ducks [11:10] :) [11:11] dimitern: aren t you a sweetie [11:11] perrito666, I'll buy you a beer on the next sprint hehe [11:11] ill make some coffee before this [11:19] ericsnow: ping [11:56] dooferlad, I think the build errors you're getting might be due to the "type SpaceDoc spaceDoc" definition in export_test.go (or something else like this when only happens while running tests) [11:59] dimitern: well it was the second time around most of these changes [11:59] which made them a bit easier [12:00] perrito666, I've been on some of the previous ones as well, but there are new things there as well [12:00] dimitern: yep, but still much better than the first time [12:00] :) [12:01] * dimitern found out this background music makes it a *lot* easier to go through reviews :) https://www.youtube.com/watch?v=exWNztpgfIw [12:03] dimitern: sounds like it would make you shoot at the review at some points [12:04] perrito666, it occasionally does, yes :) [12:22] dimitern: the code builds fine here. Very strange [12:22] dimitern: in fact I have 100% tests passing, and I have rebased on upstream so I should have identical code. [12:26] dimitern: maybe a go version thing? I am on 1.4.2 [12:26] dooferlad, I'm on 1.2.1 which is the same CI uses IIRC, I'll pull your branch and try it here [12:30] dimitern: thanks. I thought we had moved to 1.4.2. Guess not. Are we waiting for 1.5? [12:30] dooferlad, we are [12:30] dooferlad, but it's useful to have a mix of versions until then, just for such issues [12:31] dooferlad: ping [12:31] voidspace: hi [12:31] dooferlad: hey, you available to hangout? [12:32] voidspace: yea, I can come back to this. [12:32] dooferlad: cool, stdup hangout? [12:33] sure [12:38] mgz, ping [12:56] dooferlad, btw while looking at the changes your branch introduced - https://github.com/juju/juju/compare/net-cli...dooferlad:net-cli-state-add-space I noticed the last change - removing Assert: isAliveDoc from Subnet.EnsureDead() - why is that? [12:56] dimitern: odd. [12:56] dimitern: must spaces list be a bulk call? [12:57] voidspace, I don't think so, but it should take filters [12:57] dimitern: what do you mean by filters? [12:57] dimitern: filtering output by name or something? [12:58] dimitern: the CLI doesn't have filters (like that) [12:58] voidspace, let me double-check the model [12:58] * voidspace too [12:58] I might be thinking of subnet list [12:59] dooferlad: the juju command is actually "space" rather than "spaces" [12:59] dooferlad: so "space" seems more correct [13:00] subnet list hasn't been done yet [13:00] voidspace, no filters for space list [13:00] so I can't just copy it [13:00] dimitern: yeah [13:01] voidspace, the --short argument is purely a CLI thing - we still get all the details from the API [13:01] dimitern: ok [13:01] dimitern: and what about format? [13:01] dimitern: do we do that on the server? [13:01] I'll find another list cli command and look at that [13:02] voidspace, how about this? http://reviews.vapour.ws/r/1390/ [13:02] voidspace, the format is also a CLI thing [13:02] dimitern: yeah, I meant the apiserver bit [13:02] dimitern: thanks though, worth looking at [13:03] voidspace, ah, yeah - no apiserver support for listing spaces, but it should just call Backing.AllSpaces [13:04] dimitern: so if format, output and short are all handled on the client - ListSpaces takes no arguments [13:05] dooferlad, please reintroduce that assert [13:05] dimitern: will do. Did you have any problems with go 1.2? [13:05] voidspace, yeah [13:06] dooferlad, tests are still running - so far a few failures which look like flakyness [13:18] dimitern: hey [13:18] dooferlad, passed the cmd package where the build issue happened on the CI machine - no issues [13:18] dimitern: I thought the problem was in state. [13:18] mgz, hey, I'm trying to analyze why this merge fails with such an odd error: http://juju-ci.vapour.ws:8080/job/github-merge-juju/4188/consoleFull [13:18] dimitern: you could "cd state; go test -c" to check for a compile error [13:19] mgz, it's happening a few times now and both I and dooferlad get no errors when running tests with the same branch locally, I'm on 1.2.1, he's on 1.4.2 [13:19] dimitern: that's not one I've seen before [13:19] dooferlad, I know, but just in case it's some weird issue which *only happens* under load or when running the full suite.. [13:20] mgz, can you force the instance to stay after the tests fail, so we can get in and inspect it? [13:24] hm, I should just attatch the tarball as an artifact [13:26] ugh, that branhc adds more ConnSuite derived tests? [13:27] dimitern: I bet the problem is the export_test [13:28] mgz, that's what I suspected, but there's no redefinition of that type there [13:29] I am surpised it worsk for you on 1.21 but not on the clean instance for the bot [13:29] mgz, and since #testmain is involved, I strongly suspect it's actually due to the way we're running CLI tests (another possibility is a dirty GOPATH on the CI instance) [13:30] dimitern: try running `make check` and see if you get it? [13:30] mgz, I did, it's running for a while now [13:31] mgz, and there it is! I've reproduced it (in a different package, but that's due to suites running in parallel I guess) [13:31] dooferlad, I've got a repro [13:31] dimitern: sweet! [13:32] katco, are you in today? [13:34] alexisb: i am :) [13:39] dooferlad, now running go test ./... in cmd/juju to see if that triggers it [13:41] incredibly annoying :( [13:42] it's not that then trying cmd/jujud/ [13:44] dooferlad, I managed with go test -c in state/ [13:47] dimitern: perrito666: more input needed on this: http://reviews.vapour.ws/r/2199/ [13:47] katco, ack, will look shortly [13:48] dooferlad, found a workaround [13:49] katco: will look [13:50] dooferlad, if you change "func (s *Space) Doc() spaceDoc { return s.doc }" to "func SpaceDoc(s *Space) spaceDoc { return s.doc }" (and the tests from space.Doc().X to state.SpaceDoc(space).X) it builds ok here [13:50] dooferlad, amazingly it doesn't complain about spaceDoc not being exported, which I expected [13:51] oh boy PowerShell [13:51] gsamfira, ping :) [13:52] perrito666, I'm with you on that one re PS [13:53] dimitern: ? [13:54] perrito666, about http://reviews.vapour.ws/r/2199/ [13:56] katco, replied, if somewhat unhelpfully I guess [14:01] dimitern: thanks. Just setting up a container to let me test in a clean environment before I try and merge again, (trusty + default go) [14:02] dooferlad, +1 [14:06] Bug #1481366 opened: leader-get may fail in -departed hooks [14:08] alexisb: hey i'm out tomorrow [14:09] katco, ok np [14:09] I need to catch pat before she goes on vacation, so just decline the call [14:10] alexisb: k will do [14:10] alexisb: just lemme know what you need from me [14:28] katco: that patch is still a hughe powershell blob, I have no idea what is going on inside [14:30] Bug #1481368 opened: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down

[16:03] perrito666, ping [16:18] alexisb: pong [16:18] sorry was having lunch [16:18] perrito666, no worries [16:18] I saw https://launchpad.net/bugs/1481368 come in on the proposed 1.24.4 [16:18] Bug #1481368: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down

[16:18] looks to potentially be status related [16:18] * perrito666 checks [16:19] was curious on your perspective [16:22] alexisb: mm, I think it might be something else being masked by status [16:30] perrito666, katco, cherylj, wwitzel3, ericsnow, natefinch if someone has free cycles https://launchpad.net/bugs/1481368 needs to be worked [16:30] Bug #1481368: Deploy hangs: jujud-machine-0 upstart process running but juju status shows it down

[16:30] alexisb: might be possible later. today is moonstone's catchup+planning day [16:31] alexisb: since i was out on fri. [16:31] katco, ack [16:35] alexisb: I can take a look in a few [16:38] cherylj, thank you as always === Guest47499 is now known as anthonyf === anthonyf is now known as Guest410 === Guest410 is now known as anthonyf === anthonyf is now known as Guest26675 [19:23] cherylj: I am trying to force CI to retest your commit to master. [19:24] sinzui: for bug 1480298? [19:24] Bug #1480298: unknown object type "Charms"

[19:26] cherylj: yes. the branch failed because of a logging test that may have been intermittent [19:26] ah, ok [20:31] Hello core devs. Someone is setting up a network for a conference and wants to know all the ports to open to get Juju to work. I know about 22 and 37017 and 38017, are there any other ones that I am forgetting? [20:31] when I do a google search for juju ports I only get the open ports for charms. [20:37] wwitzel3: ericsnow: we'll delay the remainder of planning until thurs. do you feel like you have a good idea of what to work on tomorrow? [20:37] katco: yep [20:37] katco: I also did my best to flesh out the cards we have [20:37] ericsnow: awesome ty [20:42] The default port numbers for api-port, state-port, and storage-port are 17071, 37017, and 8040 respectively. [20:56] katco: yep, sounds good [20:56] ericsnow: thanks :) [21:16] menn0: ping [21:19] perrito666: sorry, in standup [21:42] menn0: np, just ping me when you have a moment plz [22:06] perrito666: ok i'm done. what's up/ [22:06] you dont seem happy to see me :p [22:07] ill go priv so I have proper logs to read after [22:16] Bug #1481500 opened: automatic devel streams selection for beta releases

[23:00] aghh my fix depends on fwereade patch [23:14] perrito666, this one: https://github.com/juju/juju/pull/2909 [23:14] yeah, I am trying to make a patch for it [23:17] alexisb: mm, it seems he did not fwport all of it, ill propose a patch tailored to master