How can I generically get all LB objects & attributes via iControl?

Sorry for the delay.. I was traveling yesterday and the message hit me in the air!

 

 

I guess I'm missing the point of your exercise. Why would you want to store F5 proprietary formatted objects in your system?

 

 

The config file format on the BigIP is a mechanism for F5 to serialize the configuration so it can be preserved and recovered through file system tools on the control plane. That's really all it is. It is not really an externally exposed schema or a suggestion of one. In fact the file configuration gets put into a config database format on the BigIP itself for other tools F5 writes to access configuration object (so those tools don't try to understand the file format).

 

 

In fact it is not supported to load config file 'fragments' cobbled together (while it may work if you are good at it ). You are supposed to use a valid configuration client like bigpipe(pre v11), TMSH (v10+), GUI, SNMP, or iControl. These clients read, or in some cases change, the running configuration which then 'can' be serialized into full configuration files for archival via file system tools (like tar which is used in the ucs archives). The iControl System::ConfigSync interface is there to let you archive/upload complete config files so you can build your own archival system, not construct a config from 'fragments' and use the load mechanism to configure the BigIP. The serialized file format was only ever meant to be relevant to F5 tools on the BigIP control plane, like bigpipe or TMSH.

 

 

For programmatic remote access, the serialization format is SOAP rpc encoded XML, and the get_list methods on the various configuration objects is how you 'walk' the config. There is no generic 'get_all_box_config', because F5 doesn't force an object model on your systems. The object format presented by the iControl exposed structures can be a strong hint as to the schema you can use in your data access objects, but it certainly isn't a requirement. You can use whatever data access schema is preferred in your model or programming language. If the model wants to store data as serialized JSON or XML.. great, but it doesn't have to look anything like the BigIP config files. Most data access schema reflects what is relevant to the design goals. Don't inherit things from the F5 file formats you don't need, want, or that does not fit in your data model.

 

 

If you are looking for a tool to automate the archival and restoration of BigIP configurations, take a look at F5's Enterprise Manager. That's what it is built to do.

 

 

If the goal is to capture whole BigIP archived config in a CMDB or DMS for restoration or comparison, use the System::ConfigSync interface.

 

 

Did that help?