Sometimes flushing all entries from the pool is very useful. Using shell script for this lacks "atomicity".
Begin adding flush option for v4 and v6 pools.
Add flush operation to man page
Change arg letter
Add flush functions to userspace tool
Naive pool flush
I'm sorry; we don't have anything against including this, but this iteration has had a lot of merging conflicts, and this is going to add more, so we wish to postpone it to version 3.1.6.
Can you please tell us what kind of situation has prompted you to want this feature?
I know I'm going to want to include that in the documentation.
It can be used in configuration scripts when you want to make sure you don't have any addresses in the pool other then ones set from your script. Also I wanted to use it in chef cookbook for jool.
By the way:
I just opened #100.
A BIB entry's IPv4 address always comes from the IPv4 pool.
A session entry's local IPv4 address always comes from the IPv4 pool. A session entry's remote IPv6 address always comes from the IPv6 pool.
When an element from a pool is removed, its BIB and session entries are no longer useful. Up until Jool 3.1.4, these orphan elements would not be removed from the database until they expired; with #65 we've been working on a different model where the destruction of an element from the pool immediately triggers the destruction of its BIB and session entries.
When you call your implementation "naive", I assume that you mean that flushing a pool doesn't cascade to the rest of the database. We're planning to remove this "naivety".
Does this somehow conflict with your use cases?
One thing you might want to keep in mind is that, if the destruction of a BIB or session entry fails (eg. because some other thread is using it at the same time), Jool will refuse to remove the respective element from the pool and the userspace application will ask the user to try again. That is, this cascade business adds a somewhat maybe likely chance of failure when Jool is under heavy traffic.
Feel free to ask back if I've failed to explain something in a satisfactory manner.
Yes, your assumption about "naivety" is correct.
Do you plan to add some 'force' flag? The main reason one may want to remove address from the pool is stop using it. If I understand you right, under heavy load it would be difficult to remove pool entry other than looping until success for undermined time. Force option falling back to 'not very clean' behavior could solve such problem.
Fair enough; we hadn't thought of leaving a 'force' option.
Thank you :)
issue #97 The code was ready and made by @realloc, Added delete casca…
…de when one of the pools were flushed or removed.