write mem?

I'm not sure I understand what you mean by "to do a write mem". Do you mean to save the running, in-memomy config out to disk? Can you elaborate please?

 

 

Loc

Yes. I have noticed that when I take a DIP out of service, the change does not get written to disk. Therefore, if the Bigip device crashes, any state changes are lost.

 

 

thanks

To save the running configuration, you can use the System::ConfigSync::save_configuration method. The SaveMode flag indicates how much information to save. Here's the documentation from the SDK for the SaveMode flag:

 

 

SAVE_FULL - Saves a complete configuration that can be used to set up a device from scratch. This mode is used to save a configuration that can be used in a configsync process. The filename specified when used with this mode should NOT have any path information, since the file will be restricted to a specific directory used in configsync. If the specified file does not end with the ".ucs" suffix, a ".ucs" will be automatically appended to the file.

 

 

SAVE_HIGH_LEVEL_CONFIG - Saves only the high-level configuration (virtual servers, pools, members, monitors...). The filename specified when used with this mode may contain path information, such as "/var/tmp"... If there's no path information, the file will be saved to /config by default.

 

 

SAVE_BASE_LEVEL_CONFIG - Saves only the base configuration (VLANs, self IPs...). The filename specified when used with this mode may contain path information, such as "/var/tmp"... If there's no path information, the file will be saved to /config by default.

 

 

Hope this helps.

 

Loc

 

Does this configsync method also cause the config to be replicated to the backup Bigip box?

 

 

thanks

No, this method just saves the configuration, it does not synchronize the configuration. If you want to synchronize the configuration, use System::ConfigSync::synchronize_configuration method. Please check the SDK documentation for further information.

 

 

Loc

I suspect there may be some confusion as to wayney's question. Wayney is not asking how to generate a UCS file which would be the equivalent of a "b config save " command from the shell and which is the way I interpret the method you listed above.

 

 

Wayney is asking how you use iControl to make a change on BIGIP to the disk instead of just memory. A good example is if you say take a Member offline. He would like the change to be replicated not only to BIGIP's memory (so that a "b list" shows the change) but also to disk so that the change can survive a reboot (and thus a "cat /config/bigip.conf" would show the change as well.

 

 

Thus he is asking for the iControl equivalent of a "b save all" from the Shell which would write any change in memory to disk on both the bigip.conf & bigip_base.conf files. Perhaps, writing to memory & disk at the same time is inherent to all iControl changes but from Wayney's internal testing it doesn't appear that this is the case as I can see his iControl calls change the config in memory but not on the disk.

 

 

Given this, what do you feel would be the best way to accomplish this? Thanks for the help and the lightining fast turnaround as always.

 

 

I was writing a response and Loc beat me to it...

 

 

One other thing to mention is that you can override the default filenames of "/config/bigip.conf" (SAVE_HIGH_LEVEL_CONFIG) and /config/bigip_base.conf (SAVE_LOW_LEVEL_CONFIG) by passing in a value for the filename. These files are not limited to the "/config" directory and you can also specify an alternate directory if you desire. If you want to use the defaults, just pass in an empty string.

 

 

For SAVE_FULL, a filename is required and cannot contain alternate directory information. If you don't append a ".ucs" to the filename, it will be appended for you.

 

 

-Joe

We've found that in a large majority of the cases, the low level config (vlans, selfips, etc) are not changed that often beyond initial setup. The high level config (vips, pools, etc) are changed much more often and that is why bigpipe segmented the two and iControl has followed in those footsteps. It's also our belief that, in general, customers don't want to do anything with the low level config once it's set.

 

 

If you have a compelling need to issue both commands in a single command, we can look at adding a new method to handle this, but since both configurations are stored in separate files, the api would require two filenames to be passed in which is kind of clunky.

 

 

-Joe

I agree with you that customer make the majority of changes to the bigip_base.conf upon 1st setup so I can see that it is logical to segment the changes into 2 methods to protect the customers that don't want to accidentally change anything. I think the best option is not to combine the 2 methods into one but to simply add a 3rd method in for customers that want to write all changes at once while retaining the 2 ones you already have.

 

 

The 3rd option (b save all type of a thing) is good so that when you issue a certain command so that you can be certain that any change you just made gets written to the BIGIP's disk regardless of which file it's in. This is especially helpful because there are always cases where some BIGIP operators know BIGIP better than others, and so it's easy to get an inexperienced person who doesn't know what F5 stores in 1 file vs. the other. This also sort of holds true in that most devs at big corporations writing code for BIGIP may not know all of the ins & outs of which files store which info so giving them a an easy 1 line method that does it all may not hurt.

 

 

Just my 2 cents for what it's worth. Thanks again.

I don't claim to understand all of the ins & outs of what it would take on your side, but if you are asking what I think the ideal way to handle it would be, I would say create a seperate method that doesn't take in any filenames. Just create a seperate method and then have the right filenames to perform the save be programmed in on your side so that they are abstracted from the customer.

 

 

The benefit there in my mind is that if F5 decides to change the filnames from bigip.conf & bigip_base.conf in v9.2 to whatever then you guys own updating the method to reflect the new filenames vs. me owning that which is the right thing to do here. That way I don't have to worry about breaking my iControl Apps if i upgrade since I am essentially hard-coded to the old filenames.

 

 

Hopefully I am answered your question but I may be missing some of what you are asking here. If so, just give me a call. The usual suspects should have my phone if you don't already.