[00:09] * thumper is now grumpy, sore and hungry [00:09] specialist appointment for shoulder isn't until 26th of November [00:14] o_O [00:17] thumper: bugger [00:17] thumper: sounds very NHS-ish [00:18] thumper, davecheney: so what are we doing about the standup? I have an errand to do so just trying to plan the rest of the day. [00:22] menn0, davecheney: now? [00:22] thumper, davecheney: works for me [00:23] sure, i'll see you in the hangout [01:04] menn0: one for you http://reviews.vapour.ws/r/120/diff/ [01:04] davecheney: cool. will look shortly. [01:06] kk [01:34] davecheney: apparently the review request is private and I'm not allowed to look [01:45] davecheney: I don't think you've hit publish yet [01:50] menn0: wut [01:50] is there a flag to rbt to say "yes, i'd actually like to review this " [01:50] done [01:50] menn0: try againplease [01:53] menn0: i've got a few more changes like this that are trying to pull apart the multi watcher to make it more unstandable (for me) [02:00] davecheney: finished chatting to Tim now. looking at your change. [02:02] davecheney: Ha ... I kept reading InfoId and "Infold" [02:02] s/and/as/ [02:04] axw: sha'ping [02:04] rb is a useless sack of shit [02:04] if it do rbt post on a branch that has already been posted, it creates a new review [02:05] % rbt publish 120 [02:05] ERROR: Error publishing review request (it may already be published): Object does not exist (HTTP 404, API Error 100) [02:05] why is this an error ? [02:05] can't the tool look at the status of ther view and see it's been published [02:07] menn0: what is the command to upload a new diff to an existin greview ? [02:07] "rbt post -r " [02:07] rbt can rbt remember that an existing branch is attached to a review ? [02:09] ok, that review is totally screwed [02:09] just getting 500's [02:09] i'll make another one [02:09] http://reviews.vapour.ws/r/120/diff/# [02:09] should be correct now [02:10] davecheney: review of 120 done. thumper needs to meta-review. [02:11] menn0: I have to remove that type because otherwise I cannot break the import look between apiserver/params and state/multiwatcher [02:11] menn0: fwiw, i disagree with your comment [02:11] this type adds nothing in terms of type safety [02:11] davecheney: I know you do, we've discussed this before :) [02:12] it leads people to think that f(id multiwatcher.InfoId) takes things of a specific type [02:12] (it doesnt') [02:12] davecheney: I know it doesn't add type safety but it does add the other benefits I mentioned [02:12] and I am neurtral on the reability argument [02:12] * thumper looks [02:12] davecheney: if it helps with the import loop breaking then let's do it. that's a bigger win. [02:13] kk [02:13] davecheney: probably should have mentioned that reason in the commit message or review description [02:14] yes, my bad [02:14] * menn0 is out for a bit. errands to run. [02:36] reviewboard is telling me I have -1 Open incoming reviews [02:36] now i have -2 [02:50] anyone seen this failure ? [02:50] http://paste.ubuntu.com/8452331/ [02:50] it's sporadic [02:56] http://reviews.vapour.ws/r/122/diff/ [03:22] menn0: can you tell me how to do a dependent change with rbt ? [03:22] i'm guessing there is a flag for rbt post [03:28] davecheney: I've never done it myself but I believe it hinges on the --parent option [03:30] davecheney: re that failure - I have seen it before but it looks like a ordering problem that might be fixed by using SameContents [03:36] menn0: same [03:36] lp has forgotten my login [03:36] i'll log a bug when I go downstairs and get my key for 2fa [03:36] davecheney: k [03:37] menn0: if you ahve time, http://reviews.vapour.ws/r/122/diff/ [03:37] opens the door to my next fix which makes params.EntityId an interface [03:39] davecheney: give me a little while [03:42] client_test.go:2448: c.Assert(client.AddCharm(curl), gc.IsNil, gc.Commentf("goroutine %d", index)) [03:42] ... value *params.Error = ¶ms.Error{"", "cannot add charm to storage: unexpected deletion of resource catalog entry with id \"47d6e7812099383e8266f590d37b7f5369ef43931aecc72a4b86674e7052f346a391648 [03:42] 209b8e69ea5b649d2c0e86da0\": Resource not available because upload is not yet complete"} ("cannot add charm to storage: unexpected deletion of resource catalog entry with id \"47d6e7812099383e8266f590d [03:42] 37b7f5369ef43931aecc72a4b86674e7052f346a391648209b8e69ea5b649d2c0e86da0\": Resource not available because upload is not yet complete") [03:42] ... goroutine 0 [03:42] [LOG] 0:00.462 DEBUG juju.storage managed resource entry created with path "environs/90168e4c-2f10-4e9c-83c2-feedfacee5a9/charms/cs:precise/wordpress-3-082e539d-946e-44ef-8684-489fc4bcfc3f" -> "47d6e78 [03:42] 12099383e8266f590d37b7f5369ef43931aecc72a4b86674e7052f346a391648209b8e69ea5b649d2c0e86da0"more [03:42] more intermediate failures [03:51] axw: ping [03:55] menn0: where are we on these branches? [03:55] davecheney: re 122 above, shipit [03:55] thumper: just about to push the API server change again [03:55] thumper: ta [03:56] thumper: then one more manual test of the env uuid unit change and that can be merged [03:56] menn0: ok [03:56] menn0: let me know when I need to look at that review again [03:57] thumper: just manually testing that branch now [03:58] kk [04:01] thumper: ok. http://reviews.vapour.ws/r/119/ [04:01] * thumper looks [04:03] menn0: still LGTM [04:03] trying to auth as an aribtrary user is pretty gross [04:04] would you consider raising a ticket/card/smoke signal [04:04] to have a proper method added somewhere to do this ? [04:04] menn0: one small thing [04:05] menn0: now that we are treating any error as maintenance in progress [04:05] davecheney: *nod* I'll create a ticket [04:05] menn0: you don't really need to create a fake user tag [04:05] menn0: you could just pass through the agent tag [04:05] thumper: well not quite [04:05] no? [04:06] thumper: the loging validator in jujud returns nil for the local machine [04:06] ah... [04:06] * thumper nods [04:06] thumper: because the local machine is always allowed to login [04:06] yeah... [04:06] thumper: but if that breaks due to db migrations then we still want to know we're in upgrade mode [04:07] got it [04:07] please add that to the comment [04:07] thumper: ok [04:07] so the next person doesn't change it [04:07] thumper: and as per davecheney I'll add a TODO referring to a ticket to get this done in a cleaner way [04:08] thanks [04:08] the next person will probably be me [04:08] and i'll go through trampling that [04:15] % echo $? [04:15] 0 [04:15] sweet, sweet, tests [04:16] number of tests run: 0 [04:20] thumper: do you want to see that change again or should I land it? [04:27] hmm my env uuid for units branch is getting lots of merge conflicts with upstream ... for files I haven't touched [04:27] I wonder what's up with that [04:27] thumper: menn0 i think i'm at the point that I have to stop nibbling around the edges and invert the dependenceies between state/multiwatcher and apiserver/params [04:35] menn0: just land it [04:35] thumper: doing it now [04:36] davecheney: I'm ok with that [04:36] menn0: NFI re conflicts [04:37] thumper: it's ok. there were tiny unit env uuid changes in those files. lots of conflicts with recent ports ports. [04:37] thumper: i'm almost done resolving. [04:37] ugh [04:37] ok [04:45] * thumper EODs [04:45] dog walk time === uru_ is now known as urulama [05:47] morning all [05:48] tasdomas, as OCR, can you please review http://reviews.vapour.ws/r/117/ ? [05:52] fwereade, jam, TheMue, you might be interested as well ^^ [05:53] morning dimitern, looking [05:53] jam, cheers! [05:59] dimitern: I'd like to see it tweaked, but I'm willing to discuss it [06:03] jam, thanks, I realized I've missed something [06:03] dimitern: what's that? [06:04] jam, we shouldn't be opening and closing ports like that at every hook commit [06:04] jam, even though there won't be an error as they will be opened or closed already [06:04] dimitern: do you commit hooks before they are done? [06:05] ah, this is pre-populated, not the stuff which is currently changing [06:05] dimitern: yeah [06:05] jam, it's not pre-populated because I realized it needn't be [06:05] jam, the uniter hook commands is the only way to open and close ports on *that* unit [06:07] jam, so we should cache what's opened and closed, to show it later with the opened-ports hook tool (in a follow-up), but use temp lists for pending ports, which are cleaned up at hook commit time [06:11] dimitern: sgtm [06:31] morning === barrypri1 is now known as barryprice [06:47] jam, updated - http://reviews.vapour.ws/r/117/diff/1-2/ [06:49] dimitern: so why do we track "Closed" ports in the portRanges map, isn't everything closed that hasn't been opened ? [06:50] or this is both "things I've requested" and "things that were already there" [06:51] jam, I was thinking we can have both "opened-ports" and "closed-ports" hook tools in a follow-up, which will use the map [06:51] jam, it might be useful for charms to see what ports it requested to be closed as well as opened [06:51] dimitern: k, "opened" or "opening" ? I'm just trying to figure out what portRanges buys us above just openingPorts and closingPorts [06:53] jam, the portRanges map is not reset between hooks, unlike the slices [06:54] jam, and they need to be reset so we don't unnecessarily issue api calls on each hook commit for the port ranges already opened before [06:55] morning [06:55] morning TheMue [07:01] dimitern, I've submitted a review [07:02] dimitern: am I *very* choppy ? [07:02] or just a little? [07:02] tasdomas, cheers, I've updated the review and some of your suggestions are implemented, can you take another look? [07:14] dimitern, is there a need to add the OpeningPorts and ClosingPorts methods to the interface? [07:16] tasdomas, what do you suggest instead? [07:19] dimitern, am I missing something or are they only used in tests? [07:19] tasdomas, for now yes, but this might change [07:20] tasdomas, but then again, it makes sense to only add them to export_test [07:20] dimitern, exactly [07:20] as of today [07:25] fwereade, ping [07:28] dimitern, I'm also a bit concerned about how conflicting operations will be handled [07:29] dimiter, open(100-200) followed by a close(100-200) should probably result in a nop? [07:29] dimitern, unless 100-200 was already open [07:32] dimitern, heyhey [07:32] tasdomas: I'd probably say "yes but that is a bit of an edge case in a buggy charm" so we're allowed to have it be slightly undefined behavior [07:32] because you'd have to determine that the first open() is actually the noop. [07:32] If we really want it, then we could make the total list of open + close ordered [07:33] so one slice with (true, 100-200), (false, 100-200), (true, 100-200) etc [07:33] morning fwereade [07:33] jam, heyhey [07:33] fwereade, I'd appreciate it if you find some time to review my open/close-port sandboxing branch http://reviews.vapour.ws/r/117/ - and read a bit of scrollback with comments from jam and tasdomas [07:34] dimitern, will do, but I have to do gsamfira's ones first of all [07:36] fwereade, sure [07:37] fwereade, it will be easier maybe if we do a quick g+ talk when you can [08:06] dimitern, ok, I had a quick look at that because it seemed smaller ;p [08:06] dimitern, the things I immediately wonder are: [08:07] dimitern, do we have some mechanism for checking against what's already opened/closed? [08:07] dimitern, and, how will we integrate this with per-relation port open/closes? [08:08] fwereade, well, that's why I suggested a g+, it will be easier talking than typing [08:08] dimitern, ok then :) [08:30] jam, tasdomas, ok, after a chat with fwereade I'll discard http://reviews.vapour.ws/r/117/ and do a prereq first that adds a method to uniter api to retrieve all machine ports and cache them in the uniter, so we can both check for conflicts and do sandboxing [08:31] dimitern: well, I would guess you can use most of what you already have, just an extra step at the start? [08:32] dimitern, understood - I was thinking about that solution, I'm just worried that there would still be a window present, where conflict could emerge [08:34] tasdomas, even with the extra checks against machine ports, there will still be a very minor possibility for open/closePorts to fail at finalize time, but that's OK, as we'll catch and handle most other cases [08:35] dimitern. sound good to me === fabrice_ is now known as fabrice|lunch [10:48] TheMue: standup? [10:48] omw [11:23] morning [11:24] i just wanted to use juju with a local environment. it's not working... anyone got any idea of what might be happening here and how I might be able to fix it? http://paste.ubuntu.com/8454648/ [11:26] hmm, perhaps it was as simple as just apt-get install lxc. somehow that must have got uninstalled at some point. [11:26] ha, it works now. phew. [11:26] those error messages were not great though. [11:33] wow, that is a bit of a mess rogpeppe [11:33] mgz: mmm [11:33] I was expecting the "must install juju-local" message === fabrice|lunch is now known as fabrice [11:49] fwereade, jam, http://reviews.vapour.ws/r/123/ - uniter api changes, as discussed [11:49] dimitern, cheers, just popping out but back shortly [11:49] fwereade, sure, np [12:45] dimitern: my first thought is "why does *Uniter* have a Machine implementation", it seems the wrong thing for a uniter to think about. [12:45] maybe it needs to know the machine it is on isn't dying? [12:45] jam, because the ports are on the machine, not on a unit anymore [12:46] jam, and the only reason to have a Machine object is to be able to call AllPorts() on it [12:47] dimitern: so looking at the data structures, you expose MachinePortsResults which holds a slice of MachinePortsResult which holds a slice of MachinePortRange which uses a UnitTag and a PortRange [12:47] but nothing there uses the NetworkTag [12:47] And what do we do if more than one Unit asks for a similar port to be open? [12:47] Is it just a conflict ? [12:51] jam, the idea is to return all ports on the machine, regardless of network [12:52] jam, when more the one unit tries to open a conflicting range, we'll detect and not allow it to happen [13:00] dimitern: but especially in the case of ranges, saying "I want these open" doesn't actually have to be a problem does it? [13:02] jam, I'm not sure I follow - can you expand a bit? [13:03] if I say "i need this machine to expose 10-100, and someone else says 90-200", we could just open 10-200 and be done [13:03] I suppose it would be clearer for the charm to fail with "you can't actually use 90-100" so it doesn't try to configure the application to use them? [13:06] dimitern: ^^ [13:07] jam, nope [13:08] dimitern: nope ? not sure what you are saying no to [13:08] jam, if unit 0 says open 10-100/tcp, that's fine; later unit 1 says open 90-100/tcp - there's a conflict and we won't allow it [13:08] jam, we can't have concurrently running open-port requests, as there's only one hook running at a time on the machine [13:14] jam, port ranges are bound to units that requested them, so 10-100/tcp + 90-200/tcp for different units != 10-200/tcp === ericsnow_ is now known as ericsnow [14:02] perrito666, natefinch: standup [14:03] wwitzel3: going [14:03] wwitzel3: coming one sec, grabbing my coffee from the other room [14:04] natefinch: wwitzel3: did you see the email from menno about syslog and cert issues? [14:05] jam: yep, the one about log message spam? [14:05] wwitzel3: about not being able to connect because of an issue with "no IP SANs" [14:05] after upgrade [14:05] jam: looking at it now [14:06] wwitzel3: k, I'd chat with nate about it, because I think he discovered the golang issue for the HTTP API stuff [14:06] I think the issue is that whatever workaround we did for the API we need to do for syslog [14:07] jam: ack === jheroux_away is now known as jheroux [14:26] fwereade, ping [14:26] alexisb, pong [14:26] hey there [14:26] do you mind if I reschedule our 1x1? [14:27] my little guy is still sleeping and I dont want to wake him to go to his nanny given he has been sick [14:27] so I will be on the road for our normally scheduled time [14:27] fwereade, ^^ [14:27] alexisb, np [14:27] thanks [14:28] any particular day that works best for you? [14:31] fwereade, ^^ [14:31] alexisb, tomorrow isn't great, how about weds? [14:32] alexisb, or thurs? [14:33] I can do a thursday morning, I will reschedule for them, thanks for being flexible fwereade ! [14:33] alexisb, no worries, glad to be of service === kwmonroe_ is now known as kwmonroe [14:38] natefinch: FYI, I fixed that issue on http://reviews.vapour.ws/r/103/ [14:40] ericsnow: can you print the name and the type of the value, instead of a generic string? Would make debugging easier. [14:40] natefinch: sure [14:41] natefinch: you know, you can leave comments on the review :) [14:41] ericsnow: sometimes it's faster just to talk on irc, but I just left a message there too [14:41] natefinch: thanks [15:41] fwereade, didn't you have some writing provider getting started docs? not seeing them in tree.. got a partner thats interested === fabrice is now known as fabrice|family [15:50] fwereade, TheMue, jam, tasdomas, re-proposed open(close)-port sandboxing for the uniter, please take a look http://reviews.vapour.ws/r/125/ [16:39] mgz: this error looks suspiciously like a build script merge failure - [16:39] /var/lib/jenkins/juju-release-tools/make-release-tarball.bash: line 115: syntax error near unexpected token `<<<' [16:41] natefinch: do we have a UTC-0400 to -0700 timezone person who knows the build server stuff? [16:42] perrito666: surely I can count on at least you to be around :) [16:43] that looks odd [16:43] whew [16:43] mgz: still not sure if that's the issue but the last couple builds failed with that error [16:43] wassit on? a landing? [16:43] okay, fixing. [16:44] yep [16:44] http://juju-ci.vapour.ws:8080/job/github-merge-juju/837/ and http://juju-ci.vapour.ws:8080/job/github-merge-juju/838/ === seelaman is now known as IS_hr_bot [16:44] yup... conflictishy [16:45] okay, should work now [16:45] wow. thanks mgz [16:45] I'm also going to make another change with some fixes, will notify when it's through === IS_hr_bot is now known as seelaman [16:46] thanks mgz should we start to land again or wait for your fixes? [16:46] try a landing now if you're waiting [16:46] k [16:50] mgz++ === niemeyer_ is now known as niemeyer [17:55] natefinch: could you have another look at 103? [17:57] ericsnow: ok [17:58] natefinch: thanks [18:01] ericsnow: ship it [18:01] natefinch: thanks === uru_ is now known as urulama [20:55] thumper: fyi we got some new info @ https://bugs.launchpad.net/juju-core/+bug/1375268 [20:55] Bug #1375268: Juju Panic'ing on MAAS Power8le Environment

[20:55] arosales: ta, looking [20:55] thumper: natefinch had done some debug to identy the panic, but didn't have anything conclusive [20:56] arosales: I've read all that... [20:56] thumper: let us know if you need any other info, or access [20:56] access to the maas would be helpful [20:56] and the instance that is having problems [20:56] mbruzek: do you have docs you can send over to thumber on accessing the maas IBM system? [20:56] the logs don't show any information for the stack frame that actually is the one panicing [20:57] which is somewhat surprising to me [20:57] arosales: mbruzek: info also to davecheney plz [20:57] mbruzek: also be interesting to see if you have reproduced on the other maas environment [20:58] thumper: arosales I will send that out right now. Tim from IBM needs to make him an account. We could jump in a hangout if you want to see my screen now. [20:58] mbruzek: I have meetings starting in a minute for a while [20:59] mbruzek: I guess the VPN is specific to individuals [21:22] davecheney: are these the lines that indicate a bad compiler? juju[5386]: bad frame in setup_rt_frame: 0000000000000000 nip 0000000000000000 lr 0000000000000000 [21:24] yes [21:24] thumper: hold fire [21:24] writing you a long email so that you too can know all there is to know [21:27] wow an email containing "all there is to know" must be instanely long [21:34] I would really dig doc strings on things like state/watcher.go [21:35] perrito666: brevity is not my strong suit [21:36] * perrito666 imagines thumper getting an email with 42 as body text [21:46] I would also dig a trackball, I have too much junk on my desktop to be able to move the mouse :/ [22:18] thumper: per our hangout last week: http://reviews.vapour.ws/r/127/ [22:19] jcw4: cheers, will look when I have the kids back from swimming :) [22:19] menn0: it's about EnvUUID so your feedback appreciated too :) [22:19] thx thumper === thumper is now known as thumper-afk [22:33] jcw4: having a look [23:04] jcw4: review done [23:06] menn0: much appreciated [23:07] menn0: tx for your mail it was enlightening [23:12] perrito666: good! it was useful for me to write it. I learned a few things while making sure I was giving you correct information :) [23:15] sadly I cannot have a watcher since I am nuking the db in this process so I am looking another way to signal my worker [23:31] http://reviews.vapour.ws/r/126/ [23:31] what's going on here [23:32] i thought that backups were going to be streamed back to the client, not shoehorned into the api server [23:33] davecheney: as per fwereade design and I believe we agreed on that in Las Vegas, backups are stored in the state server and downloaded on demand [23:33] Iam not sure if any of those things include shoehorning since I am having some difficulty picturing the meaning of it in my head :p [23:34] perrito666: yes [23:34] that is no in question [23:34] davecheney: That patch provides all the boilterplate needed plus a very basic implementation of the data transfer [23:34] but downloading them via encoding them into json is bad [23:34] davecheney: I agree sending a []bytes over the wire is not a valid solution [23:35] ericsnow: i thought the plan was to add some bulk download api [23:35] i thought that had happened [23:35] davecheney: not that I'm aware [23:36] bummer [23:36] davecheney: I agree that download should support bulk calls [23:36] davecheney: upload as well (when we get to that) === thumper-afk is now known as thumper