RuhNet

I meant that their releasing anything open source is a "side gig" since it's not integral to their business at this point.

LOL -- I'm working with some companies on projects that are taking even longer than that. But the thing is, Kazoo v5 is completed and has been in production for several years. It's just the open source release of it that has been delayed. Now, that's not to say that they _couldn't_ have released it sooner if things were planned/managed better. But the thing is, they run a business, and releasing the open source code is only a "side gig" thing and isn't actually a huge benefit to the business side of things (it is some, but not nearly as much as people think). Clearly the open source release isn't their "priority" or it would have already been released, but that doesn't mean it isn't an important thing on their list; and that is why this amount of time, although painful to all the persons waiting on it, isn't unreasonable.

He's just speculating. Most people don't understand the complexities of a large project like Kazoo, so it's very common for many to assume that multiple delays == cancellation. When in reality that isn't the case. I don't have any inside information on it, but having worked on some large projects myself before, 2600Hz/Ooma's timeline for bringing it out, although disappointing and frustrating so far, isn't a clear indication of Kazoo v5.x staying closed source.

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.