I'm not clear what do you mean by "configure *all* configurable options". Does it mean the option value be set to *all* for all the options in filer storage system configurations? All options don't accept *all* as valid entity. So I assume you me be talking about for the ones that do.
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.
To add, here is the customers full wish list for the configuration management:
Wants to be able to store, protect, edit, compare, monitor, and push all configuration files for each controller. The compare function is particularly important for HA pairs and clustered systems. The files to be controlled includes, but are not limited to: /etc/rc; /etc/hosts.
Monitoring these files includes generating an event if the files are modified outside OpsMgr's control.
Wants all configuration information stored in the OpsMgr database and available via export or API/SDK/ODBC to be linked to customers CMDB (Configuration Management Database).
Wants the configuration info stored in the database to be able to be pushed onto the controllers. Likes existing template functionality, but wants it extended to be able to use template + unique information and to be able to be pushed to the controllers, and reported upon.
Wants to be able to configure the RLM/BMC file in OpsMgr and push the configuration onto the controllers.
Wants to be able to set registry options through OpsMgr.
Wants OpsMgr to monitor all options, configuration files, and registry and to generate an event when any are changed outside of OpsMgr.
Here is the customer's proposal for configuration management.
It is more like a result of a brainstorming so there are so many question unanswered and I am sure more will come later if this idea would be implemented.
1. Possibility to edit all configuration files
2. Usage of templates.
Template is contains informations: - directly edit options - indirectly edit options throught an abstraction layer - edit configuration files - execute ONTAP commands - variables - other templates can be included
3. Replace interactive command like ‘cifs setup’, ‘securadmin setup’ etc with non-interactive version. Possibly create the abstraction layer to execute these task. I have no information if it is documented anywhere how to add a filer to the domain without manual intervetion.
VIF_network_config.template: <config_file: /etc/rc> # VIF config comes here </config_file> DNS_conf.template: <config_file: /etc/resolv.conf> nameserver $local_dns nameserver $global_dns </config_file> run options dns.enable on
vol0_snap_config.template: run snap reserve vol0 5 run snap sched vol0 10 1 1
The template below assigned to the server which is about to configure:
filer1_config.template: include Global_config include Budapest_config include VIF_network_config include DNS_conf run options cifs.comment “Ready” run vol size vol0
Actually this development would lead to a complex configuration management software but it would be very useful for the customers especially if the additional abstraction layer would be inserted between the template files and the NetApp configuration. (example: configure the network interface but the abstraction layer knows which file/options to modify)
Is it on the roadmap to integrate all of the "uncommon" options to the Configuration Management tool through operations manager?
The customer has multiple controllers located globally with each requiring different host configuration. They would like for the CM tool to encompass all options available via OnTap rather than needing to configure each through OM then on the filer.
If this is not on the roadmap, how could we see this get added?
have you got any answer for this request? Seems it is still not there now. I have started using DFM/OnCommand Core for our customers and this is exactly what I miss. It is kind of ... disappointing ... something you can manage, something not ..... although the options seem equal in importance.
thanks for response - the reason for the request (managing /etc/hosts via config mgmt) - we want the (NetApp filer) environment to be as independent of the rest of the infrastructure (DNS here) as possible - FOR ITS OWN FUNCTIONS (like SnapMirror replication etc). So we put all names/IPs of our filers/vfilers to the /etc/hosts.
Another think would be you can check the content for changes.