Checking DNR execution - ideas?

Hi All -
This is a bit of a repost from several months ago, but I'm now working on it, so it's worth a new look. This is all taking place on Solaris, with OpenDeploy 6.02, patched up to current.

We're planning on doing some Content-Provisioning-like development, where we're using dnr scripts to control some environment and application configuration on remote servers.

So far, we've:
got the OD configurations set up to allow dnr execution ,
tested out the execution of scripts on the target,
using parameter substition from within the GUI,
and we've tested using the response code="-2" to force deployment failure.

All's going pretty well.

What we're interested in is a 'next step' in dnr execution, where we test the success of executing a dnr and then perform some processing based on the test. For example; if we call a dnr script to create a new Tomcat instance, we'd like to go run a test to see that the instance was actually created.

What we do with the results of the test can vary, but most likely the results will be used to control a workflow's branching.

So, taking the above example a bit further:
Let's say a TeamSite workflow task calls an OpenDeploy config that executes a dnr on a remote machine, creating a new Tomcat instance.
We'd then like to verify that the instance has been created correctly and feed that information back to the TeamSite workflow and the workflow would continue on to it's next step.
If a problem with the Tomcat instance creation is detected, that information would also be related back to the workflow, which would then branch off into an error routine in which the correct people are notified and any additional cleanup tasks might take place before trying again.

We're working through a set of ways that the above might take place, but would greatly appreciate any input that others have, either from practical experience or from from a theoretical standpoint.

Ideas, anyone?

I'll try to post updates on our progress also!

Many thanks,
Wally Box
Nike, Inc.

Find more posts tagged with

Comments

Adam Stoller

If you're dealing with a boolean situation (success / failure) from the DNR script - the means of having the DNR script indicate failure are documented in the manuals (an XML snippet that needs to be printed to STDOUT which OD looks at - also assumes that you're in transactional mode for best results). Also the DNR must *not* be running asynchronously.

The script from the workflow that invokes OD needs to check the return / exit status of the invokation - if the exit status is 0 (zero) - everything apparently succeeded. If the exit status is anything other than 0 - something failed. And you can use that to determine which callback value to use to transition the workflow.

If the question is how to determine whether the creation of the TomCat instance succeeded or failed - I don't know. I have to assume that whatever CLTs exist for TomCat will provide similar exit status values that you can check and then propagate back.

Migrateduser

Hey Wally,

Since you're looking for the result of the deployment+DNR to affect the workflow, the deployment needs to complete and return success or failure status, pretty much as you've got it working now.

Next you want to verify something on the target. One way would be to run another deployment that doesn't move any files, but kicks of a target-side DNR to run a script that does the test, then returns success or failure. The resulting status of the deployment would tell your workflow which way to fork.

Hope that helps.

Todd

Migrateduser

Thanks Gentlemen - these are some good thoughts.

There are 2 separate issues: the deployment success status and the dnr success status. Each one can have a distinct effect on what to do next.

What I have easily available is the deployment success status. If I deploy with no dnr, I'll have a fail / succeed result. I need to check further into the return/exit status that OpenDeploy provides. We've only recently come up to speed on 6.02 and the previous release we were one didn't provide this correctly.

What's more difficult is the dnr success status. What I have easily available to me is to have the dnr script produce the xml -2 result, as if the deployment failed. If, like Todd's suggests, I create separate deployments for dnr execution, that will at least let me know that it's the dnr that's returning failure. What type of failure isn't easily known.

What I'm trying to come up with is a better mechanism to determine the outcome of a dnr's execution. For example, I may execute a remote dnr that checks for 5 different error conditions, each of which might cause a different logic branch in a workflow. I can see where I could create 5 different dnrs, each with a single check (and I might test this one out today), but it'd be easier to create one routine and allow it to return a variety of results.

Other ways I might create a dnr error checking routine for multiple conditions:
- Create a web service that returns the dnr's success status outside of OpenDeploy.
- Log the dnr's output on the remote server. If a -2 is returned (something failed), kick off a reverse deployment of the output log and analyze it on the source server.

Wally

Adam Stoller

Other ways I might create a dnr error checking routine for multiple conditions:
- Create a web service that returns the dnr's success status outside of OpenDeploy.
- Log the dnr's output on the remote server. If a -2 is returned (something failed), kick off a reverse deployment of the output log and analyze it on the source server.

Wally

Given the refined problem statement - yeah, those are the two ideas that came to my mind too - or slight variations thereof.
Unfortunately, I don't believe the DNR mechanism is rich enough to provide the kind of functionality you're looking for .... unless ... it is possible to include more information in the '-2' return result status that can be picked up in the in-memory logs and then processed by a client-side dnrDeploymentJob script run after the deployment (or suitably trigger-specified dnrDeployment script, since I'm not sure if the in-memory log is available to the dnrDeploymentJob script).

I remember at one point there was some talk about this (like putting comments with the return result or something) - but I don't know if it ever got implemented and/or whether there are any special tricks for accessing it (like a missing IWXML.pm method?).

If this functionality doesn't exist - it might be reasonable fodder for a FR.

Migrateduser

Hi DevNetters!

What goes around comes around.. we're starting up another couple of projects that require this 'DNR success status' capability that got me to post the original entry in this thread.

We're starting work on a CAPS-like workflow where we're going to pull content from a source control system, attach it to a workflow and then sync the content to various remote servers and, most likely, execute some DNRs on those remote systems.

It will be important is that we are able to analyze the success of the DNR execution to some extent and then use that success/fail (well, maybe more granular status than just success/fail) criteria to control the workflow's execution.

We've had some more experience recently in using OpenDeploy to communicate with remote systems (using DNRs to send status updates) and I'm fairly confident that we could now:
1) execute a deployment with a target side DNR that outputs its success status to a file,
2) reverse deploy the file back into our local system,
3) analyze the pulled-in status and fork the workflow accordingly.

But that still seems like such a clunky solution for a system (OpenDeploy) that already has the communication channels all built into it to transfer status of the deployment between base and receiver instances. And, in particular, it seems like this would be a core functionality of the productized CAPs system - but I haven't run into it in any doco / DevNet postings on this as of yet.

So, here's the 'checking in' part: has anyone got any updates / success stories / good thoughts on this DNR-status-checking capability?

Thanks again,
Wally Box
Nike, Inc.