cmd: Add check-connection to jujud

[babbageclunk]

Description of change

This takes an agent name and checks whether a connection can be made
to the API server from that agent's config. It will be used in the 1.25
upgrade process to confirm that the controller is accessible from all
of the agent machines once the config files have been rewritten (analogous
to the migration minions checking connectivity in a model migration).

QA steps

• Bootstrap and add a model, and deploy an application.
• SSH to the application machine and run (from /var/lib/juju):

sudo tools/<agent>/jujud check-connection <agent-name>

• It should succeed (return 0, no output).
• Pass in a non-existent agent name, you should get an error about not finding the config and non-zero return.
• Edit the config file to make it incorrect in some way (by changing apipassword or apiservers, for example), you should get sensible error messages.

Documentation changes

This isn't really intended for users - it will be called from the upgrade tool, so there's no need for documentation.

[wallyworld]

I reckon we need to change the cmd constructor to just take a data dir

[wallyworld]

This reads a bit funny?

[babbageclunk]

Yeah, I couldn't think of better wording - I've tweaked it to "ConnectFunc connects to the API as the given agent.".

[wallyworld]

I'd prefer this be given a name like ConnectToAgent or something and the testing version be munged to be MockConnectToAgent.
"ReallyConnect" is what we'd expect business logic to do without adding that aspect to the method name. Best to keep the real logic / naming pure and rename things for tests.

[babbageclunk]

I've changed it to ConnectAsAgent. ConnectToAgent doesn't seem right?

[wallyworld]

to the API server of a specified agent
?

[babbageclunk]

"for the specified agent"?

[wallyworld]

Move this to just above the tag, err := .... line
No need to go to the trouble of checking tags etc if we are only going to bail out anyway

[babbageclunk]

Done.

[wallyworld]

I'm confused - if we are reading in the agent conf from a file, why pass an agent conf in at all? Why not just pass in the data dir and construct an empty conf from that?

[babbageclunk]

I might be misreading the code, but an AgentConf is just a wrapper around a directory, right? If I passed in a data dir as a string wouldn't the tests have to create the dir(s) and a config file in it? If I take the AgentConf then I can pass in a mock conf and avoid filesystem access from the tests.

[babbageclunk]

I think I might be missing your point though, so I'll check in with you about it anyway.

[wallyworld]

So all we need here is the data dir from the current conf right? Let's pass that in instead of the whole conf which we are just going to overwrite anyway.

[babbageclunk]

The AgentConf that gets passed in is empty - it doesn't have a current conf until something calls ReadConfig(agentName) on it. Or are you concerned about the conf being shared between the different commands? I can change that, anyway.

[babbageclunk]

Not sure about the test failure here:

----------------------------------------------------------------------
FAIL: logsink_test.go:83: logsinkSuite.TestSuccess

logsink_test.go:110:
    s.stub.CheckCallNames(c, "Open", "WriteLog")
/home/ubuntu/juju-core_2.2.3/src/github.com/juju/testing/stub.go:222:
    return c.Check(funcNames, jc.DeepEquals, expected)
... obtained []string = []string{"Open", "WriteLog", "Close"}
... expected []string = []string{"Open", "WriteLog"}
... mismatch at top level: length mismatch, 3 vs 2; obtained []string{"Open", "WriteLog", "Close"}; expected []string{"Open", "WriteLog"}

OOPS: 5 passed, 1 FAILED
--- FAIL: TestPackage (0.28s)
FAIL
FAIL	github.com/juju/juju/apiserver/logsink	1.627s

From reading the code, I thought maybe we were hitting the read deadline, but it's using endpointVersion 0, so that's 6 hours! So I don't know what's happening here. The websocket dies for some reason, and that in turn calls Close on the writeCloser. :(

[babbageclunk]

$$merge$$

[jujubot]

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju