[02:39] anyone familiar with the upgrade tests? I added upgrade steps to move the rsyslog config files from /var/log/juju to /var/lib/juju ... but the tests fail because the tests mock out a bunch of stuff and evidently don't set up the log directory. [02:47] axw_: wallyworld: backort of storage-add http://reviews.vapour.ws/r/1803/ [02:48] looking [02:49] axw_: \o/ === natefinch-afk is now known as natefinch [02:50] natefinch-afk: isn't t just a case of adding a LogDir() metod to fakeConfigSetter [02:51] wallyworld: could be. upgrade_test.go is 1000 lines long... finding what particular part I need to tweak in what particular way is not always obvious. [02:54] i just guessed by looking at what setup test did, hopefully it works [02:54] wallyworld: oh yeah, I didn't think to look at setuptest [02:55] actuially, matbe not setup test, i forgot what i looked at, but see NewFakeConfigSetter [02:55] it has some of the COnfig methods but not all [02:56] i find that both useful and difficult in Go [02:56] hard to know what implements what [02:59] we just mock out and fake out so much of our code to run the tests... it's hard to know what actual code is getting run. [03:01] every test we have runs hundreds of lines of setup code, most of which is very far away from the test itself. [03:09] wallyworld: I seriously have no clue how to even begin to do this. Adding LogDir() to fakeConfigSetter does not seem like it will populate that directory with the correct expected files. [03:09] it won't - you need to do that [03:09] with c.MkDir() [03:10] and then pass that dir to fakeconfigsetter [03:10] so it can be returned from the LogDir() func [03:10] just guessing [03:10] I can't even really tell where this test ends up creating a fakeConfigSetter [03:11] see TestContextInitializeWhenNoUpgradeRequired [03:11] looks like the test sets it up [04:21] thumper: reporting dropped log messages: http://reviews.vapour.ws/r/1804/ [04:22] thumper: btw, i really don't like the tests for logsender and I have a plan for reworking them to be more unit-testy === kadams54 is now known as kadams54-away [05:12] menn0: ack [06:32] wallyworld: FYI I have the deadlock in hand, just working through updating all the tests and so on [07:06] axw_: awesome, so the worker uses a tomb etc. did you get rid of the singleton? [07:07] wallyworld: I did, but now I'm putting it back (sort of) [07:08] wallyworld: it's a huge PITA to change all of the tests [07:08] yeah :-( [07:08] wallyworld: so I'm changing it so there's a worker, and it updates a singleton which you can call and will fail if there's no active worker [07:09] wallyworld: changing *most* of the tests was fine, but then JujuConnSuite things were a nightmare, because they have their own API server which needed to have resources threaded through... just not worth the effort right now [07:09] i hate jujuconnsuite [07:10] i'm off to soccer soonish, will look in more detail when i get back [07:11] wallyworld: sure. I've not proposed yet, still fixing tests [07:11] enjoy [07:11] will do, not quite leaving yet [07:16] axw_: with your change, will tests still need to start their own worker loop, or did you get to remove that ickiness too? [07:17] wallyworld: which tests? [07:17] wallyworld: the uniter tests will still need to [07:18] axw_: william put a worker loop in dummy provider, and menno also added one for some agent tests [07:18] hmmm, i think the agent tests are on master though [07:18] wallyworld: didn't see anything in dummy provider. I don't think my change will improve on that [07:19] maybe william's code not landed yet [07:20] if blocking calls were removed, that would help with the problem [07:20] i guess with your changes though, it's a matter of starting a worker rather than a loop directly [07:21] and maybe blocking calls can be aborted when the worker fies [07:21] dies [07:21] wallyworld: if the worker isn't started, lease/leadership calls will error out [07:21] wallyworld: so they won't hang forever [07:21] great, that's an improvement [07:21] wallyworld: not sure if that's enough to cover all the tests [07:22] gotta start somwhere [08:25] fwereade: http://reviews.vapour.ws/r/1806/ [08:25] FYI [08:25] wallyworld: ^^ [09:03] axw_, reviewed; basically awesome, but I have a few quibbles [09:03] fwereade, can you stamp http://reviews.vapour.ws/r/1777/ please? [09:06] wallyworld, axw_: and, yes, I suspect I didn't land the branch that put lease manager in the dummy provider, dammit, sorry [09:43] fwereade: I guess we don't really need an exported error for the BlockUntilLeadershipReleased call at all, do we? I could just create an error inline [09:43] axw_, true [09:43] axw_, but you need the same error in several circumstances, right? [09:44] axw_, so an unexported errStopped is probably a good idea [09:44] fwereade: just that one method in leadership, but I'll do that anyway [09:45] axw_, shouldn't claim and release have similar? [09:45] axw_, we don't want to leak the lease error to the clients, and we definitely don't want to let tomb.ErrDying out of the worker [09:45] fwereade: their cancellation happens in the lease package. so... I could export an error from there instead [09:46] fwereade: fair enough. ok, so I'll export an error from lease, but trap it in leadership and translate [09:47] I was hoping not to put that in the lease contract [09:47] axw_, well that's sort of why I was advocating a worker.ErrStopped [09:47] I see [09:47] ok then, that'll do [09:48] axw_, from the POV of a client it barely matters which worker was stopped or why [09:48] axw_, it's as simple as "I cannot fulfil your request because the necessary components are not running" [09:49] axw_, the non-running components ought to have their own failures logged anyway, so there's little benefit to leaking anything else out of the methods [09:49] fwereade: yep, sounds good [10:30] Bug #1459610 was opened: juju status --format=tabular > 80 characters wide [10:42] Bug #1459611 was opened: juju status --utc does not display utc and is confused [10:52] fwereade: updated, PTAL when you can [10:52] axw_, cheers [10:54] Bug #1459611 changed: juju status --utc does not display utc and is confused [11:00] Bug #1456957 changed: rsyslog worker should not add machines that are not ready yet

[11:00] Bug #1459611 was opened: juju status --utc does not display utc and is confused [11:00] Bug #1459616 was opened: 'juju status' timestamps should use rfc3339 or ISO8601 [11:03] sorry I missed the first half, but the last half was useful :) [11:14] wwitzel3: it was just as great for me too! I had all my questions answered :D [12:01] ericsnow: you ocr? can you look at http://reviews.vapour.ws/r/1805/ sometime during your day? [12:02] fwereade: just as an fyi ^^^^^ [12:02] since we discussed it [12:02] wallyworld, cheers [12:09] I'm outa here [12:31] perrito666, woudl you also cast an eye over http://reviews.vapour.ws/r/1805/ with a view to understanding how/whether it interacts with the restore-mode api [12:47] * perrito666 casts eyes [13:17] Is the environment UUID exposed in the API? [13:32] marcoceppi, Client.EnvironmentInfo [13:32] marcoceppi, and you get the tag, which is "environ-" when you log in [13:40] Bug #1459679 was opened: MinUnitsSuite teardown fails

[14:01] Bug #1459679 changed: MinUnitsSuite teardown fails

[14:04] ericsnow: ping === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:09] how can I go from a name to a Tag? [17:14] perrito666: ? [17:15] perrito666: what do you mean? [17:15] perrito666: you have string name? [17:16] yes, and I want a way to get a tag [17:18] perrito666: if you don't know the type, you can just use ParseTag which will switch over the different tag types for a match [17:19] perrito666: if you know the tag type you want, you can call ParseUnitTag(s) for example [17:19] wwitzel3: what I have is what a unit will return by calling Name() [17:19] I was not sure if that parsed to tag [17:21] perrito666: yes, it will [17:21] k tx [17:21] perrito666: all u.UniTag does is wrap names.NewUnitTag(u.Name()) [17:22] perrito666: so it will be the same result, except NewUnitTag panics and ParseUnitTag has an error return, so just depends on the behavior you want [17:22] tx a lot man [17:22] np [17:22] * perrito666 adds the appropriate string in the appropriate parts [17:47] how is juju backup different than just, say, a bundle? [17:52] Bug #1459761 was opened: Unable to destroy service/machine/unit === arosales_ is now known as arosales [17:58] Bug #1459761 changed: Unable to destroy service/machine/unit

[18:07] Bug #1459761 was opened: Unable to destroy service/machine/unit === kadams54 is now known as kadams54-away [18:33] marcoceppi: what do you mean by "bundle"? a charm bundle? [18:37] Bug #1457011 changed: init system discovery script fails with: [[: not found

[18:37]

[18:37] Bug #1459775 was opened: init system discovery script has bashisms

=== kadams54-away is now known as kadams54 [18:43] Bug #1457011 was opened: init system discovery script fails with: [[: not found

ericsnowcurrently>

[18:43] Bug #1459775 changed: init system discovery script has bashisms

[18:52] Bug #1457011 changed: init system discovery script fails with: [[: not found

[18:52]

[18:52] Bug #1459775 was opened: init system discovery script has bashisms

[18:52] Bug #1459785 was opened: systemd-related tests may fail under windows

[18:55] Bug #1459785 changed: systemd-related tests may fail under windows

[19:07] Bug #1459785 was opened: systemd-related tests may fail under windows

=== kadams54 is now known as kadams54-away [19:28] does anyone know why 1.18 would not bootstrap to ec2? [19:28] * perrito666 looks a sinzui [19:32] perrito666: 1.18 did/does [19:32] I have this error https://bugs.launchpad.net/juju-core/+bug/1358933 [19:32] or related [19:32] Bug #1358933: localHTTPSServerSuite.TestMustDisableSSLVerify fails in lxc

[19:32] mm, or just related [19:32] perrito666: and cloud health shows it did 16 minutes ago, so AWS hs not changed to break 1.28 [19:34] it was that bug, juju 1.18 deppends on ca-certificates yet the package doesn t [19:35] perrito666: that sounds true. the ca-certificates is delievered with ever desktop system [19:35] sinzui: I am running juju from inside an lxc container [19:36] there's a corner case :p [19:37] perrito666: sure easily fixed by the edge user [19:37] indeed [19:38] Though I hope that wasn’t the only reason devs swore juju in lxc was unsupported [19:38] alghough I dont think it would hurt the package to depend on its dependencies even if they are installed by default [19:39] perrito666, they might not be, if you install ubuntu server with the "minimal virtual machine" option [19:39] installed by default, that is.. [19:39] I assume using lxc by hand is not all that common but I dont feel all that edgy [19:40] monocultures are bad. i like edgy :) [19:55] cherylj: ping [19:57] ericsnow: what up [19:57] cherylj: I have some concerns with http://reviews.vapour.ws/r/1797/ [19:57] cherylj: just wanted to talk about it real quick :) [19:59] ericsnow: sure. Reading through your comments now [19:59] cherylj: cool [20:04] ericsnow: to answer your question about adding in a start for the service with systemd - the short answer is that the container never halted if I didn't explicitly start the service. [20:04] When I was debugging, I saw that the service was in an inactive state once I added in the correct After and Install info [20:05] cherylj: yeah, it kind of makes sense [20:06] And I guess you had a different take on who should make the decision about the cloud-init AfterStopped target. [20:06] cherylj: relatedly, how does the shutdown service get removed? or does is simply stick around but do nothing? [20:07] cherylj: yeah, the code in service/systemd shouldn't have any knowledge of cloudinit [20:08] cherylj: also, part of what the cloudbase guys did was to pull all the cloudinit-related code into one place (under cloudconfig) [20:08] ericsnow: the ExecStopPost disable works just fine. It completely removes the service such that any containers created from that template to not have it in their registered services [20:08] cherylj: oh yeah :) [20:08] ericsnow: I can go in and make your suggested changes [20:08] cherylj: cool === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away