22 Jan 2024 07:21 PM - last edited on 23 Jan 2024 03:02 PM by Michal_Gebacki
Since OS service entities create separate custom devices we are struggling to ensure that the mgmt zones we have always have access to all os services that run on any host apart of the mgmt zone. I've seen some things outlined in the post below but this is not feasible and scalable. Are we really expected to know the host group name or os services that run on these hosts? Yes it is somewhat simple to get the host group name but what about in situations where there are a lot of different host groups associated with the 1 mgmt zone? Do we really need to have 10 different rules to account for all of them? What about when hosts get provisioned any maybe get a different host group but are apart of the mgmt zone, we then have to go back in add in another rule?
I've played around some with the entity selector in relationships but am not getting anything better. I would hope there is a better way of capturing OS services in a mgmt zone, more of a 1 time rule creation vs constantly having to maintain the mgmt zone rules.
Solved! Go to Solution.
23 Jan 2024 07:58 PM
Hi there! Your concern may pertain to the naming convention for these host groups and processes. Other customers use their naming convention to "end with" or "start with" keywords to be universal for new host groups. For example, all hosts running these os services are oshost_1 or host1_os, so they are easily identifiable. Similar to how the solution does it in the post you provided:
type(os:service),fromRelationship.runsOn(type(HOST),entityName.startsWith("<name of the host>"))
In many cases, if the hosts or host groups are specific then yes, you will have to create a new rule to ensure they all map to the correct management zone. If anyone finds a better solution, feel free to build off this. Thanks!
24 May 2024 02:20 AM
Currently OS Services incidents are coming as P2 as it is going to Default Profile. How can we reduce this to P3?,