I think points 1. and 2. are very much related and common to scenarios of breaking down a monolithic application in to micro services. I could be wrong but from what I've been reading I think its recommended to have a common build for django. Not all apps will be enabled in the django config and not all instances will have the same url config but for common models in either openwisp or for dependencies like allauth, trying to run migrations in parallel from different instances is risky. I'm not an expert on this and still learning meself.
If you look at a celery workers build its basically a replica of your base django app with celery services as the only delta. Also I'm not sure if each openwisp service instance (container) should have it's own django-admin or if there should be a master admin interface colocated with one of the instances. I think that depends on how the current build of openwisp behaves. Again this is uncharted territory for me. I've been reviewing you repository. Very impressive. I'm confident you'll figure it out. On Sat, Apr 6, 2019, 1:45 PM Ajay Tripathi <[email protected]> wrote: > Hi, > > On Saturday, April 6, 2019 at 8:54:36 PM UTC+5:30, 2stacks wrote: >> >> 1. I'm pretty sure they need to share user table information but I'll >> defer to Federico. Do you know the exact issue? >> > > I was thinking about the user table as well, I will investigate and report > back. > > 2. I've been researching this lately as it pertains to running >> django-admin on a seperate instance (container). Its recommended best >> practices that migrations only be run from one container when multiple >> containers share a code base or models. >> > > Okay. Thanks will look into it further. > However, I think making a container for running all the migrations might > have a huge cost. We already have a lot of services and in future we will > have more, so the container responsible for having all the modules and > their dependencies for migration will start becoming bulky. What do you > think? > What do you think about a control variable that allows only one of the > services to migrate at a time ? (The rest stay in a while loop until the > control variable allows another service to start it's migration.) Let me > know If I should elaborate this idea further. > >> >> 3. I use a combination of shell scripts and docker entry points. Check >> out >> https://github.com/eficode/wait-for and >> https://github.com/2stacks/freeradius-django/blob/master/compose/django/entrypoint. >> >> > > That's perfect, thanks, I'll implement this in the prototype. > > It's also possible in Terraform to create things with implicit >> dependencies. I haven't tried with Kubernetes but I'm sure it can be done >> https://learn.hashicorp.com/terraform/getting-started/dependencies.html. >> > > I tested terraform's dependencies, actually they only wait for container > to start running and not the services inside the container. > However, When I incorporated the entrypoint solution mentioned above, I > think this problem will also be solved. > > >> Hope this helps. >> > > Yes, many thanks. :-) > > Best, > Ajay Tripathi > > -- > 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. > -- 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.
