I'm wondering what's the default behavior of the BIG-IQ when re-import BIG-IP device configuration with deleted items on the BIG-IP. It seems that the previous imported configuration items still reside on the BIG-IQ, although they are deleted on the BIG-IP device.
For your reference, the BIG-IQ is NOT our source-of-truth, means configuration changes will still be made directly on the BIG-IP devices. The referenced items will be displayed as not in use anymore on the BIG-IQ, but they are still there.
How can I achieve that such items will also be deleted automatically on the BIG-IQ? During import process I also set "use BIG-IP device" for any configuration conflict types. But still no difference after re-import.
Regards Stefan 🙂
@Stefan_Klotz Sadly this is one of those things I don't believe you have any way of sorting this out automatically and it would require you deleting the entries before re-importing devices. I could definitely be wrong on this one but in the past I have always had to delete these manually before performing a re-import.
Thanks @Paulius for the quick response, although this is very disappointing 😞
Are you aware if this maybe changes or will be fixed in any upcoming software update (currently we are still running 18.104.22.168)?
Or is there any possibility to delete all non-assigned configuration items on the BIG-IQ (similar to the BIG-IP GUI, where you can select all items from a list and simply click on "delete", which only deletes those, which are not referenced -> I tried this on the BIG-IQ, but it stops deleting, when one referenced item is detected.)? Or maybe simply delete all previously imported configuration items (in one step) before re-import all BIG-IP devices again -> but I assume this will also delete all statistical data (so this wouldn't really be an option)?
Regards Stefan 🙂
@Stefan_Klotz - sorry to see that the desired behavior is unavailable.
I kinda wanna mark @Paulius' reply as Solution just to make it more obvious that it is right (if not desireable).
...as a side note, I wonder if you have found out whether it is, indeed, fixed in a later version? and if not, maybe an ENH request with Support?