Thought this was interesting to add some confusion 😁 https://www.reddit.com/r/django/comments/6cp4gw/multiple_projects_shared_auth_single_signon/
On Sat, Apr 6, 2019, 2:08 PM A Stanley <[email protected]> wrote: > 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.
