New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/flush #97

Merged
merged 5 commits into from Sep 2, 2014

Conversation

Projects
None yet
3 participants
@realloc
Contributor

realloc commented Jun 12, 2014

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

@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Jun 13, 2014

Member

Ok.

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.

Also:
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.

Member

ydahhrk commented Jun 13, 2014

Ok.

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.

Also:
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

This comment has been minimized.

Show comment
Hide comment
@realloc

realloc Jun 13, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Jun 25, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@realloc

realloc Jun 25, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Jun 25, 2014

Member

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

Member

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 added a commit that referenced this pull request Jul 3, 2014

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