Bug 481162

When deploying a config file to multiple systems via the System Set Manager, if one of these systems does not have the deploy action enabled the entire operation fails and an ISE appears in the web UI.


Steps to Reproduce:
1. Register two systems. (CentOS 5 in my case)
2. Enable deploy action on one of the systems.
3. Create a configuration channel with a single file.
4. Manually subscribe each system to the channel from their individual SDC Configuration tab.
5. View system list, select both systems, click "Update List" button.
6. Switch to System Set Manager, Configuration Tab > Deploy Files.
7. Select the file from the channel and click "Schedule File Deploy".
8. View confirmation screen, note that only the system with deploy enabled is in the list, click "Confirm File Deploy".

Actual results:

ISE. Stack trace looks like:

CPU Arch: i686-redhat-linux]]. The server will be unable to deploy config files until this capability is provided.
        at com.redhat.rhn.manager.action.ActionManager.createConfigActionForServers(ActionManager.java:393)
        at com.redhat.rhn.manager.action.ActionManager.createConfigAction(ActionManager.java:432)
        at com.redhat.rhn.frontend.action.configuration.ssm.ConfigConfirmSubmitAction.confirm(ConfigConfirmSubmitAction
.java:149)
        at com.redhat.rhn.frontend.action.configuration.ssm.ConfigConfirmSubmitAction.deploy(ConfigConfirmSubmitAction.
java:96)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:270)
        at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:187)
        at org.apache.struts.actions.LookupDispatchAction.execute(LookupDispatchAction.java:150)
        at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
        at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
        at com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProcessor.java:82)
        at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
        at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:73)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)

...



Additional info:

It looks like the SSM is displaying the correct list of systems on the confirmation screen (i.e. with non-deploy enabled systems filtered out) but when it goes to actually perform the action it attempts to run on the entire list.