DX Unified Infrastructure Management

Hi,

currently there seems to be lots of different ways probes are storing their configs. Here are some examples:

1) oldschool way: everything is stored in probe.cfg. Most of "old" probes configured with IM work this way

2) mixed way: all the normal configurations are stored to probe.cfg, then new features are in other places like those ToT/TtT thresholds are under prediction_engines file structure, if I remember correctly they are zipped text files. Most of "old" probes use this way when you just apply new ToT/TtT settings through admin console to them

3) adminconsole-only way: some configs are in probe.cfg then all actual monitoring/thresholds are in zipped json files under probe file structure (examples are vmware and xendesktop) + also ToT/TtT in prediction_engine. No documented, official way to copy settings from a probe to another, though workaround found.

4) IM-adminconsole mixed way: probe can still be configured with either IM or AC, but those configurations are not compatible with each other, so what you have done with IM are not seen in AC. Some configs are stored in probe.cfg, those that you do with  AC are in alarms.cfg. + also ToT/TtT in prediction_engine (example here sqlserver and oracle latest versions). No idea if there are also something else new than that alarms.cfg and if that/those could be copied from a probe to another.

Are there any documented way that a user with some thousands of robots in their environment could handle all these in a proper way? = in a way we have used to: drag and drop with IM, use callback to distribute etc.

Are there any documentation about these new configuration ways? What files are used, what they include, how to copy them from a probe to another, how to include those in probe packages... So far only thing I have found fro point 4 is that pls note that those configs are not compatible, no explanation how/what/where.

If those configs are copyable then is there a documentation how to do that manually/using REST /using callbacks?

I know MCS will hide all these things under the hood, but as far as I think, that system is not yet production-ready when looked in how that is currently managed. And in the end of the day we UIM admins need to know where that information is stored, how to check what actually is there on robot/probe, how to debug etc.

OK, this could also be an idea about "pls document the changes", but hopefully a question gets some answers quicker that idea goes to production.

I am more than happy to learn that I have just not read the correct documentation yet, so if there are some knowledge about these, please let me know.

Thanks for highlighting this.

Let me work with engineering on this  and get back for clarification and guidance.

garav01

And maybe to phrase the need in an alternate way, any UIM environment that has more than half a dozen unique purpose servers will be taking advantage of some sort of automation - be that saving configurations in the archive, using REST calls to update settings in the field, using the controller get/set call backs to change configurations, scripting mass deployments, automating configuration validation, etc. 

MCS has been a nonstarter since it's inception years ago in an attempt to automate the process and kind of like the way the Dashboard portlet and IM were treated, new feature and new functionality ran rip-shod over established norms. All the while harming the existing user base.

I think that I understand why prediction and baseline work the way they do but why did they have to be completely different in storing their configuration from the other probes? JSON is easily represented in the CFG-XML style - just need some carriage returns really. And for that matter why sprinkle the configuration files around? Or like the log file settings from the Java logging where you get to have multiples places to set the same sort of setting that's maybe used or not used.

 UIM is supposed to be a single product but to its users it really feels like five or six separate products. And it feels like some of the product groups think that they're smarter than the status quo and that gives then the justification to change the way their part of the product works.

If you pay attention to the fluff at CA World, it's all about interfaces and APIs and interoperability and rapid release. This sort of plethora of configuration files flies in the face of that in my opinion.

-Garin