Do changes made thru iControl persist across power down&

Joe,

 

I thought save_configuration() method is merely for saving a COPY of the configuration information on to a file which could then be uploaded on to another BIG-IP box to create identical configuration. Do you mean that this method, in addition to doing what I describe above, also has the "side-effect" of committing the latest configuration information to disk (i.e. /config/bigip.conf & /config/bigip_base.conf)???

 

Thanks,

 

Karthic.

Karthic, It turns out that saving state to disk is a costly event (in CPU and disk usage). When designing the usage of iControl we had two options to model from. 1) the CLI bigpipe command where all commands are not persited until a "bigpipe save" is performed. or 2) the GUI where each page submission causes a persistent save to occur.

In our initial usage analysis we found that the impact of causing a config save on each iControl method would cause the client applications that relied on immediate response to be delayed too long inbetween calls.

So we opted for the bigpipe model where a "save" command is needed to persist state. You can do this with the

void save_configuration( 
     in String filename, 
     in SaveMode save_flag 
 );

method. Give a filename specifying the .ucs file to be stored in the /usr/local/ucs directory.

-Joe

Actually, depending on which version of BIG-IP you're using, starting in 4.5 PTF 05 the ConfigSync::SaveMode flag indicates how the configuration would be saved:

 

 

SAVE_FULL & SAVE_COMMON: Saves a complete configuration that can be used to set up a device from scratch, i.e. UCS file.

 

SAVE_HIGH_LEVEL_CONFIG Saves only the high-level configuration (virtual servers, pools, members, monitors...), i.e. bigip.conf.

 

SAVE_BASE_LEVEL_CONFIG Saves only the base configuration (VLANs, self IPs), i.e. bigip_base.conf.

 

 

Loc

That is what it's for but currently there is no method to just save the state to disk (/config/bigip.conf, etc). The save_configuration() will do this before it packages up everything into a .ucs file.

 

 

-Joe

Joe,

 

Since I care only about committing the state to disk and NOT about the copy of configuration in .ucs file, couldn't I just hardcode the file name to, say, "blah.ucs"? OR would I have to come up with a new name every time?? In other words, would BIG-IP fail the call if "blah.ucs" already existed??

 

boy, it sure would be nice to not have to play these games.

 

Thanks,

 

Karthic.

You should be able to call it whatever you wish. blank.ucs would be a valid choice. As Loc mentioned you can pass the SAVE_HIGH_LEVEL_CONFIG ConfigSync::SaveMode flag to trigger only the high level objects saving (VIP, Pool, Members, Nodes, etc). This is essentially a bigip.conf save which is equivalent to the "bigpipe save" command.

 

 

I understand the issue with a non-autocommit mode with our interfaces but we believe that giving control to the client is much more powerful and it also will significantly decrease the resources needed to support the iControl methods.

 

 

-Joe