RuhNet

No need to search for other occurrences of Iterator() — unless you have custom stuff that uses it, the Trunkstore view is the only place it appears in the Kazoo v4.3 codebase. Nice replication script—I use a simple one written in Bash but yours is more informative. One thing you can do is add some delay (minutes) between replication requests which can keep from overwhelming a server. I’ve found that if I just machine-gun style replicate a bunch of DBs sometimes RAM and CPU get slammed. Also, if worse comes to worse and you have too many issues letting Couch replicate itself, what you can do is a manual clone—in other words instead of writing a script to tell Couch what DBs to replicate, you write something that pulls each doc individually and creates it on the target machine. This way takes longer of course, but can be useful if there’s corrupted data or some other issue preventing a normal replication from succeeding fully, and you also get an internal reset of revisions on the target, since although the data is the same, it is a “new” document on the target side, and doesn’t have all the previous revision tombstones hanging around. Also, although you aren’t doing this, for the benefit of other readers, you can upgrade Bigcouch to CouchDB v3, BUT you must first upgrade to v2, and then from there to v3.

Sure---and you are correct, it needs a redirect since the path has changed. All you need is something like this: frontend couch-5986-admin-port bind 127.0.0.1:15986 default_backend couch-redir-node-admin-port backend couch-redir-node-admin-port balance roundrobin reqrep ^([^\ :]*)\ /(.*) \1\ /_node/_local/\2 #http-request replace-uri ^/(.*) /_node/_local/\1 server couch1 172.31.12.34:5984 check server couch2 172.31.23.45:5984 check server couch3 172.31.34.56:5984 check If you are using a version of HAProxy v2.0 or later then comment out the `reqrep` line and uncomment the `http-request replace-uri` line.

Don't want to get too off topic with this thread, but: Couch v2 is the supported/approved version, but I use v3. You need to modify a Trunkstore view (if you use Trunkstore) and do a redirection of the admin port using HAProxy or other server like Nginx/Caddy/whatever. There is a thread about the Trunkstore view mod here in the forums. Placement and zoning depends on your cluster size. If you are in a single DC, then there isn't a reason to do multi-zone, unless you have a large number of servers. The most common scenario I encounter when setting up clients is they have 2 zones, and I recommend a minimum of 3 DB servers in each if they want full redundancy with good performance. Then for placement I usually recommend a 2+2 split; in other words put 2 copies of each document in the local zone, and 2 copies in the remote zone. NOTE that CouchDB zones are disconnected from and have no relationship to Kazoo zones---it's a totally different system. You could have a single zone Kazoo, with 5 Couch zones if you wanted, or vice versa. I generally recommend to have as few zones as you can get by with, both for Couch and for Kazoo. (I sent you an invite as well)

Worse case scenario we can cherry pick improvement commits and “front-port” them to v5 if/when it gets released publicly.

Thanks---that would be great if you could find out---it would solve the immediate issue of upgrading past unsupported CentOS 7 for v4.3 installs at least for Kamailio, since you already have the Rocky packages for Kamailio available. Even if the configs are incompatible we could work on fixing that, as long as the Kazoo module itself in Kamailio isn't doing something that's not compatible with v4.3.

@mc_ for Kamailio specifically---are there v5 breaking changes in the Kamailio Kazoo module itself? In other words, should it work with v4.3 if 4.3 Kamailio configs were used? Or have there been breaking changes to the Kazoo module of Kamailio?

@mc_ did you ever get the "official" word on this? I'm assuming since it's been several years that the version used with Kazoo 4.3 isn't a more recent version than what FS makes available publicly, so it would be nice to know which version/tag/commit of Freeswitch sources should match Kazoo 4.3.

Do you happen to remember the details of what you tried (which versions and how installed) and what the actual problem was? I notice there is a Freeswitch package for Rocky 8 at packages.2600hz.com but I don’t know if that targets v4.3 or v5.x.

Would be a good idea to start a new thread for this, since it's unrelated to the current topic.

is the number actually added to the account?

Must have been a temporary blip—it’s working now for me as well, but was not earlier today.

@fmateo05 Not sure why you would want to do that, but you can request deletion of your forum account by going to "Account Settings" and then the "Security and Privacy" section.

If you are willing to put in the effort to give that a shot, then it would be awesome! There are a few forks of Kazoo already, but most are private. One that is not, and what I would encourage you to start from, is the Sipengines fork, which is up to date with 4.3.142, but has a number of fixes applied, as well as the improvements to ACDC that Voxter made several years back. In my forked repo I have the Sipengines branch (4.3.142.itlevel3) as well as the stock 2600hz code, and some other [minor] improvements I've made on some branches. https://github.com/ruhnet/kazoo You are welcome to use that as a base. I can't necessarily commit concretely to help a lot, but as much as I have opportunity I would love to. I normally build Kazoo on Debian, as it is my server distro of choice, but building it on Alma shouldn't be any different really. Reach out to me if you have any issues setting up your build environment or need help. :) RE CouchDB v1 (Bigcouch) on Almalinux---Noooooooo lol. v2.x is the current "supported" version by 2600Hz, but I have always used CouchDB v3.x on my installs for the past 5 years or thereabouts (since v3 came out). It requires slightly different setup (the admin port 5986 has been deprecated), but is current and performant. I believe Kazoo v5 uses Couch v3 if I remember correctly (there is some code in master branch that references it).

Yes, those packages are only for Kamailio, Freeswitch, and maybe RabbitMQ.

In fairness to 2600Hz/Ooma/mc_ , I don't recall any time there was actually a promised date, only "targets", "projections", "estimations", "hopes", "plans", etc. Personally, I'd rather be told an honest hope/estimation/target and then it not be met, than to be promised something concrete and it not be met. The messaging from 2600Hz has been clear and consistent: v5.x will be released open source. The when is the only thing that has not been as expected, and the projections and time estimations have been extended/changed etc. Anyone who has worked on large software projects knows this is difficult to avoid. The Ooma acquisition has obviously further complicated and delayed things on that front. Have the delays shrunk the community size? I would say probably. But size or involvement of the open source community I would guess is not really high on the company's priority list, particularly in light of the minimal benefit the open source community has brought to the company. I suspect that this pattern of low volume of upstream contributions from the community may be common among open source software projects which have the combination of 1. being very complex and 2. being of high monetary value to users in a competitive industry. To replicate something as complete and useful for a production environment as Kazoo 4.3, using other open source projects that are available, costs literally at the very least several hundred man-hours of work. (Trust me---I've done it before: it's not nearly as simple or straightforward as slapping together Freeswitch, Kamailio, a DB and some other things.) So, whenever the release of v5 happens, it will of course be welcome. I'm not holding my breath, for obvious reasons, and will continue working with v4.3 until then. When v5 finally comes out, I'll see what can be done to merge the changes/customizations/improvements I have made to v4.3, and hopefully use it in my systems. :) 2600Hz/Ooma employees: don't read the following paragraph. LOL 🤣 And who knows---these delays may actually strengthen and improve the Kazoo community over a longer period of time: with Centos7 going EOL in a few weeks, current users of Kazoo that have no alternative solution are of necessity going to be forking and compiling their own releases. And once you've done that, the barrier to entry for contributing upstream becomes much lower than when you are a "yum-install-freeloader-gimme-gimme-person" 🤣. So it may end up being a good thing in the long run. 🤭