3 Replies Latest reply on Oct 12, 2020 6:30 AM by Raul Galicia

    Fully resolve host group members defined in Workload Policy

    Levente Bosz
      Share This:

      Dear Members,

       

      until it will be possible that workload policies can be created, edited and deleted, not just activated or deactivated via command line, is there any known possibility to have a command-line (or cli) powered dynamic association of nodes and running 0 jobs on these in case of for example maintenance window?

       

      For example:

      • nodes are node01, node02, node03
      • host group is node_group which includes node01 and node02
      • workload policy is created and activated for node_group
      • Job #1 contains node_group as "Host/Hostgroup" field
      • Job #2 contains node03 as "Host/Hostgroup" field

       

      In this case no jobs are running for node_group, means node01 and node02 are running no jobs, which is expected behaviour.

       

      So and when I add now the host node03 to the group node_group:

      • ctmhostgrp -EDIT -HOSTGRP node_group -APPLTYPE OS -ADD node03

       

      , Job #2 (recall: defined host is node03 which is now member of node_group) can be still started and won't wait because of activated workload policy.

       

      This is perhaps because workload policy filter hostnames won't be resolved to host groups and their members, which leads me to the question: how else would be possible a fully automated control of job running allovance (in case of maintenance window for specific nodes for example), without editing the jobs in AJF but with possibility of having multiple hosts at the same time with a number of running jobs of 0?

       

      Thank you in advance!

        • 1. Re: Fully resolve host group members defined in Workload Policy
          Raul Galicia

          Hello Levente

           

          If Job #2 is defined to run on node03, doesn't matter whether you add host node03 to node_group because the job won't run on node_group but on node03 so the workload policy applied to node_group won't be used for your job.

           

          If you need the workload policy for node_group works on your job, you MUST change the definition for your Job #2 to use node_group instead of node03 as the host.

           

          Or, If you want, you could modify your existing policy for node_group and add node03 in the host filter (to use several hosts or hostgroups in a workload policy filter you must separate them by commas: node_group,node03) and after that, apply changes.

           

          Or you could simply add a new workload policy only for node03 and say that the number of allowed running jobs for node03 is 0. Indeed you could have a workload policy for every node and every host group and activate them when there is a maintenance window affecting one of your nodes or every node on your host group.

           

          I've been checking the last automation api options but there is nothing yet to create/modify workload policies, only to activate/deactivate them and only from api version 9.0.19 so you don't have too many options

           

          Best regards,

          Raúl Galicia

          1 of 1 people found this helpful
          • 2. Re: Fully resolve host group members defined in Workload Policy
            Levente Bosz

            Hello Raul,

             

            thanks for your reply and that you take time to answer. I tried again some variations but how hosts and hostgroups are handled, seems really to be simple as it can be. I would create a ticket as request for feature.

             

            Use case #1:

            1. Hostgroup contains affected host
            2. Job definition contains affected host
            3. Workload contains hostgroup
            4. Result: no action

             

            Use case #2, based also on your suggestion:

            1. Hostgroup contains affected host
            2. Job definition contains affected host
            3. Workload contains host
            4. Result: works, but for a fully automation is needed to create for each host and hostgroup the same amount of workload policies

             

            Use case #3:

            1. Hostgroup contains affected host
            2. Job definition contains affected hostgroup
            3. Workload contains host
            4. Expected result: all ordered jobs are running on one of the remaining hosts in the hostgroup where no workload policy is active but not on the affected host
            5. Observed result: each ordered job takes the next member of the group, regardless of current affectedness of workload policy membership and because of this it will be tried to execute jobs on affected hosts too. Conclusion: not a solution

             

            Use case #4:

            1. Hostgroup contains affected host
            2. Job definition contains affected hostgroup
            3. Workload contains hostgroup
            4. Result: no jobs are running, neither on the affected host nor on still unaffected hosts.

             

            Conclusion: Assumed, no gui can be used, only the solution in Use case #2 can be used: create as many workload policies as hosts and hostgroups are existing. It's probably not allowed to execute sql queries directly on the database to edit existing workload policy entries for ongoing changes, so we did'nt worked on such solution further.

             

            I hope that this behaviour can be tuned in future releases and thank you in advance.

            • 3. Re: Fully resolve host group members defined in Workload Policy
              Raul Galicia

              Regarding Use cases #3 and #4, you could use a different approach, instead of using a workload policy you could have a script to disable that agent (Control-M won't send jobs to an agent inside a hostgroup if it is disabled or unavailable) or you could also remove temporarily the agent from the hostgroup and add it again once the maintenance/issue is over.

               

              Note: Both actions (disabling/enabling the agent or removing/adding the agent from the hostgroup) can be performed using automation api.

               

              Good luck.