# BIG-IP : iControl LocalLBDataGroupFile.set\_local\_path()

**URL:** <https://community.f5.com/t/big-ip-icontrol-locallbdatagroupfile-set-local-path/17743>\
**Category:** Technical Forums\
**Tags:** f5-icontrol, icontrol, devops, data-groups, data-group-list, cache\
**Created:** [August 14, 2014, 10:06pm UTC](https://community.f5.com/t/big-ip-icontrol-locallbdatagroupfile-set-local-path/17743 "2014-08-14T22:06:53Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![BaltoStar\_12467](https://avatars.discourse-cdn.com/v4/letter/b/df705f/32.png) [@BaltoStar\_12467](https://community.f5.com/u/BaltoStar_12467)\
**Post date:** [August 14, 2014, 10:06pm UTC](https://community.f5.com/t/big-ip-icontrol-locallbdatagroupfile-set-local-path/17743/1 "2014-08-14T22:06:53Z")

</div>

F5 BIG-IP LTM VE v11.4.0 on ESXi

iControl re-cache data-group operation :

```tcl
LocalLBDataGroupFile.set_local_path()

```

For a live prod BIG-IP cluster with a VIP iRule that is actively reading data from the data-group , is the above considered a risky operation ?

e.g. attempt live-swap of data-group’s data-file, fails due to locks or other systems-level issues, data-group now unavailable to iRule

I’ve attempted live-update of a data-file’s contents via BIG-IP browser admin ( copy/paste new contents and click “Update” ) and seen the corresponding data-group become unavailable to the iRule. The paranoid approach is to create a new data-group/file and a copy of the iRule modified to point to this new data-group , and then in the VIP’s iRule list swap old/new iRules – so that never actually update a “live” data-group.

So now I am concerned about performing similar operation via iControl

```tcl
LocalLBDataGroupFile.set_local_path()

```

–- although apparently this API is not actually live-updating a cached data-file but rather re-pointing data-group to a new cached data-file ?

---

<div class="post-metadata">

**Author:** ![Kevin\_Davies](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/kevin_davies/32/1696_2.png) [@Kevin\_Davies](https://community.f5.com/u/Kevin_Davies)\
**Post date:** [August 16, 2014, 10:24am UTC](https://community.f5.com/t/big-ip-icontrol-locallbdatagroupfile-set-local-path/17743/2 "2014-08-16T10:24:42Z")

</div>

“…seen the corresponding data-group become unavailable to the iRule.”

Really? Thats very surprising. Adding entries to a datagroup from the GUI should never take it offline.

“eg. attempt live-swap of data-group’s data-file…”

Why would you need to do this? The F5 has a running config and a stored config. When you update a datagroup which points to a file you only need to update the file, then perform a config load to have that new files contents loaded into memory. It is also indexed at this time.

---

<div class="post-metadata">

**Author:** ![BaltoStar\_12467](https://avatars.discourse-cdn.com/v4/letter/b/df705f/32.png) [@BaltoStar\_12467](https://community.f5.com/u/BaltoStar_12467)\
**Post date:** [August 16, 2014, 11:05am UTC](https://community.f5.com/t/big-ip-icontrol-locallbdatagroupfile-set-local-path/17743/3 "2014-08-16T11:05:21Z")

</div>

Thanks for the response Kevin.

Please note that I am on BIG-IP v11. The data-group mechanisms you describe I believe apply to pre-v11.

New to v11, the operation

```tcl
LocalLBDataGroupFile.set_local_path()

```

immediately reloads & recaches an external data-group with the contents of the supplied data-file -- there’s no need to trigger BIG-IP to reload its config.

It is not recommended to directly update the local data-files BIG-IP self-maintains for each external data-group ( if you could even locate the file currently being used ). On create/update of an external data-group, BIG-IP auto-creates a new persistent data-file stored in a special directory. This data-file’s name is constructed as the data-group name appended with a unique identifier and revision index to track history of changes.

My concerns are that on reload/recache of very large data-sets ( 1M+ rows ) something goes wrong and the data-group becomes unavailable to those iRules that reference it.