Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #781 from ionutrazvanionita/dlg_profiles
[dialog] flag for replicating profiles
- Loading branch information
Showing
7 changed files
with
243 additions
and
188 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
2b8fd2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So going forward, to replicate dialogs over the binary interface, you must throw the /b flag in modparam?
2b8fd2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@46labs yes. /s for cachedb sharing, /b for sharing through binary interface. If no flag set, profile is not replicated. Also you can't do both cachedb and binary interface replication, simply because it makes no sense.
2b8fd2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you need to specify the /b both in the modparam as well as the script? An error is thrown if the profile name doesnt match the profile name in the modparam...so if a profile named "calls" was previously in the modparam, then it needs to be changed to calls/b and the script also needs to be changed to calls/b? Ie you cannot have calls/b in the modparam and just calls in the script.
If that is the case, then it can break all kinds of external scripts that rely on consistent profile names, and also requires that you update an entire cluster of servers at a time to effect this change.
2b8fd2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. That is the logic behind the profiles, didn't want to change that. The same story is if you use '/b' for a profile. Perhaps that shall be changed in the future.
2b8fd2d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ionut,
Right, but this requires all cluster members to be running at least the same source. If any programs are written that parse profile names external to opensips (either through fifo or http interface) have to be rewritten to handle the change. Can the flag not be thrown in modparam only? Or, what would also be suitable would be to throw a flag in modparam that makes all profiles either use /s or /b?