mc_

@Kirill Sysoev you live!!! Tell me more about potatoes on KAZOO? Are they in vodka form? And I agree, the platform is becoming more general purpose for building apps that can leverage the scaling bits in KAZOO. Almost borg-like...

It is done! Community-supported apps can be found here: https://github.com/kazoo-community 2600Hz-supported apps can still be found here: https://github.com/2600hz Look for kazoo-{APP} repos like kazoo-crossbar. The kazoo repo itself still serves as the focal point for pulling in core and apps, tooling, CI, etc. Changes to the Erlang code will be committed to the individual repos. There's still a lot of work to do (like linking changes in two or more repos) and general workflow improvements, but this is an exciting step! Plus I may never get a commit stat like '+490 −717,630' again!

Not sure what OSes will be targeted. I think CentOS7 will continue and hopefully a Debian variant. Not sure on timeline for CentOS8 though...

@btracht00 hmm, didn't know there were 3.22 still active lol We weren't planning on keeping the 3.x->4.x migration stuff in there with 5.x so I would say you'll need to upgrade to 4.x first, then 5.x once its available in the packages.

Hi Folks, Its finally happening! We are separating the KAZOO git repository into multiple repos, one for each kazoo application (and one for kazoo core libs). This Friday, May 1st, at the end of business hours Pacific time, all remaining pull requests will be closed from the main kazoo repo (the Erlang team here will be working hard to merge as many before that time). Closed PRs will be asked to be re-opened against the appropriate repo(s) starting on Monday. The breakening will occur over the weekend. The workflow for KAZOO development will be a little different in the bootstrapping phase - you will define the applications you want to include (crossbar, callflows, whatever) and they will be fetched just as we fetch 3rd party dependencies now. The apps will still live under applications/ so most existing tooling will continue to work as expected. We realize there will be some pain points in the transition. We want to hear what you're butting up against so we can build tooling or refine process to make development a more pleasant experience. Community apps like ACDc and Konami will be moved to a new Github organization: https://github.com/kazoo-community If you would like to be added as a contributor or maintainer of a repo under that organization, let me know. Eventually we'll get a proper organizational structure but for now, the leading community contributors are going to be auto-accepted if they ask to be included on those repos. What that means is 2600Hz will no longer be in the mix for reviewing/merging pull requests. The community around each app will be able to move forward as they see fit. This is a big step and we know there will be a period of adjustment for everyone, 2600Hz engineers included. If you have further questions, please ask here and I'll clarify as necessary. Thanks!

By "funny money" I mean when you want to issue a service credit to your customer, say give them $20 for whatever reason, there's no credit card to charge or otherwise. It's just you updating their ledger with some "money". "real money" is when a CC is processed and those funds are added to the account to pay for services.

Could be a ulimit issue? Check those settings, make sure you have enough file descriptors...

Possibly permissions on the database files themselves (I think they're under /srv/dbs ?). Try accessing a single bigcouch node and see what its logging. Also, n=4 (or any even number) is problematic in a network split. It is generally good to have n be odd to make it more likely to have a majority on one side of the split.

As the SSO stuff is still a work-in-progress, the docs are evolving as we go. We have an internal doc for setting it up but there are still a lot of details to work out before it is ready for release to the broader community. Of course, if you are familiar with the SSO flow of OAuth you can probably figure it out but a comprehensive guide is not currently ready for release.

jonny5 is a reference to the movie Short Circuit; the kazoo app tracks limits and balances for accounts and does authorization for resource-consuming calls. In other words, it short-circuits calls that are not authorized :p For numbers, check out https://docs.2600hz.com/dev/doc/internationalization/numbers/ You'll probably want alternative prompt languages too: https://docs.2600hz.com/dev/doc/internationalization/prompts/ While most of the 2600Hz team is US-based we do have a number of devs outside the US as well as a group of community members outside the US too. We all want KAZOO to be a proper platform for any region of the world. That said, we also know we have blind spots of how telecom is done everywhere so any feedback you have which can be incorporated into the project for everyone to take advantage of, is greatly appreciated. Also, when you feel you need to look at code or the docs aren't sufficient, ask here in the forums - that's usually a good trigger for someone to take a stab at improving the documentation. You are always welcome to submit PRs for improved docs as well.

For support, free options include this forum and IRC; you can email sales@2600hz.com to see about dedicated support plans. For open-source builds you are probably best served with the 'dev' docs site: https://docs.2600hz.com/dev/ Also the 'sysadmin' docs site: https://docs.2600hz.com/sysadmin/ Both are great places to contribute to the project if Erlang code isn't something you want to take on at the moment.

You "use" DIDs by assigning them to an account and creating a callflow in the account to run when receiving calls for the DID. There are no zone restrictions on that.

I believe rating will debit via ledgers but things like auto top-up and such use transactions