ml-gradle
ml-gradle copied to clipboard
marklogic
Test Connection
As a developer who is adding new connection details to an existing ml-gradle project. I want to be able to test the connection settings to a given MarkLogic cluster without making changes to the cluster. This cluster is of high value and is used by other people, but I'd like to eventually start managing this environment using ml-gradle. I want to be confident I can use ml-gradle from a given machine, using a set of connection settings, when I'm ready to make changes to the environment.
After testing the connection I expect mlLoadModules and mlDeploy tasks to work using these connection settings.
It may be useful to take advantage of https://github.com/marklogic/java-client-api/issues/636 for testing the connection.
@jamesagardner Just to confirm, you're expecting a new task here, right? Something like "mlCheckConnection"?
I'm tossing this into 4.0 as part of a plan to bump ml-gradle et al to 4.x once they depend on Java Client 5, which entails depending on Java 9+.
@rjrudin a new task would be fine. Unless there is already some other diagnostic level task it makes sense to add on to.
@jamesagardner I'm realizing now there are multiple connections to check. At a minimum, I think we'd want to ping 8002 to verify that the Manage API connection is good. Then there's the question of which REST API connections are known about and can thus be tested. I think ml-gradle would just test mlRestPort, but in DHF, that property isn't used - mlStagingPort, mlJobPort, and mlFinalPort are there, pointing to 3 different app servers.
Which connections did you have in mind for this?
Proposal:
gradle mlPing [-PmlAppServicesPort] [-PmlRestPort]
By default, test connections to both app services and (if configured) the REST port. Allow overriding to test just the specified port. I would think DHF would override this task and add options for staging, job, and final ports. ml-gradle would want to use properties like mlAuthentication, mlUsername, ml*Password, etc.
Moving this for now, as 4.1 is going to be focused on updating a bunch of third party dependencies.
I think this could go a little further than just checking connection. As per OP it should give confidence a subsequent deploy should work, so it would be good if it would check all relevant user settings for sufficient privs, as far as ootb deploys go of course..
Thinking of testing the following:
- It's almost certain that ml-gradle needs to talk to the Manage App Server, so do a ping call on that and print the results.
- As long as
mlAppServicesPortis not 0, do a ping call on that and print the results.
The problem with testing mlRestPort is that for an initial deploy, that App Server won't exist yet. Also, that port will only be used for loading REST extensions; modules/schemas/data are loaded via mlAppServicesPort.
Thinking that if ml-gradle can connect to the Manage app server, it can check to see if there are app servers with ports of mlRestPort and mlTestRestPort. And if so, it can create a DatabaseClient for each and try checkConnection on each as well.
Realizing now there are at least two kinds of outputs here:
- An
mlTestConnectionstask that prints out the results of testing each connection. Useful for ad hoc testing of connections and easily seeing the results. - A new
TestConnectionsCommandthat would cause e.g.mlDeployto fail if any connection fails.
The second one above is a little tricky because for an initial deploy, the restPort/testRestPort servers won't exist yet, so we can't test them.
For the scope of this, I'm going with the first item. And I'm thinking mlTestConnections should throw a GradleException - that would at least allow a user to do ./gradlew mlTestConnections mlDeploy, causing the latter task not to run if the former fails.