Feature/flush #97

merged 5 commits into from Sep 2, 2014


None yet

3 participants

realloc commented Jun 12, 2014

Sometimes flushing all entries from the pool is very useful. Using shell script for this lacks "atomicity".

Stanislav Bo... and others added some commits May 29, 2014
ydahhrk commented Jun 13, 2014


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.

realloc commented Jun 13, 2014

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.

@ydahhrk ydahhrk self-assigned this Jun 24, 2014
@ydahhrk ydahhrk added this to the 3.2.0 milestone Jun 24, 2014
ydahhrk commented Jun 25, 2014

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.

realloc commented Jun 25, 2014

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.

ydahhrk commented Jun 25, 2014

Fair enough; we hadn't thought of leaving a 'force' option.
Thank you :)

@ydahhrk ydahhrk assigned dhfelix and unassigned ydahhrk Jun 27, 2014
@dhfelix dhfelix added a commit that referenced this pull request Jul 3, 2014
@dhfelix dhfelix issue #97 The code was ready and made by @realloc, Added delete casca…
…de when one of the pools were flushed or removed.
@ydahhrk ydahhrk merged commit f91963e into NICMx:master Sep 2, 2014
@ydahhrk ydahhrk modified the milestone: 3.2.0 Sep 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment