[02:39] <natefinch-afk> 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] <anastasiamac> axw_: wallyworld: backort of storage-add http://reviews.vapour.ws/r/1803/
[02:48] <axw_> looking
[02:49] <anastasiamac> axw_: \o/
[02:50] <wallyworld> natefinch-afk: isn't t just a case of adding a LogDir() metod to fakeConfigSetter
[02:51] <natefinch> 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] <wallyworld> i just guessed by looking at what setup test did, hopefully it works
[02:54] <natefinch> wallyworld: oh yeah, I didn't think to look at setuptest
[02:55] <wallyworld> actuially, matbe not setup test, i forgot what i looked at, but see NewFakeConfigSetter
[02:55] <wallyworld> it has some of the COnfig methods but not all
[02:56] <wallyworld> i find that both useful and difficult in Go
[02:56] <wallyworld> hard to know what implements what
[02:59] <natefinch> 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] <natefinch> every test we have runs hundreds of lines of setup code, most of which is very far away from the test itself.
[03:09] <natefinch> 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] <wallyworld> it won't - you need to do that
[03:09] <wallyworld> with c.MkDir()
[03:10] <wallyworld> and then pass that dir to fakeconfigsetter
[03:10] <wallyworld> so it can be returned from the LogDir() func
[03:10] <wallyworld> just guessing
[03:10] <natefinch> I can't even really tell where this test ends up creating a fakeConfigSetter
[03:11] <wallyworld> see TestContextInitializeWhenNoUpgradeRequired
[03:11] <wallyworld> looks like the test sets it up
[04:21] <menn0> thumper: reporting dropped log messages: http://reviews.vapour.ws/r/1804/
[04:22] <menn0> thumper: btw, i really don't like the tests for logsender and I have a plan for reworking them to be more unit-testy
[05:12] <thumper> menn0: ack
[06:32] <axw_> wallyworld: FYI I have the deadlock in hand, just working through updating all the tests and so on
[07:06] <wallyworld> axw_: awesome, so the worker uses a tomb etc. did you get rid of the singleton?
[07:07] <axw_> wallyworld: I did, but now I'm putting it back (sort of)
[07:08] <axw_> wallyworld: it's a huge PITA to change all of the tests
[07:08] <wallyworld> yeah :-(
[07:08] <axw_> 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] <axw_> 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] <wallyworld> i hate jujuconnsuite
[07:10] <wallyworld> i'm off to soccer soonish, will look in more detail when i get back
[07:11] <axw_> wallyworld: sure. I've not proposed yet, still fixing tests
[07:11] <axw_> enjoy
[07:11] <wallyworld> will do, not quite leaving yet
[07:16] <wallyworld> 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] <axw_> wallyworld: which tests?
[07:17] <axw_> wallyworld: the uniter tests will still need to
[07:18] <wallyworld> axw_: william put a worker loop in dummy provider, and menno also added one for some agent tests
[07:18] <wallyworld> hmmm, i think the agent tests are on master though
[07:18] <axw_> wallyworld: didn't see anything in dummy provider. I don't think my change will improve on that
[07:19] <wallyworld> maybe william's code not landed yet
[07:20] <wallyworld> if blocking calls were removed, that would help with the problem
[07:20] <wallyworld> i guess with your changes though, it's a matter of starting a worker rather than a loop directly
[07:21] <wallyworld> and maybe blocking calls can be aborted when the worker fies
[07:21] <wallyworld> dies
[07:21] <axw_> wallyworld: if the worker isn't started, lease/leadership calls will error out
[07:21] <axw_> wallyworld: so they won't hang forever
[07:21] <wallyworld> great, that's an improvement
[07:21] <axw_> wallyworld: not sure if that's enough to cover all the tests
[07:22] <wallyworld> gotta start somwhere
[08:25] <axw_> fwereade: http://reviews.vapour.ws/r/1806/
[08:25] <axw_> FYI
[08:25] <axw_> wallyworld: ^^
[09:03] <fwereade> axw_, reviewed; basically awesome, but I have a few quibbles
[09:03] <dimitern> fwereade, can you stamp http://reviews.vapour.ws/r/1777/ please?
[09:06] <fwereade> wallyworld, axw_: and, yes, I suspect I didn't land the branch that put lease manager in the dummy provider, dammit, sorry
[09:43] <axw_> 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] <fwereade> axw_, true
[09:43] <fwereade> axw_, but you need the same error in several circumstances, right?
[09:44] <fwereade> axw_, so an unexported errStopped is probably a good idea
[09:44] <axw_> fwereade: just that one method in leadership, but I'll do that anyway
[09:45] <fwereade> axw_, shouldn't claim and release have similar?
[09:45] <fwereade> 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] <axw_> fwereade: their cancellation happens in the lease package. so... I could export an error from there instead
[09:46] <axw_> fwereade: fair enough. ok, so I'll export an error from lease, but trap it in leadership and translate
[09:47] <axw_> I was hoping not to put that in the lease contract
[09:47] <fwereade> axw_, well that's sort of why I was advocating a worker.ErrStopped
[09:47] <axw_> I see
[09:47] <axw_> ok then, that'll do
[09:48] <fwereade> axw_, from the POV of a client it barely matters which worker was stopped or why
[09:48] <fwereade> axw_, it's as simple as "I cannot fulfil your request because the necessary components are not running"
[09:49] <fwereade> 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] <axw_> fwereade: yep, sounds good
[10:30] <mup> Bug #1459610 was opened: juju status --format=tabular > 80 characters wide <juju-core:New> <https://launchpad.net/bugs/1459610>
[10:42] <mup> Bug #1459611 was opened: juju status --utc does not display utc and is confused <juju-core:New> <https://launchpad.net/bugs/1459611>
[10:52] <axw_> fwereade: updated, PTAL when you can
[10:52] <fwereade> axw_, cheers
[10:54] <mup> Bug #1459611 changed: juju status --utc does not display utc and is confused <juju-core:New> <https://launchpad.net/bugs/1459611>
[11:00] <mup> Bug #1456957 changed: rsyslog worker should not add machines that are not ready yet <cpec> <logging> <rsyslog> <juju-core:Won't Fix> <juju-core 1.22:New> <juju-core 1.23:New> <juju-core 1.24:New> <https://launchpad.net/bugs/1456957>
[11:00] <mup> Bug #1459611 was opened: juju status --utc does not display utc and is confused <juju-core:New> <https://launchpad.net/bugs/1459611>
[11:00] <mup> Bug #1459616 was opened: 'juju status' timestamps should use rfc3339 or ISO8601 <juju-core:New> <https://launchpad.net/bugs/1459616>
[11:03] <wwitzel3> sorry I missed the first half, but the last half was useful :)
[11:14] <anastasiamac> wwitzel3: it was just as great for me too! I had all my questions answered :D
[12:01] <wallyworld> ericsnow: you ocr? can you look at http://reviews.vapour.ws/r/1805/ sometime during your day?
[12:02] <wallyworld> fwereade: just as an fyi ^^^^^
[12:02] <wallyworld> since we discussed it
[12:02] <fwereade> wallyworld, cheers
[12:09] <thumper> I'm outa here
[12:31] <fwereade> 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] <marcoceppi> Is the environment UUID exposed in the API?
[13:32] <fwereade> marcoceppi, Client.EnvironmentInfo
[13:32] <fwereade> marcoceppi, and you get the tag, which is "environ-<uuid>" when you log in
[13:40] <mup> Bug #1459679 was opened: MinUnitsSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1459679>
[14:01] <mup> Bug #1459679 changed: MinUnitsSuite teardown fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1459679>
[14:04] <wwitzel3> ericsnow: ping
[17:09] <perrito666> how can I go from a name to a Tag?
[17:14] <wwitzel3> perrito666: ?
[17:15] <wwitzel3> perrito666: what do you mean?
[17:15] <wwitzel3> perrito666: you have string name?
[17:16] <perrito666> yes, and I want a way to get a tag
[17:18] <wwitzel3> 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] <wwitzel3> perrito666: if you know the tag type you want, you can call ParseUnitTag(s) for example
[17:19] <perrito666> wwitzel3: what I have is what a unit will return by calling Name()
[17:19] <perrito666> I was not sure if that parsed to tag
[17:21] <wwitzel3> perrito666: yes, it will
[17:21] <perrito666> k tx
[17:21] <wwitzel3> perrito666: all u.UniTag does is wrap names.NewUnitTag(u.Name())
[17:22] <wwitzel3> 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] <perrito666> tx a lot man
[17:22] <wwitzel3> np
[17:22]  * perrito666 adds the appropriate string in the appropriate parts
[17:47] <marcoceppi> how is juju backup different than just, say, a bundle?
[17:52] <mup> Bug #1459761 was opened: Unable to destroy service/machine/unit <juju-core:New> <https://launchpad.net/bugs/1459761>
[17:58] <mup> Bug #1459761 changed: Unable to destroy service/machine/unit <destroy-machine> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1459761>
[18:07] <mup> Bug #1459761 was opened: Unable to destroy service/machine/unit <juju-core:New> <https://launchpad.net/bugs/1459761>
[18:33] <ericsnow> marcoceppi: what do you mean by "bundle"?  a charm bundle?
[18:37] <mup> Bug #1457011 changed: init system discovery script fails with: [[: not found <cloud-init> <compatibility> <regression> <tech-debt> <juju-core:Fix Released by ericsnowcurrently>
[18:37] <mup> <juju-core 1.23:Fix Released by ericsnowcurrently> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1457011>
[18:37] <mup> Bug #1459775 was opened: init system discovery script has bashisms <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459775>
[18:43] <mup> Bug #1457011 was opened: init system discovery script fails with: [[: not found <cloud-init> <compatibility> <regression> <tech-debt> <juju-core:Fix Released by
[18:43] <mup> ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1457011>
[18:43] <mup> Bug #1459775 changed: init system discovery script has bashisms <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459775>
[18:52] <mup> Bug #1457011 changed: init system discovery script fails with: [[: not found <cloud-init> <compatibility> <regression> <tech-debt> <juju-core:Fix Released by ericsnowcurrently>
[18:52] <mup> <juju-core 1.23:Fix Released by ericsnowcurrently> <juju-core 1.24:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1457011>
[18:52] <mup> Bug #1459775 was opened: init system discovery script has bashisms <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459775>
[18:52] <mup> Bug #1459785 was opened: systemd-related tests may fail under windows <systemd> <windows> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459785>
[18:55] <mup> Bug #1459785 changed: systemd-related tests may fail under windows <systemd> <windows> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459785>
[19:07] <mup> Bug #1459785 was opened: systemd-related tests may fail under windows <systemd> <windows> <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1459785>
[19:28] <perrito666> does anyone know why 1.18 would not bootstrap to ec2?
[19:28]  * perrito666 looks a sinzui 
[19:32] <sinzui> perrito666: 1.18 did/does
[19:32] <perrito666> I have this error https://bugs.launchpad.net/juju-core/+bug/1358933
[19:32] <perrito666> or related
[19:32] <mup> Bug #1358933: localHTTPSServerSuite.TestMustDisableSSLVerify fails in lxc <ci> <test-failure> <juju-core:Fix Released by sinzui> <https://launchpad.net/bugs/1358933>
[19:32] <perrito666> mm, or just related
[19:32] <sinzui> perrito666: and cloud health shows it did 16 minutes ago, so AWS hs not changed to break 1.28
[19:34] <perrito666> it was that bug, juju 1.18 deppends on ca-certificates yet the package doesn t
[19:35] <sinzui> perrito666: that sounds true. the ca-certificates is delievered with ever desktop system
[19:35] <perrito666> sinzui: I am running juju from inside an lxc container
[19:36] <perrito666> there's a corner case :p
[19:37] <sinzui> perrito666: sure easily fixed by the edge user
[19:37] <perrito666> indeed
[19:38] <sinzui> Though I hope that wasn’t the only reason devs swore juju in lxc was unsupported
[19:38] <perrito666> alghough I dont think it would hurt the package to depend on its dependencies even if they are installed by default
[19:39] <cmars> perrito666, they might not be, if you install ubuntu server with the "minimal virtual machine" option
[19:39] <cmars> installed by default, that is..
[19:39] <perrito666> I assume using lxc by hand is not all that common but I dont feel all that edgy
[19:40] <cmars> monocultures are bad. i like edgy :)
[19:55] <ericsnow> cherylj: ping
[19:57] <cherylj> ericsnow: what up
[19:57] <ericsnow> cherylj: I have some concerns with http://reviews.vapour.ws/r/1797/
[19:57] <ericsnow> cherylj: just wanted to talk about it real quick :)
[19:59] <cherylj> ericsnow: sure.  Reading through your comments now
[19:59] <ericsnow> cherylj: cool
[20:04] <cherylj> 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] <cherylj> 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] <ericsnow> cherylj: yeah, it kind of makes sense
[20:06] <cherylj> And I guess you had a different take on who should make the decision about the cloud-init AfterStopped target.
[20:06] <ericsnow> cherylj: relatedly, how does the shutdown service get removed?  or does is simply stick around but do nothing?
[20:07] <ericsnow> cherylj: yeah, the code in service/systemd shouldn't have any knowledge of cloudinit
[20:08] <ericsnow> cherylj: also, part of what the cloudbase guys did was to pull all the cloudinit-related code into one place (under cloudconfig)
[20:08] <cherylj> 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] <ericsnow> cherylj: oh yeah :)
[20:08] <cherylj> ericsnow: I can go in and make your suggested changes
[20:08] <ericsnow> cherylj: cool