rhythnic
commented
5 years ago A minimal first attempt at a TTN v2 account server is stashed in branch "issue-208" in "docker/configuration/ttn-account-server". Changing courses to attempt to use new devEUIs and manually remove applications in TTN console.
Background
This requirement is mainly targeted at resolving #207 .
TTN and our test data
Another consideration is that v2 of TTN doesn't delete applications, so the applications and devices generated by our tests are not being deleted from the TTN account server. v3 reportedly supports deleting an application, so it might be possible to delete old test data once v3 is released, but it may not supported deleting archived applications. At one point, the TTN console used the word "archive" and not "delete", but now it says "delete". I don't know if it's just a change in the UI or functionality. Most of the info I was able to find is about 18 mos old. As evidenced by #207, I think the application and device records are not deleted. Anyway, it's another consideration for running TTN locally.
TTN Architecture
TTN has a distributed architecture comprised of several smaller services, most of which are open source and available as different commands in the ttn docker image. There is a guide for running these in docker. It requires adding 7 services to the docker compose files already in place, as well as configuration, generating certificates, etc. Redis and Mosquito are required dependencies, but they're already in our docker-compose.
The account server is large TTN service that is closed-source for v2. The v3 account server will be open-sourced. The account server manages users, applications, gateways, devices, etc. as well as authentication and authorization.
Requirements
In addition to adding all the TTN services to the docker-compose, we'll need to implement our own version of the TTN account server. It's no small effort, as it's a monolith. We might be able to get by with stubbing out some of the resources, like gateways, but we'll need to implement all the authentication and authorization bits. There are some background requirements for the authentication/authorization parts, but it's not at all inclusive of all that needs to be done to implement the account server.
Considerations
I haven't found a release date for v3 online. The v3 milestone on Github is at 50% completion. I've read twice in TTN blogs that they'll not compromise quality for a faster release of v3. There are some things to consider before beginning work on this issue. Should we wait for v3 or is it too far away? How long will it take to implement a bare-bones TTN account server? Do we try to hack/fix #207 without running TTN locally? Would it be better to commit resources to lpwanserver development and possibly delay TTN support, or delay lpwanserver development in order to support TTN?