Site/Service dispatch error under 3.5.4

[Anthony Shortland]

Setting up a simple site/service resource model under 3.5.4 (after upgrading both framework and seed from 3.5.3) I get:

[ctier@centos55 ~]$ ctl -p demo -t Site -r sample -c Deploy 

Dispatching command 'Deploy ' to: sample[TomcatServer] ...

Error handler caught failed command execution: sample[TomcatServer]#Deploy. reason: No matched nodes: null

Error: The following error occurred while executing this line:

/opt/ctier/ctl/projects/demo/modules/Mediator/commands/Deploy.xml:31: No message

Here's the code from Mediator's Deploy command handler:

 29     <dispatch-command name="Deploy" threadcount="${opts.threadCount}" requirematch="false" strategy="${opts.strategy}">

 30       <errorhandler>

 31         <fail/>

 32       </errorhandler>

 33       <command name="Deploy"/>

 34       <arg line="${passed.argline}"/>

 35       <contexts>

 36         <select-dependencies sortkey="deployment-startup-rank" sortorder="ascending" relationtype="(?:Service|Mediator)" source="context">

 37           <include name="${opts.resourcename}" type="${opts.resourcetype}"/>

 38         </select-dependencies>

 39       </contexts>

 40     </dispatch-command>

Here's the project XML:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE project PUBLIC "-//ControlTier Software Inc.//DTD Project Document 1.0//EN" "project.dtd">

<project>

  <deployment type="Site" name="sample" description="" basedir="" installRoot="" startuprank="">

    <resources>

      <resource name="sample" type="TomcatServer"/>

    </resources>

    <referrers replace="false">

      <resource name="centos55" type="Node"/>

    </referrers>

  </deployment>

  <deployment type="TomcatServer" name="sample" description="Sample Apache Tomcat server deployment" basedir="${user.home}/apache-tomcat-5.5.28" installRoot="${user.home}/apache-tomcat-5.5.28" startuprank="">

    <referrers replace="false">

      <resource name="node1" type="Node"/>

    </referrers>

  </deployment>

</project>

Some sort of dispatcher problem?

Anthony.

[Anthony Shortland]

Here's verbose output from the command:

Doing dispatch-command ...

selectToken: deployment-startup-rank

matchedGroup: service.TomcatServer.sample.deployment-startup-rank

propName: service.TomcatServer.sample.deployment-startup-rank

sortkey value: 

Dispatch context selector including: sample[TomcatServer]

Dispatching command 'Deploy ' to: sample[TomcatServer] ...

dispatch-command macro 'dispatch-command-macro' not declared in handler: Deploy

starting: sample[TomcatServer] Deploy  ...

calling TaskContainerStrategy with sequence

Override ignored for property "context.user"

authenticated user: ctier

creating an ObjectCommandProxyDispatcher

Filtering to local node only... 

Error handler caught failed command execution: sample[TomcatServer]#Deploy. reason: No matched nodes: null

Exiting /opt/ctier/ctl/projects/demo/modules/Mediator/commands/Deploy.xml.

Error: The following error occurred while executing this line:

/opt/ctier/ctl/projects/demo/modules/Mediator/commands/Deploy.xml:32: No message

Seems to indicate that dispatch-command is "Filtering to local node only...".

I've logged a bug: https://sourceforge.net/tracker/?group_id=151079&atid=779847

Anthony.

[Noah Campbell]

It was change in 3.5 to only dispatch to localhost.  If you you want to dispatch far and wide you need to explicitly call it out.

The rationale is that while you're testing, it keeps things local and then you broaden your reach when you're comfortable with the results.  This will prevent dispatching that rm -rf command to all your nodes.  

-Noah

--
You received this message because you are subscribed to the Google Groups "ControlTier" group.
To post to this group, send email to contr...@googlegroups.com
To unsubscribe from this group, send email to controltier...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/controltier?hl=en
http://wiki.controltier.org

[Moses Lei]

Really? I thought the default behavior was just changed for ctl-exec.

If the dispatch-command task was changed, this is *very* backwards incompatible and I am against it.

Moses

--
Moses Lei
[ Professional Services | DTO Solutions, Inc. ]
[ office: 323.654.6944 | mobile: 703.901.5969 | e-mail: ml...@dtosolutions.com | aim/gtalk: ml...@controltier.com | yahoo: moseslei | windows live (msn): ml...@dtosolutions.com ]

[Anthony Shortland]

There is no way to select nodes in the dispatch-command task used by the *generated*  code in the core module's command handlers, and no need to expose that mode of usage in the "traditional" service-orientated approach.

Greg's guess was that the lower-level change for ctl-exec is now (erroneously) being inherited by DispatchCommand and he's looking into it, I believe.

Anthony.