[00:51] davechen1y: just a peanut gallery comment but does that ppc64 crash happen with GOGC=off? [01:15] mwhudson: let me check [01:15] i already checked stack copying [01:15] and adjusted the min stack size to be higher [01:15] what it looks like to me is the receiver of the method is not being carried over in the case that there are no arguments [01:15] which is weird [01:16] but that'ts the case [01:16] does it happen all the time? [01:17] i could guess that autogenerated methods might screw up SP manipulation but that seems like the sort of thing that ought to break hard all the time [01:19] mwhudson: 100% of the time [01:19] oh [01:19] well that shooooooooouuuuuuuuuuuuulllllllllllllld make it easier to fix [01:19] github.com/juju/juju/cmd/envcmd.(*SysCommandBase).ConnectionInfo(0x478420, 0x0, 0x0, 0x0, 0x0) /home/ubuntu/src/github.com/juju/juju/cmd/envcmd/systemcommand.go:130 +0xec fp=0xc820484c98 sp=0xc820484c20 [01:19] github.com/juju/juju/cmd/envcmd.(*SysCommandBase).ConnectionEndpoint(0x478420, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) /home/ubuntu/src/github.com/juju/juju/cmd/envcmd/systemcommand.go:116 +0x5c fp=0xc820484df8 sp=0xc820484c98 [01:19] receiver is 0x0 in the autogenerated method [01:20] then bonkers in the next frame down [01:20] opps [01:20] github.com/juju/juju/cmd/envcmd.(*SysCommandBase).ConnectionEndpoint(0x478420, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) /home/ubuntu/src/github.com/juju/juju/cmd/envcmd/systemcommand.go:116 +0x5c fp=0xc820484df8 sp=0xc820484c98 [01:20] github.com/juju/juju/cmd/juju/user.(*AddCommand).ConnectionEndpoint(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...) :17 +0x30 fp=0xc820484e00 sp=0xc820484df8 [01:20] this, not the other one [01:20] is a nil receiver plausible? [01:21] theorerically yes [01:21] calling through an interface, no [01:21] and in this case [01:21] the receiver was not nil [01:22] the weird thing is genwrapper is only called from two places in the compiler [01:22] it is called a _lot_ [01:22] right, and you haven't been able to reduce it? [01:22] it takes minutes every run [01:22] i am trying to reduce it [01:23] but everything on ppc takes so long [01:23] also, you cannot breakpoint an autogenerated wrapper [01:23] which is fucked [01:23] if you could [01:23] this would be easy [01:23] eh? [01:23] gdb and go, two great tastes etc [01:24] davechen1y: you can break point on an address btw [01:24] br *0xdeadbeef [01:24] github.com/juju/juju/cmd/envcmd.(*sysCommandWrapper).Run(0xc82023e580, 0xc82040b590, 0x0, 0x0) :61 +0x9c fp=0xc820485300 sp=0xc8204852b8 [01:24] what's the address ? [01:25] does "p 'github.com/juju/juju/cmd/envcmd.(*sysCommandWrapper).Run'" show anything? [01:49] davechen1y: lolz [01:49] (vivid-ppc64el)mwh@kelsey01:~$ ~/go/bin/go get github.com/juju/juju/... [01:49] # cd /home/mwh/gopath/src/github.com/juju/juju; git show-ref [01:49] package github.com/juju/juju/...: signal: segmentation fault [03:53] /away [03:53] mwhudson: it prints something [03:53] but it's not that useful [03:53] i have some ideas for a repro now [03:53] i'll keep trying [04:13] axw: did you have 5 minutes? in standup hangout? [04:13] wallyworld: be there in a sec [04:30] Bug #1483492 opened: worker/storageprovisioner: machine agents attempting to attach environ-scoped volumes [05:12] axw: building with your latest pull request [05:27] mwhudson: Thuper: got it! [05:27] i have a repro [05:28] which doesn't involve any juju code [05:38] https://github.com/golang/go/issues/12108 [06:00] Bug #1483525 opened: Document action-set quoting [06:38] aisrael: thanks for the update. the other things are known issues. to destroy with persistent storage, you currently have to use --force, or destroy the machines that the volumes are attached to. I'll send a PR soon that makes this unnecessary [06:41] mwhudson: i know what it is [07:00] Bug #1236859 changed: errors reported in agent-state can contain too much information (traceback, etc)

[07:07] dimitern: ping [07:09] dimitern: unping [07:11] voidspace, (un)pong? :) [07:11] dimitern: hah [07:11] dimitern: I had a question, but I figured it out... [07:11] voidspace, awesome! [07:12] hah :-) [07:12] not sure that counts as awesome, but thanks [07:12] you must have had your coffee already this morning [07:12] Bug #1298819 changed: Mechanism for retrieving relation names

[07:13] voidspace, well, you know at least it's a great start of the morning [07:13] voidspace, :) [07:14] :-) [07:14] apparently giving your smilies noses, the - in :-) , is a sign that you're old [07:14] I just can't get used to :) though [07:14] his eyes are too close to his mouth [07:16] hehe [07:16] I like :o) sometimes or just ;] when lazy [07:18] :o) looks like a clown [07:19] voidspace: really? it has something pig-ish to my eyes .. ") [07:20] anastasiamac: heh, maybe [07:20] clown pig [07:20] dimitern: soooo.... [07:21] dimitern: we have an issue with address allocation for containers [07:21] dimitern: we get the subnet from the provider [07:21] dimitern: and create it in state if necessary [07:21] dimitern: and now subnets in state have space information [07:21] dimitern: but address allocation for containers cares nothing for spaces yet [07:22] dimitern: so if the subnet it discovers from the provider doesn't exist in state it will create it in the default space [07:22] dimitern: I might just ignore this for my PR and I think we need a new card for it [07:22] dimitern: because fixing that is quite a bit of thinking [07:23] anastasiamac: good evening [07:24] dimitern: what it ought to do is check the space constraints for the container, iterate over all subnets until it finds one that matches and use that [07:24] Bug #1298819 opened: Mechanism for retrieving relation names

[07:25] voidspace: evening :D [07:30] voidspace, it does need a new card, yes [07:30] Bug #1298819 changed: Mechanism for retrieving relation names

[07:30] voidspace, but it needs spaces-in-constraints support first [07:31] dimitern: fair enough [07:31] dimitern: maybe it's time to start telling containers which subnet(s) to pick an address from instead of just picking an arbitrary one [07:32] dimitern: at the moment we discover subnets and create them in state when we use them [07:32] anyway [07:32] I'll add a card for us to estimate [07:35] dimitern: I added a card for updating AddSpace/CreateSpace to allow spaces with 0 subnets [07:35] dimitern: not much work, but some work [07:36] voidspace, cheers [07:37] voidspace, as soon as we finish the mvp stuff, we should make sure the address allocation still works and fix it as needed [07:38] dimitern: why does subnetsAPI define AllSpaces? [07:38] and define it differently to the spacesAPI [07:38] voidspace, to verify the spaces [07:39] voidspace, is this the backing interface or? [07:39] dimitern: apiserver/subnets/subnets.go [07:40] dimitern: and it returns a list of space tags, whereas AllSpaces as used by "space list" returns full space information [07:43] voidspace, well, we only need the tags for the CLI, but I guess there's no harm do get all the information if it's easier [07:44] dimitern: ah, it's called ListSpaces on the spacesAPI [07:44] dimitern: but the backing call is AllSpaces [07:44] dimitern: slightly confusing but not actually wrong [07:49] voidspace, these are one of the earliest attempts - it was expected for the various cli, api, apiserver, and backing interfaces to change, but get some sort of convergence at the backing side eventually [07:49] ok [07:57] davechen1y: nice test case reduction [08:06] davechen1y: ooooh i think i know [08:16] mwhudson: do tell [08:16] it's something about the setup for duff copy [08:16] i'll see what russ says overnight [08:16] davechen1y: well duffzero is entered by bl [08:17] OH [08:17] yeah [08:17] that' won't help [08:17] and the function exits by b to the method [08:17] yup [08:17] i've hit that before in risc compilers [08:17] which blr's out... [08:17] and back to the callers caller [08:18] no [08:18] hang on [08:18] back to the generated method i think [08:18] hmm [08:18] i don't think that is it [08:18] i was clued in by a breakpoint being hit an impossible number of times [08:18] oh [08:18] so it's going around and around until it rolls off the end of the stack ? [08:19] er not sure [08:19] i think you're close [08:19] i think the stack pointer is wrong [08:19] but that isn't the whole story [08:19] the reciver is zeroed out [08:19] anyway [08:19] so the load from the stack at the end of the function is not reading the right bit of stack [08:19] this is all very familiar feeling, did we fix this bug in arm64 already or something? [08:20] i think you're right with the tail call thing [08:20] wrapper methods are designed to return to their caller [08:20] anyway, i know how to fix juju [08:20] even if it means a small patch [08:21] disable duffzero? [08:21] oh, or a juju change? [08:22] just disable duffzero [08:22] we'll live [08:23] i wonder if this fixes the GOARCH=amd64 go build runtime thing [08:23] that's probably a bit optimistic [08:23] probaby a long shot [08:26] mwhudson: anyway, not looking at it any more tonight [08:26] davechen1y: fair enough [08:26] thanks for the sugestions, i'll have a look tomorrow [08:27] i'll add a quick comment [08:27] dooferlad, go fmt is sad: cmd/juju/commands/main.go [08:35] mwhudson: thanks for that comment [08:35] i think you're right [08:35] there was something similar a while back with somethign in the arm32 runtime [08:35] i don't rememver exactly [08:36] it was something like the kernel atomic helper [08:36] or something like that [08:36] NO [08:36] it was the gettls helper [08:36] which was sort of the same thing [08:36] needs a kernel helper to get the tls offset [08:36] ah yes [08:36] blah blah [08:36] tail call didn't call no more [08:36] that tickles faint bells [08:38] mwhudson: b377c9c6a9b720d0897d298652bebd3887ceeb46 [08:38] for your ref [08:38] i think [08:39] i might have fixed a similar problem [08:39] but i cannot find the ref [08:39] anyway [08:39] it's the same smell [08:39] arch's with link registers get tripped up by these shennaigans [08:39] i can't for the life of me find the code that compiles the tail call [08:42] genwrapper [08:42] i mean the liblink bit [08:42] i don't think it's there [08:43] sorry, i mean the bit that creats the b $foo instruction [08:43] i found it, then realized i was looking at arm64 [08:43] i think it's [08:44] compile/internal/gc/subr.go [08:44] generapper [08:44] case 11 in asm9.go [08:44] oh god [08:45] please don't make me look at asmN.go [08:45] heh ok [08:45] that's the worst [08:46] hmm, this doesn't look to magic [08:46] i don't think that's the right place to look [08:47] ok [08:47] i see, ADUFFCOPY is implemened in case 11 [08:48] so [08:48] arm and arm64 will be in the same boat [08:48] what are they doing I wonder [08:48] yeah i wonder how come they don't break [08:53] arm64 reloads the link register from the stack before the tail call [09:13] are you looking at zerorange in arm64 ? [09:13] or is that in asm7 ? [09:24] mwhudson: here's some math for ya [09:24] 8+frame+lo-8 [09:24] davechen1y: seems like that could do with some constant folding [09:25] davechen1y: i think i've found the ppc64le/arm64 point of difference [09:25] the ARET case in preprocess [09:27] i think it could be soethign else [09:27] have a look at zerorange in arm64 [09:27] and zerorange in ppc64 [09:27] arm64 laosd the SP into rt1 then adds the size to zero to it [09:28] ppc64 does not load the sp [09:28] oh [09:28] sorry [09:28] yes it does [09:28] it sets the source reg to be regsp [09:28] and the dest reg to rt1 with an add [09:29] we cannot do the same for arm64 because you cannot use Sp as the source or something [09:29] anyway [09:29] that's not it [09:29] i'm sure you're right about the tail call not reloading sp [09:42] davechen1y: disabling duffzero seems like the right fix [09:42] for the short term [09:52] and to a general lack of surprise it doesn't fix the "can't compile amd64 code" thing [10:32] dimitern: we used to have space validation that would check all specified subnets have a valid CIDR and exist [10:32] dimitern: I replaced the validation logic with a check that they exist in the transaction [10:33] dimitern: so an invalid subnet still fails (because it doesn't exist in state) [10:33] dimitern: the place to check for an invalid cidr would seem to be when adding a subnet [10:33] dimitern: so I'm going to remove the failing test I have as a consequence [10:33] dimitern: specifying an invalid cidr when adding a space still fails [10:33] dimitern: but now it fails with subnet not found [10:34] and there's a test for that already [10:37] voidspace, hmm.. I have to take a look to remind myself.. [10:38] dimitern: TestAddSpaceInvalidCIDR is gone [10:38] dimitern: see https://github.com/juju/juju/compare/net-cli...voidspace:spaces-list-state?expand=1 [10:39] dimitern: due to the removal of Space.validate and changes to AddSpace [10:40] dimitern: so the only difference is that for an invalid CIDR in AddSpace we don't validate first, but we do ensure the subnet exists (it won't) and fail with a sensible error message (subnet not found) [10:40] voidspace, hmm.. [10:41] voidspace, so invalid CIDR I think should be validated before looking it up [10:41] dimitern: why? [10:41] dimitern: that's only sensible if we will be putting invalid CIDRs in state [10:41] dimitern: which we really shouldn't! [10:41] voidspace, well, it how about ";drop tables foo" :) [10:42] dimitern: you're saying we have an injection vulnerability... [10:42] dimitern: I really don't think so [10:42] voidspace, but seriously, we shouldn't put invalid cidrs in state indeed [10:42] voidspace, jk [10:42] :-p [10:43] voidspace, so you're saying adding a space with an empty list of subnets is now allowed? [10:43] dimitern: yes [10:43] voidspace, but ISTM non-empty list with possibly invalid cidrs leads to erraborted on addspace [10:43] dimitern: yep [10:43] dimitern: and there's a check for that [10:44] dimitern: if we get ErrAborted that isn't due to the space already existing we check to see which subnet is missing [10:44] dimitern: so we can report the error correctly [10:44] dimitern: and there's a test for it, which passes [10:44] well, missing subnet [10:45] which is exactly the same thing (as an invalid cidr will always be missing) [10:45] voidspace, indeed, sounds reasonable [10:45] cool, thanks [11:11] TheMue, you have review - sorry it took so long [11:11] dimitern: great, thanks. [11:15] morning people [11:40] Bug #1483672 opened: Allow charms to associate structured data with status

[12:16] dimitern: the mentioned trick is, because State.DeadIPAddresses() returns a []*state.IPAddress, but in the mock I want a []StateIPAddress. a direct type cast of a slice isn't possible, only in a loop one by one [12:17] dimitern: any more intelligent way is welcome [12:18] TheMue, I see, ok [12:18] dimitern: heyCompilerImNotDumbSoCast([]myType, mySubInterfaceSlice) [12:27] TheMue, :) I'd suggest adding a comment like // Convert to addresses to []StateIPAddress [12:27] dimitern: yeah, makes it more clear. [12:30] TheMue, uhm.. s/to[1]// [12:30] just Convert addresses.. [12:31] dimitern: already thought so [12:34] dpb1: ping [12:55] dimitern: voidspace: do you have a moment to review http://reviews.vapour.ws/r/2324/ ? [12:55] TheMue: after the MAAS call maybe [12:56] TheMue, yeap [12:56] great, thx [13:42] alexisb, katco, perrito666: there's also this as a dependency for the centos PR, it doesn't seem to show up on rbt because the request didn't get automatically created [13:59] dooferlad: dimitern: if you have time http://reviews.vapour.ws/r/2344/ [14:01] dimitern: hmmm... "space add" won't initially be supported by ec2 will it. So I'm not sure why we've implemented it (with the same semantics as create it seems) [14:01] ah well [14:02] I'm not even entirely convinced we need both anyway... [14:03] we should just have add, if it already exists on the provider that one should be used - if it doesn't (and creating is supported) then it should be created [14:03] possibly the same for subnets [14:05] hi frankban [14:06] added as a comment to the model doc [14:06] dpb1: hi, could you please either give me write access to lp:juju-deployer or take a look, merge and release https://code.launchpad.net/~frankban/juju-deployer/guiserver-bundle-v4/+merge/267540 ? [14:09] dooferlad: would you mind adding a link to the PR to bug #1468349? [14:09] Bug #1468349: discoverySuite.TestDiscoverServiceLocalHost: invalid series for wily and vivid

[14:13] ericsnow: done [14:13] dooferlad: thanks! [14:16] voidspace, well, I think technically speaking, juju space add ... is a great way to "import" spaces from previous deployments [14:16] dimitern: sure, and it would remain so [14:16] dimitern: however, if there is no previous deployment then it would create them [14:17] dimitern: I'm not suggesting any change in functionality, merely merging add and create [14:17] voidspace, because it allows you to discover tagged subnets as part of a space, and .. hmm.. although overwriting the list of subnets seems dangerous [14:18] dimitern: doesn't add already have this problem [14:18] dimitern: if you want to add an existing space then don't specify any subnets [14:18] dimitern: the user will always want to either add or create, but they only need a single entry point to do it [14:18] dimitern: whichever we do under the hood, from the user perspective they are adding a space to the current environment [14:19] voidspace, and, in case of AWS if you pre-tag subnets you effectively create spaces you can immediately use for bootstrapping [14:19] voidspace, so "add" only makes sense to take a name, yeah [14:20] voidspace, perhaps it can optionally take CIDRs and verify if they match, or if not - create it.. [14:21] voidspace: thx for review. "failled" is no typo, the more l, the more it failed ;) [14:21] TheMue: hehe [14:21] failllllllled [14:22] dimitern: we don't need to take CIDRs - let's not [14:22] dimitern: I've added a comment to the model doc [14:22] dimitern: I'd prefer we just merged add and create [14:22] voidspace, or if they match (or are a subset of) the actual tagged subnets just ignores them and adds all subnets [14:22] dimitern: all existing subnets should be discovered [14:23] dimitern: in fact - we probably don't want add at all [14:23] dimitern: we probably want "space discover" [14:23] voidspace, not really [14:23] dimitern: find and add all subnets and spaces [14:23] voidspace, I think the original idea was that "create" is an admin command [14:23] dimitern: in case you only want a subset of available spaces and subnets? [14:23] dimitern: it's not in the doc... [14:24] voidspace, while "add" can be used to "subclass" a bigger space [14:24] dimitern: MVP is ec2 only, which doesn't support add at all [14:24] voidspace, :) it's in one of the other docs or numerous notes, I'm sure [14:24] and "space discover" would still be useful - find and add all spaces and subnets [14:24] voidspace, or space list --all [14:25] dimitern: and I bet that would be all most users would ever use... with manually adding a subset being an esoteric and rarely used option [14:25] voidspace, or you mean more like "space import --existing" [14:25] "space import" [14:25] the --existing flag is redundant [14:26] "space list --all" would be cool too (later) [14:26] yeah, it could instead be --from file.yaml [14:26] bbiab [14:26] hah [14:26] voidspace, agreed, I'll fix this to be reflected by the doc [14:27] voidspace, it should be easy to drop the parsing/tests around add with CIDRs [14:28] we don't need it at all for ec2, but yes [14:28] voidspace, and we could then just omit it from the MVP [14:29] voidspace, I'd like to keep it in net-cli, as soon we should be able to discover and add maas spaces [14:45] dimitern: will you find a moment for a hopefully final review too? [14:54] TheMue, did you see my comment about the EnvironWatcher ? [14:55] dimitern: yeah, removed it [14:55] dimitern: now everything is even smaller and more simple [14:56] TheMue, hmm well I still see it in api/ [14:57] dimitern: oh, will take a look, thought I got them all [14:57] ericsnow: wwitzel3 any of you around? [14:57] perrito666: sure [14:57] perrito666: heyo [14:57] ericsnow: a quick question (hopefully) I see you guys implemented a basic disk abstraction [14:58] and that you have only types for persistent and scratch [14:58] dimitern: sh*t, yes, killed it on server side but missed client, one moment [14:58] perrito666: right [14:58] perrito666: those are needed during provisioning [14:58] what do I get with persistent, standard persistent or ssd persistent? [14:59] perrito666: I don't really remember (the GCE docs can tell you though) [15:01] mmm I see that goes for an attached disk, Ill look more into creating un attached disks [15:01]