Bug 1013906 - Re-add the ability to push to Zanata
Re-add the ability to push to Zanata
Status: CLOSED CURRENTRELEASE
Product: PressGang CCMS
Classification: Community
Component: CCMS-Core (Show other bugs)
1.1
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 1.5
Assigned To: Lee Newson
:
Depends On:
Blocks: 1092171
  Show dependency treegraph
 
Reported: 2013-09-30 23:04 EDT by Lee Newson
Modified: 2014-05-01 17:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-01 17:40:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lee Newson 2013-09-30 23:04:58 EDT
Currently there isn't anyway to push content specs to Zanata from within the UI or the server and you need to do it from the csprocessor client. This used to be possible in the Old UI, however it was removed when we went to the new REST client UI.

Technical Notes: This will require async rest calls as there is a high chance it will cause http timeouts otherwise.
Comment 1 Lee Newson 2014-03-30 08:54:30 EDT
Added in 1.5-SNAPSHOT build 201403161524

The server now has an async setup using JPPF which allows distributed computing (it's not very important for this RFE, but it's needed for book builds in the future).

The new rest server endpoints are:

/rest/1/contentspec/translation/push/json/{id}
/rest/1/contentspec/translation/sync/json/{id}
/rest/1/process/get/json/{id}
/rest/1/process/stop/json/{id}
/rest/1/processes/get/json/all
/rest/1/processes/get/json/{query}

and each will return a representation of the RESTProcessInformationV1 entity.

The RESTProcessInformationV1 entity holds a uuid, a name, the status, the start and finish times and any logs. The states for the status are as follows:

PENDING: The process has been submitted, but hasn't been added to the queue yet.
QUEUED: The process is in a queue waiting for it's turn to be executed.
EXECUTING: The process is currently in a node executing.
COMPLETED: The process completed and was successful.
FAILED: The task failed for either an unknown or known reason. (ie incorrect username/apikey)
CANCELLED: The task was cancelled by the user/admin.

The UI has been updated to include a "Processes" tab in the Content Spec UI and also a gloabl "Processes" view under the advanced menu. Additionally on the Content Spec view, there is an "Actions" menu that will you allow you to push/sync translations. Upon selecting one of the actions a Dialog box will popup and ask for any required information and then when started will show a "process status" dialog, to allow users to watch their process state.

In the processes view you'll be able to see the state, start time, finish time,  logs, who started the process and additional actions. The current additional actions are refresh and stop, which will only appear when the process is in a queued/executing state. Also at this stage since we don't have authentication the "Started By" field will always by "Unknown".

Note: I've excluded process percentage for the initial pass, as it will require a fair overhaul of our code to accurately calculate the percentage.

Note 2: This is currently live on the test/development server.
Comment 5 Matthew Casperson 2014-03-30 23:02:33 EDT
Successfully tested a push and sync of a spec.
Comment 6 Matthew Casperson 2014-03-30 23:07:57 EDT
Invalid username and passwords, invalid specs, spec with invalid topics all generate appropriate errors.
Comment 7 Matthew Casperson 2014-03-30 23:09:49 EDT
Attempting to push the same spec twice results in an appropriate error.
Comment 8 Matthew Casperson 2014-03-30 23:11:46 EDT
Pushing a spec when zanata is not running reports a successful outcome, even though there is nothing in the log files and the topics can't have been pushed.
Comment 9 Matthew Casperson 2014-03-30 23:14:24 EDT
A sync will also report success if the zanata server is not available.
Comment 10 Lee Newson 2014-03-31 02:14:48 EDT
Fixed in 1.5-SNAPSHOT build 201403311553

For some reason when you set the throwable on a task, only the throwable is serialized when it is returned to the client by JPPF. As such I've removed the throwable since it's information is logged anyways and also updated the logging to log more, as the error was being thrown by resteasy so it never would have been logged anyways.

Note: This is currently live on the test/development server.
Comment 11 Lee Newson 2014-03-31 02:46:06 EDT
I forgot to mention I've also added a check at the start of each task to make sure the Zanata server is able to return a response. If it can't then it'll log the following error and fail.

Unable to connect to the Zanata Server. Please make sure that the server is online and try again.
Comment 12 Matthew Casperson 2014-03-31 16:24:48 EDT
I tired this again this morning with zanata shutdown and got the same result of an empty log and a success message.

Job ID is 63BDF323-04AD-86E7-3090-BDC9AAB512E9
Comment 13 Lee Newson 2014-03-31 19:33:19 EDT
I forgot to restart the JPPF nodes and they already had the classes cached locally, so I believe this is why it failed again. I've restarted the nodes, so moving this back to ON_QA.
Comment 14 Matthew Casperson 2014-03-31 19:37:49 EDT
Tested it again when zanata server was not running and the appropriate error message was displayed.
Comment 15 Matthew Casperson 2014-03-31 19:53:21 EDT
Started a push and shutdown the zanata server in the middle. The job failed as expected.

Started Zanata back up and pushed again. The job completed successfully.

Note You need to log in before you can comment on or make changes to this bug.