=== mramm2 is now known as mramm [00:14] ericsnow: given we have stuff that needs to be landed for 1.23, would it be worth reverting the commit that is blocking landings [00:14] wallyworld_: it (systemd support) needs to be in 1.23 too, but otherwise yeah [00:15] ok [00:15] wallyworld_: I'm hopeful I can find the problem in the next bit [00:15] rightio [00:15] wallyworld_: it's a matter of trying to decipher the CI logs [00:15] fun [00:25] thumper: sinzu I have a replacement gccgo-go package that fixes the test problems with 1.23 [00:25] how/when do you want it ? [00:41] a/win10 [00:42] davecheney: alexisb has passed on the power patch to wes and they are dealing with the foundations (or whatever team) to get it landed [00:43] right o [00:43] just to repeat [00:44] i have a replacement deb that we can install on the ci machines to get the tests passing === kadams54-away is now known as kadams54 [01:16] ericsnow: I think there is another presentation of the map-ordering bug in systemd service_test.go : http://paste.ubuntu.com/10508907/ [01:17] ericsnow: I'll file an LP bug for it, but thought you'd like to know [01:17] jw4: is that different from https://bugs.launchpad.net/juju-core/+bug/1427149 [01:17] Bug #1427149: Tests require predictable map ordering [01:17] jw4: ? [01:17] ericsnow: it's different presentation [01:17] ericsnow: not sure if it's different root cause [01:18] jw4: pretty sure it's the same cause [01:18] ericsnow: I think it is different because the other one seems to be related to listing services and this seems to be related to order of an emitted config file [01:19] jw4: k [01:19] ericsnow: but yeah, same issue with map ordering being unpredictable in newer versions of go [01:20] Bug #1427454 was filed: systemd tests depend on map-ordering [01:20] nice new feature mup... who taught you that trick? I started noticing it this past weekend [01:27] could I get a review on http://reviews.vapour.ws/r/1053/? [01:28] it is for unblocking CI [01:35] ericsnow: ungraduated, but LGTM === kadams54 is now known as kadams54-away [01:39] jw4: thanks [01:40] wallyworld_: could you take a quick look? [01:40] * wallyworld_ looks up [01:41] ericsnow: done [01:42] thumper: thanks [01:43] ericsnow: i asked for a todo for better test coverage [01:43] wallyworld_: k [01:44] there's a few corner cases and logic in there that would be good to test [01:44] transient, desc == "" etc [01:44] wallyworld_: good point [01:46] perrito666: you're oncall reviewer right? Could you take a look please: http://reviews.vapour.ws/r/1054/ [01:46] waigani: perrito666 is or should be asleep [01:46] wallyworld_: well that's no excuse! [01:47] indeed [01:52] I'll be AFK for a bit, but the merge job is running and if it lands the local-deploy-vivid-amd64 job should kick off (with hopefully successful results) [01:54] waigani: thanks to the magic of timezones I am not OCR for a couple of hours more [01:54] perrito666: you're awake! but you shouldn't be [01:54] waigani: but, I am a nice enough person and Ill review it, although you will have to explain to my wife why I am reviewing code in bed [01:54] perrito666: no don't seriously it's okay === kadams54-away is now known as kadams54 [01:56] open question [01:57] there is a page, i think somewhere on cdimages.u.c that gives you links to amazon to try any cloud image [01:57] does anyone know what I am talking about [01:57] does anyone remember the page [01:58] https://cloud-images.ubuntu.com/vivid/current/ [01:58] it's this one [02:03] waigani: reviewed [02:04] davecheney: btw, I reviewed waigani's :p [02:04] perrito666: thank you, now sleep [02:05] waigani: I need to wait that the soap opera my wife is watching ends (I want to know the ending now that I saw the beginning) [02:09] Get:24 http://ap-southeast-2.ec2.archive.ubuntu.com/ubuntu/ vivid/main gcc-4.9 amd64 4.9.2-10ubuntu7 [5,656 kB] [02:10] 35% [24 gcc-4.9 5,647 kB/5,656 kB 100%] 98.3 kB/s 8min 7s [02:10] go cloud images [02:10] go ... slow [02:11] i've let mr howard know === kadams54 is now known as kadams54-away [02:25] * thumper disconnects to focus on finishing this branch by the EOD [02:27] the CI test is queued up that will verify the blocker bug is resolved === beisner- is now known as beisner [03:02] wallyworld_: just noticed something weird in validateVolumeParams: it's setting params.Pool to the default internally. why is it doing that? that value won't surface, since the params are by-value [03:03] the Pool should be != "" by the time validation occurs [03:03] let me look [03:08] axw: yeah, that looks like a mistake [03:09] wallyworld_: nps, I'll need to make updates in this area in my branch \ [03:09] so I can fix it [03:09] ty [04:18] Bug #1427501 was filed: api/networker: test failure due to map ordering [04:27] Bug #1427505 was filed: apiserver/networker: test failure due to map ordering [04:34] axw: that maas doc, we need to provide feedback on the storage API result data at the bottom of the doc [04:34] wallyworld_: ok [04:34] we can take a day or so to do it [04:35] i'll look tomorrow [04:40] Bug #1427508 was filed: cmd/jujud/agent: test failure [04:48] Bug #1346597 was filed: cannot get replset config: not authorized for query on local.system.replset [04:56] Bug #1427510 was filed: version: tests do not parse on a fresh machine [05:25] axw: i've put up a charm.v4 pull request https://github.com/juju/charm/pull/88 [05:25] looking [05:26] wallyworld_: I just proposed a rather larger change: https://github.com/juju/juju/pull/1725 [05:27] ok, np, i have to go to soccer soonish, but will look either now or when i get back [05:31] o/ hi, good evening! [05:32] fyi bug 1420049 updated [05:32] Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") [05:38] axw: i kinda think we should have storage properties - the spec does seem to discuss expected behaviour - perhaps jam has a view? easy to ignore if we don't need them [05:38] s/ignore/omit [05:39] wallyworld_: it "kinda" does, but it's not very clear. see my unanswered question in the doc [05:40] wallyworld_: the main problem is that once they're in there, we can't easily change it [05:40] wallyworld_: is it possible to just have the attribute ignored but not error if it's supplied ? [05:41] yeah, i know the question. i think it's a more of a charm author hint - "i don't care if this data disappears as it's just a cache". [05:42] sure, i=we can set the attribute but the stroage provider doesn't need to act on it if that's what yu mean [05:42] wallyworld_: I mean, don't even expose it in the output, or define any kind of structure for it [05:42] wallyworld_: I really can't see us using it until after phase 1 [05:43] ok, let's discuss with jam [05:43] wallyworld_: no [05:44] no, don't discuss with jam? ;) [05:44] no what? [05:44] wallyworld_: I won't discuss it. I came in late to the discussion. what's up ? [05:45] sorry, needed a :) [05:45] jam: the concept of torage properties eg transient [05:45] jam: we're discussing the merits of "properties" in storage metadata [05:45] the spec isn't 100% clear [05:45] eg are they hints or reuirements [05:45] jam: context: https://github.com/juju/charm/pull/88 [05:45] we're not sure whether to add support in charm metadata for them [05:46] do we need to support transient storages for phase 1 [05:47] wallyworld_: I'm pretty sure transient was meant to be a hint, rather than a requirement [05:47] "which providers may take to mean" [05:48] "may" is pretty clear there [05:48] jam: that's my take on it as well [05:48] can the name be changed to reflect this? [05:49] e.g. hints [05:49] you mean the name "Properties"? [05:49] right [05:49] * wallyworld_ has no opinion either way [05:51] wallyworld_: axw: so I'd like to avoid revising the charm metadata multiple times. And while 'transient' is just a hint, others may be less of a hint. Do we need to rev the charm metadata format if we allow more entries? [05:51] I suppose we don't if we only put hints in there. [05:51] I don't like the word "hints" per se [05:52] maybe its ok in a storage block [05:52] i'm not sure about the need to revise and the new values or totally optional [05:52] are [05:52] so old metadata will parse just fine [05:53] jam: we won't need to rev for additional property/hint names, I just don't think "properties" really reflects that it's optional [05:53] and charm authors may be surprised that it doesn't do what they think it does [05:54] axw: I believe the discussion was always around hinting, with some other ideas like fast etc. So the provider could know about high-iops storage and map the request over to that storage. [05:55] I guess whether or not it's a hint is on the actual value, then [05:55] okay [05:55] wallyworld_: leave it [05:55] I rescind [05:55] ok [05:56] axw: so I'm happy to bring up hints vs properties. I don't feel like I have final call, but if you want I can bring it up to Mark. [05:56] jam: I think it's fine, as long as we're clear when describing specific properties [05:57] jam: one other thing - trunk is blocked due to a vivid systemd issue. IMHO that's not a regression since we've never supported vivid yet and systemd work is WIP. what's your view on that? [05:57] it will be at least 16 hours before trunk could be unblocked and we got goamz and leader eections work to land [05:57] for 1.23 [05:57] wallyworld_: It depends. if it is a platform thing (like the gccgo bug) then I hesitate to let it block trunk (not something we can just fix) [05:57] wallyworld_: if it is something we did that doesn't work on V then we need to fix it [05:58] V is high priority to support [05:58] wallyworld_: because until it is in V it won't be backported to T [05:58] (standard Ubuntu rule is to be in the latest release and then backport it to the LTS) [05:58] jam: well, upstart always worked on vivid with juju. but we are targetting systemd i believe, and that's what in't uire rught yet [05:59] it seems silly to block on a new juju feature being developed for an unreleased series [05:59] it's just something that needs fixing for sure, but to block everything on that? [05:59] wallyworld_: blocking trunk because it is unreleasable helps us prevent adding more bugs into the system. We have a *very* bad track record here [05:59] so I'm definitely biased towards blocking [06:00] cause we keep breaking shit [06:00] and then break something else by the time we fixed the last one [06:00] sure. we block on regressions. IMO this isn't a regression [06:00] it's a new feature that is broken [06:00] wallyworld_: we can't release trunk because a key platform we want to support is broken [06:00] wallyworld_: then revert it [06:01] we may have to [06:01] or we can't because we have to use systemd for vivid [06:01] if we want to change the block policy to a key unreleased platform being broken, that's fine, but we need to make that clear [06:02] since strictly speaking it's not a regression [06:06] wallyworld_: I'm pretty sure supporting V is a must for 1.23 since it is targetted to V [06:07] yes, agreed, but thst something is broken is not a regression [06:07] it's a new feature that has a bug [06:07] therefore trunk should not be blocked [06:07] wallyworld_: support for a critical platform is enough to be a critical blocker even if it isn't a regression [06:07] wallyworld_: if 1.23 was split of trunk already then yes, don't block trunk [06:08] I don't think that split has been done yet [06:08] that's a new policy decision then [06:08] no, 1.23 not branched yet [06:08] waiting on leader elections and goamz but these are now queued [06:08] wallyworld_: if CI tests can't pass, then we risk breaking it for a new reason if we continue to land code. [06:09] wallyworld_: are we *not* waiting on V support [06:09] it's CI on one test only - vivid [06:09] that seems like it would fall into that bucket of blocking 1.223 [06:09] 1.23 [06:10] we are waiting on it yes [06:10] but systemd being broken seems unfortunate to block unrelated landings on [06:10] wallyworld_: I'm certainly willing to be pragmatic, our track record has just been so bad in this area [06:10] agreed about track record [06:11] wallyworld_: all last december we could not release trunk because we would break Y while X was getting fixed [06:11] here it's one CI test (vivid) [06:11] if anything else breaks, stop the line for sure [06:11] but it's a vivid specific (new) feature [08:15] morning o/ [08:53] morning o/ [08:55] * fwereade has an old old laptop whose hdd has started making happy fun clicky noises; going out to get another; might be a little while [09:21] :( hdds should be seen and not heard [09:46] axw: hdds should be on a hidden place of the house onnected to a storage server :p [09:46] which is what I did with al the hdd I gradually replaced [09:47] perrito666: :) [09:47] * axw pats his NAS [09:48] axw: I actually have a thinkpad with a lot of usb adapters :p I could not get a decent nas here for less money than what a cheap car costs :p [09:51] hdds shouldn't be needed, large and fast flash as ram replacement instead, non-volatile and networked === Murali_ is now known as Murali [10:39] minihdmi is really bad idea === kadams54-away is now known as kadams54 [13:54] mm why do we have structs that take pointers to ints? [13:55] perrito666: if you want to have the possibility that they are nil [13:55] perrito666: to indicate they are unset [13:56] perrito666: while 0 or any other value may be valid [13:56] TheMue: ah that makes sense, perhaps they are values where 0 is meaningful and cannot be used as empty [13:56] yeah, what themue said [13:56] perrito666: exactly [13:57] sometimes there may actually be a better way of doing the same thing, but there are also compat issues [13:59] I am seeing a rather creative solution in a review which strikes me as a bit strange but I guess there is no other way [14:00] perrito666, mgz, TheMue: the general principle is "avoid in-band signalling", it's the same as the motivation for returning `, bool` even when a nil return would theoretically convey the same information [14:01] fwereade: hey, wb, how was the laptop hunting? [14:01] perrito666, pretty good, it even had ubuntu preinstalled [14:01] fwereade: sweeet [14:01] fwereade: then a struct { myInt int; myIntOK bool } could do the same ;) [14:01] might I inquire what did you get? [14:02] perrito666, dell latitude e6540 [14:02] * TheMue thinks of structs with many of those fields [14:02] perrito666, yay certified hardware :) [14:02] TheMue, yeah, that's true, and might even be the way to go sometimes [14:03] TheMue, it's a bloody hassle constructing test data with points to ints/strings [14:03] this case has a function that returns an int pointer [14:04] imho swift has a way to signal if a value is unset [14:05] perrito666, it is hard to think of a good reason for that [14:05] * fwereade wonders if he wrote it himself [14:05] perrito666: you need to link the review now, we've been talking about it for 5 minutes [14:06] http://reviews.vapour.ws/r/1049/diff/# [14:06] look for uint64p [14:07] okay, I think that falls under the compat requirements heading [14:08] we could change the constraints struct to seperately record which constraints are actually set, but that's not how it's currently done [14:11] * fwereade is obscurely pleased to note that it is indeed all his fault [14:12] :) [15:24] could I get a review on http://reviews.vapour.ws/r/1056/ [15:24] it unblocks CI [15:24] yes you can [15:26] ericsnow: may I suggest a different path of action? [15:26] perrito666: I'm all ears :) [15:27] ericsnow: delete the code and before committing make a patch to revet that and save it for quick usage, but dont comment out code [15:27] perrito666: I'm fine with that [15:28] ericsnow: sorry I am a pruit sometimes [15:30] +1 for not committing commented-out code [15:30] though if it's a very small amount with a very clear comment as to when it'll be un-commented, that's ok [15:31] natefinch: it is :) [15:31] natefinch: but that's fine [15:31] ericsnow: the nice thing about that is that the diffs are easier to read than delete/readd [15:31] well its not like you cannot revert that commit lateron with git [15:32] ericsnow: want to do our 1 on 1, or do you want to keep cranking? I know you've been pushing hard to get this stuff done, and I don't want to break your stride [15:32] natefinch: we can meet [15:35] ericsnow: do the unit tests pass with that change? I'd expect commenting out some of the linuxExecutables to fail that test that checks 'em [15:36] ericsnow: I do think a revert at this point to unblock is sensible - if you need help testing before landing an un-revert I'll be happy to help [15:36] mgz: the patch includes updating the test that is impacted [15:36] ericsnow: so it does [15:53] I have a painfully specific question about hook tools. As open-port can now specify a range, what if there is a conflict on _part_ of the range? i.e. I try and open 80-100 but 80 is already open: do I get 81-100 or nothing? [15:54] evilnickveitch: my guess is that a conflict will mean it does nothing. [15:54] evilnickveitch: but I can look at the code to know for sure [15:55] natefinch, if you could, that would help - i do like to be as precise as possible (its for the docs) === beisner- is now known as beisner [16:06] evilnickveitch: sorry, got disconnected, did you see my last message about any overlap being a conflict? [16:07] natefinch, I did not, but now I know - thanks so much, it would have taken me far longer to work it out! [16:26] Bug #1427454 changed: systemd tests depend on map-ordering [16:26] Bug #1427454 was filed: systemd tests depend on map-ordering === anthonyf is now known as Guest62520 [16:26] Bug #1427454 changed: systemd tests depend on map-ordering [16:45] Bug #1427454 was filed: systemd tests depend on map-ordering [16:45] Bug #1427454 changed: systemd tests depend on map-ordering [16:46] Bug #1427454 was filed: systemd tests depend on map-ordering [16:46] Bug #1427454 changed: systemd tests depend on map-ordering [16:46] Bug #1427454 was filed: systemd tests depend on map-ordering === kadams54 is now known as kadams54-away [16:47] what are you up to mup... [16:47] naughty bot. [16:48] mgz: it has a hiccup, or better, a muppup [16:49] Bug #1427454 changed: systemd tests depend on map-ordering [16:56] Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms [17:13] mgz: how do I force local-deploy-vivid-amd64 to re-run? [17:14] on the same revision, rebuild will work [17:15] logged in as admin, select latest build of job, rebuild on the left [17:15] mgz: k [17:17] Bug #1427770 changed: opened-ports doesn't include ports opened by other charms [17:19] Bug #1427770 was filed: opened-ports doesn't include ports opened by other charms === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [18:56] ericsnow, i am consternated with https://github.com/juju/juju/pull/1727, just a comment [18:57] ericsnow, i was under the same impression [18:58] niedbalski: yeah, sounds like they are switching over in the next week or so [19:07] ericsnow: re-stamped [19:07] natefinch: thanks [19:19] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:20] Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:21] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:21] Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:21] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:22] Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:22] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:22] Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:23] sounds like mup could use a burst detection function [19:23] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:23] Bug #1427814 changed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:23] Bug #1427814 was filed: juju bootstrap fails on maas with when the node has empty lshw output from commissioning [19:24] really? [19:24] abentley: jog: I noticed that the reporting stuff has changed. [19:24] +1 [19:25] mbruzek, yes, URLs should still be the same. [19:25] jog: We got an AWS failure, looks like an infrastructure problem that you fixed last week. [19:26] jog: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10 [19:26] jog: is that the same error? [19:27] * jog looks [19:31] mbruzek, looking at the consoleText log deployer appears to have run fine while installing the bundle (I applied a patch for deployer last week). This looks like an error from 'juju terminate-machine' [19:33] mbruzek, hmm... maybe not, there's more to this log. [19:35] mbruzek, we saw this 'watcher was stopped' Error last week but I think it's different from the issue that was patched. [19:35] jog: OK [19:37] jog Is there a way to terminate the machines? (clean up aws) before I try again? [19:38] mbruzek, yes I can log into the AWS console and see what's still running. [19:40] jog: I kicked off amazon again to see if it works, but then I thought to ask my question. Feel free to kill that process if you think it will fail. [19:40] mgz: so how do I kick off local-deploy-vivid-amd64 against the latest revision? === kadams54 is now known as kadams54-away [19:49] mbruzek, tvansteenburgh, also once bundle configs start getting uploaded to S3 we should see links in the reports (I just sent you an email on that topic). [19:52] mbruzek: the env is destroyed at the start of every test, so you can just rerun - no need to manually cleanup [19:53] tvansteenburgh: OK. [19:53] tvansteenburgh: http://reports.vapour.ws/charm-tests/charm-bundle-test-parent-138/charm/charm-testing-aws/10 [19:53] tvansteenburgh: Have you seen this error before [19:55] this falls into the "my cloud broke, guess i'll try again" category [19:55] * mbruzek *sighs* [19:55] Thanks for taking a look. next test is running, hoping that one passes [19:55] it's most likely b/c we are competing for resources with the charm-bundle-test job [19:56] your env probably got destroyed out from under you [19:56] this will be fixed once we get RevQ using the new jobs [19:57] tvansteenburgh: ack. [19:57] tvansteenburgh: thank you [19:57] planning to sort that out in CO === kadams54-away is now known as kadams54 [20:33] local provider hates me [20:34] Bug #1427840 was filed: ec2 provider unaware of c3 types in sa-east-1 === kadams54 is now known as kadams54-away [21:28] katco: in another meeting, a few minutes late [21:29] wallyworld_: k ty === kadams54-away is now known as kadams54 [22:35] Bug #1427879 was filed: juju cannot deploy when distro-info-data gets a new series === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [23:16] Bug #1427210 changed: 'relative path in ExecStart not valid' vivid local deploy failure