| 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:39 |
|---|---|---|
| anastasiamac | axw_: wallyworld: backort of storage-add http://reviews.vapour.ws/r/1803/ | 02:47 |
| axw_ | looking | 02:48 |
| anastasiamac | axw_: \o/ | 02:49 |
| === natefinch-afk is now known as natefinch | ||
| wallyworld | natefinch-afk: isn't t just a case of adding a LogDir() metod to fakeConfigSetter | 02:50 |
| 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:51 |
| 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:54 |
| 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:55 |
| wallyworld | i find that both useful and difficult in Go | 02:56 |
| wallyworld | hard to know what implements what | 02:56 |
| 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. | 02:59 |
| natefinch | every test we have runs hundreds of lines of setup code, most of which is very far away from the test itself. | 03:01 |
| 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:09 |
| 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:10 |
| wallyworld | see TestContextInitializeWhenNoUpgradeRequired | 03:11 |
| wallyworld | looks like the test sets it up | 03:11 |
| menn0 | thumper: reporting dropped log messages: http://reviews.vapour.ws/r/1804/ | 04:21 |
| 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 | 04:22 |
| === kadams54 is now known as kadams54-away | ||
| thumper | menn0: ack | 05:12 |
| axw_ | wallyworld: FYI I have the deadlock in hand, just working through updating all the tests and so on | 06:32 |
| wallyworld | axw_: awesome, so the worker uses a tomb etc. did you get rid of the singleton? | 07:06 |
| axw_ | wallyworld: I did, but now I'm putting it back (sort of) | 07:07 |
| 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:08 |
| 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:09 |
| wallyworld | i'm off to soccer soonish, will look in more detail when i get back | 07:10 |
| 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:11 |
| 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:16 |
| axw_ | wallyworld: which tests? | 07:17 |
| axw_ | wallyworld: the uniter tests will still need to | 07:17 |
| 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:18 |
| wallyworld | maybe william's code not landed yet | 07:19 |
| 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:20 |
| 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:21 |
| wallyworld | gotta start somwhere | 07:22 |
| axw_ | fwereade: http://reviews.vapour.ws/r/1806/ | 08:25 |
| axw_ | FYI | 08:25 |
| axw_ | wallyworld: ^^ | 08:25 |
| 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:03 |
| fwereade | wallyworld, axw_: and, yes, I suspect I didn't land the branch that put lease manager in the dummy provider, dammit, sorry | 09:06 |
| 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:43 |
| 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:44 |
| 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:45 |
| axw_ | fwereade: fair enough. ok, so I'll export an error from lease, but trap it in leadership and translate | 09:46 |
| 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:47 |
| 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:48 |
| 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 | 09:49 |
| mup | Bug #1459610 was opened: juju status --format=tabular > 80 characters wide <juju-core:New> <https://launchpad.net/bugs/1459610> | 10:30 |
| mup | Bug #1459611 was opened: juju status --utc does not display utc and is confused <juju-core:New> <https://launchpad.net/bugs/1459611> | 10:42 |
| axw_ | fwereade: updated, PTAL when you can | 10:52 |
| fwereade | axw_, cheers | 10:52 |
| mup | Bug #1459611 changed: juju status --utc does not display utc and is confused <juju-core:New> <https://launchpad.net/bugs/1459611> | 10:54 |
| 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:00 |
| wwitzel3 | sorry I missed the first half, but the last half was useful :) | 11:03 |
| anastasiamac | wwitzel3: it was just as great for me too! I had all my questions answered :D | 11:14 |
| wallyworld | ericsnow: you ocr? can you look at http://reviews.vapour.ws/r/1805/ sometime during your day? | 12:01 |
| wallyworld | fwereade: just as an fyi ^^^^^ | 12:02 |
| wallyworld | since we discussed it | 12:02 |
| fwereade | wallyworld, cheers | 12:02 |
| thumper | I'm outa here | 12:09 |
| 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:31 |
| * perrito666 casts eyes | 12:47 | |
| marcoceppi | Is the environment UUID exposed in the API? | 13:17 |
| fwereade | marcoceppi, Client.EnvironmentInfo | 13:32 |
| fwereade | marcoceppi, and you get the tag, which is "environ-<uuid>" when you log in | 13:32 |
| 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> | 13:40 |
| 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:01 |
| wwitzel3 | ericsnow: ping | 14:04 |
| === 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 | ||
| perrito666 | how can I go from a name to a Tag? | 17:09 |
| wwitzel3 | perrito666: ? | 17:14 |
| wwitzel3 | perrito666: what do you mean? | 17:15 |
| wwitzel3 | perrito666: you have string name? | 17:15 |
| perrito666 | yes, and I want a way to get a tag | 17:16 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 | |
| marcoceppi | how is juju backup different than just, say, a bundle? | 17:47 |
| mup | Bug #1459761 was opened: Unable to destroy service/machine/unit <juju-core:New> <https://launchpad.net/bugs/1459761> | 17:52 |
| === arosales_ is now known as arosales | ||
| mup | Bug #1459761 changed: Unable to destroy service/machine/unit <destroy-machine> <local-provider> <lxc> <juju-core:Triaged> <https://launchpad.net/bugs/1459761> | 17:58 |
| mup | Bug #1459761 was opened: Unable to destroy service/machine/unit <juju-core:New> <https://launchpad.net/bugs/1459761> | 18:07 |
| === kadams54 is now known as kadams54-away | ||
| ericsnow | marcoceppi: what do you mean by "bundle"? a charm bundle? | 18:33 |
| 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:37 |
| === kadams54-away is now known as kadams54 | ||
| 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:43 |
| 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:52 |
| 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> | 18:55 |
| 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:07 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | does anyone know why 1.18 would not bootstrap to ec2? | 19:28 |
| * perrito666 looks a sinzui | 19:28 | |
| 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:32 |
| perrito666 | it was that bug, juju 1.18 deppends on ca-certificates yet the package doesn t | 19:34 |
| 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:35 |
| perrito666 | there's a corner case :p | 19:36 |
| sinzui | perrito666: sure easily fixed by the edge user | 19:37 |
| perrito666 | indeed | 19:37 |
| 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:38 |
| 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:39 |
| cmars | monocultures are bad. i like edgy :) | 19:40 |
| ericsnow | cherylj: ping | 19:55 |
| 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:57 |
| cherylj | ericsnow: sure. Reading through your comments now | 19:59 |
| ericsnow | cherylj: cool | 19:59 |
| 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:04 |
| ericsnow | cherylj: yeah, it kind of makes sense | 20:05 |
| 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:06 |
| ericsnow | cherylj: yeah, the code in service/systemd shouldn't have any knowledge of cloudinit | 20:07 |
| 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 | 20:08 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!