*Premise: I don't think we are not breaking down OpenWISP into microservices.*
My exprience with microservices is not happy. They make things a lot more complicated. OpenWISP 2 is modular, that gives us the advantage that we don't need to force people to write modular code by separating features in different services, which helps to keep things simple and ease maintenance. The modular nature of OpenWISP allows us to break a monolithic OpenWISP instance in different containers running different parts of it, but I would not call this microservice architecture. I want to do this break down of the monolithic OpenWISP instance into services because it will make it easier to assign resources to the different services that need to be scaled up. Let's not mention microservices anymore in this project because I believe it will fuel confusion. On Sat, Apr 6, 2019 at 8:30 AM Ajay Tripathi <[email protected]> wrote: > Hi, > > *Update:* I've added documentation for testing and building the > containers.. > > *Questions/Discussion:* > 1. About Database: > It looks like openwisp-radius and openwisp-controller can't migrate to the > same database. > Unlike the network-topology module which migrated to the same database as > the openwisp-controller, > I had to change the database name for the radius module. > Is this an expected behaviour or do we need to make openwisp-controller > database compatible with > the openwisp-radius database in the final version? > It's not the expected behaviour and it should not happen. I have some openwisp instances running fine with both openwisp-radius and openwisp-controller (development version of all openwisp modules). What issue are you having, can you paste the error you're getting? > 2. Migration problem with docker-compose: > When we run docker-compose for the first time. All the containers start > migrating parallelly which causes some containers > to fail in migrating. If we re-run the containers everything works fine > because the rest of the containers get a chance to migrate, > I think we need some kind of flag for the containers to communicate about > migrations in the first run. Please suggest on the same. > We should find a way to start the general admin dashboard container first, which should have all the django apps in INSTALLED_APPS, so migrations are run there. Then the other services can be started in parallel afterwards. > 3. Terraform creating order: > When the database server starts, it takes a while to allow connections on > port 5432. > But since terraform starts all the pods parallelly, some pods that try to > connect before postgresql is ready > and the pods fail, re-running the pods solve the problem but I could not > find how I can communicate to > terraform to let it know that database server is accepting connections and > dependand pods can be > created. Please advice how is it usually done. :) > The suggestion given by 2stacks seems good to me, if we need some dependencies to be up, we need to use all the tools at our disposal to wait until those service become ready (with a configurable timeout). I'll reply to other parts of the thread in my next email. -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
