When executing an Action Plan in service automation, is there a way for it to target as a policy action, so it runs on all applicable computers based on relevancy? From what I see, you have to manually select the targets it will be executed on and that does not scale…
I know that if you select no target, then the plan will fail. As soon as it detects 0 targets, it will stop processing the remainder of the plan. The only thing I can think of is targeting a group that you have set custom relevance to, so only the applicable machines are showing up and get ran against. However, I am a few versions behind in server automation, Site Version 60, and I am not sure if they have put something else into place recently that I am unaware of. Also, I don’t know of a way to run anything from within Server Automation as a policy as of yet.
I think the thought behind Server Automation as of now is to be used for new server builds that you can manually trigger a plan after it comes up and performs an automated run of installs/configurations, not really for true hands-off automation. If someone else understands this differently, please let us know.
As far as a policy goes regarding server automation, you could potentially have a policy action set (not within the SA GUI) that when relevant, would use the Sever Automation REST API that could kick off an automation plan using the ID.
Hi guys,
We don’t yet support policies though it has been discussed from time to time.
We would definitely like to hear more about the use case though as we don’t have a good real world example yet to help drive this.
Cheers,
Martin
Hi @Mairt, our use case is that we need to apply maintenance to our SQL clusters each month. Rather than having to manually select the target endpoints from a list, we’d like it to run as a policy action against any applicable target, just like we currently do when deploying patching baselines.
1 Like
Hi Chris,
Sounds like a repeating schedule might also address this scenario or is there some characteristic of this that requires a policy rather than a repeating schedule ?
Cheers,
Martin
We can’t assume the same target list will run the same action on a schedule. The computer target list needs to be dynamic, based on a relevance/property evaluation.
Would targeting by group, where the group membership was re-evaluated each time a repeating scheduled plan was run, provide the required level of dynamic targeting ?
Is the group currently evaluated only when the action plan is pushed, and therefor a static group, or is the group more of a dynamic group where members can come in and come out automatically?
Hi there,
So when targeting a step by group, the plan engine evaluates the members of that group only when the step is actioned - in other words, the engine leaves it until the last possible moment to evaluate the targets for that step, i.e. the members of that group. Once that step action is running however, no changes to the targeted endpoints can happen after that. Based on that explanation, is group targeting something that could help you here?
In terms of plans as policies though, for a SQL clustering scenario, wouldn’t you need to know which nodes correspond to each other to ensure you always have at least one node in the cluster available? One danger with a policy approach for clusters would be in the case where all the nodes become applicable simultaneously and get patched at the same time.
We have discussed targeting steps by property in the past though, but it’s not something we currently have available. Is that, perhaps in tandem with a repeating schedule plan, something that might be helpful to you?
-Paul.
That sounds like the group targeting is via a “manual group” type, which doesn’t give us the dynamic targeting we need.
Yes, that’s a possible scenario for clustering, if it’s targeting relevance became TRUE on all nodes at ones. But we need to assume that the cluster’s defined patching window will be accurate. If the grouping is static at the time of the automation plan execution, then any new servers built/subscribed to patching after Patch Tuesday (when the plan is executed) won’t be eligible to get the automation plan executed on them because the plan has already been queued up. They will only be able to be patched for the first time in the following patching cycle, which is not good.
My votes is to have the same type of policy targeting mechanism as you do for non automation-plan content (fixlets, tasks, baselines, etc) for automation plans.
Thanks for the feedback - so my last comment there around the idea for targeting steps by property is coming from the targeting by property mechanism you’ve captured in your screenshot above. While an SA version might not look exactly the same, it would be based on the same principles.
There is an additional complexity though for plans with this approach when it comes to applying it in a policy situation… unlike fixlets/tasks/baselines where once we have a set of target identified (i.e. they satisfy the property selections), the endpoint can then just go ahead and process that action.
However for plans, each step can potentially target different computers. So in a policy situation, the plan would have to ensure it had at least one target for each step in the plan before we could execute it. Often times, the targets would need to be related, let’s take an example to show you what I mean by that:
Let’s say we have two running 3-tier web applications: a DB hosted on one computer, a web server on another and then a series of client computers. Let’s call the two applications as a whole APP1 and APP2
Let’s also say we have a “policy” plan whose workflow is this (and I guess a cluster plan would equally be valid here):
Steps 1-3: Stop the clients, web server & DB (in that order)
Steps 4-6: Patch the clients, DB & web server
Steps 6-9: Start the DB, web server & clients (in that order)
We can’t run this plan until we have at least one DB, one web server and one client machine to target.
We also need a way to ensure that the DB, web server and client are actually related to each other.
i.e. we wouldn’t want to target the DB of APP1 and the web server of APP2 in the same plan.
So there are a lot of complexities when it comes to autonomously kicking off plans, which is why it’s always good for us to hear of real life situations with customers to help us thrash out these use cases.
Currently we use Dynamic groups that are populated by relevance that looks at a couple of static settings we apply to the client. When we schedule a patch job, we choose the groups dynamically so if someone calls in at the last minute and says, we need to suppress patching on a server for some reason, we can quickly change the static setting on that server and the server gets pulled out of the group. The server is still listed as a target in that scheduled job, but it would then have a status of “Not Relevant” because it is no long in that group. If what I’ve read from your post, the SA Plan targeting for groups, whether the group is dynamic or not, is based on manual group type and the steps will still run on that server unless we stop that automation plan and schedule a new one. Is that correct? We also have cases where it is the opposite, we put in the static settings to add a server to a group and the scheduled job sees that and the server is ready to be patched. Does the ID 137 Dynamically run Baselines from a Site step work the same why where if I add a baseline to the targeted site after the Automation plan has been scheduled but before it starts, will it run that baseline against the endpoints or will not not run the newly added baseline?
Hi @tbooker,
Yes, that is correct.
For each step in the plan, the plan engine will “translate” any dynamic group targets for that step into a static list of targets before it creates the action for that step (this is because the plan engine MUST know exactly how many results it is expecting to receive for a given step, so that it knows when it can safely move on to the next step in the plan, and using a list of targets that can change frequently mid-execution does not really allow us to achieve that). Once is has worked out that list of targets, the step is essentially targeted statically.
For baselines from site, it works a little differently.
For a scheduled plan, there are really two phases of working out what baselines to run:
(1) When the plan action is first created, the plan engine will evaluate the contents of the specified site, and will start pre-fetching content for those baselines (if pre-fetching is enabled for the plan)
(2) At the schedule start time for the plan, the engine will again evaluate the contents of the site, and THIS is the content that actually will be executed by the plan.
For (1), we basically do a “best effort” for pre-fetching content, because anything that wasn’t prefetched by (1) will be fetched by (2) when the plan actually starts running.
So in other words, the baseline content of the site can be modified up to the scheduled start time of the plan, and those changes will be incorporated into the plan at run time. Hope this answers your question (I think it does, but let me know if not)
Cheers,
Paul.
Thank you Paul, it does answer my question. I hope they work on trying to develop a way to make it dynamic for both cases. It will be the only way to truly make the processes of patching and or server provisioning in a Private cloud environment quick and fully automated.