Hey Ajay, On Sun, Mar 24, 2019 at 5:23 PM Ajay Tripathi <[email protected]> wrote:
> Hi, > > I am trying to interpret the text for this project. However, I am having > troubles trying to match requirements and solutions. > Hence, I need some clarification/confirmation of my understanding. > > Firstly, my meta understanding of the project is that we want to deliver > ready made openwisp images to users and nginx, postgreSQL, postfix > containers are just the "batteries-included" for easy installation with > configurability. > Yes, but we also want to allow to scale horizontally more easily, so the traffic can be dispatched to more instances of the same containers if needed (imagine a kubernetes cluster spread on multiple nodes). > However, I am not able to understand the reason for having a dedicated > container for OpenWISP Admin interface(password reset, email confirmation), > The Admin interface is used ony by administrators, not very often, so we likley won't need more instances of the same containers to scale. The load on the other services increases with the size of the network (number of devices or also number of users in the case of the radius module), so we will need to scale up with those. > OpenWISP Controller (connections), OpenWISP Network Topology, OpenWISP > Radius, Django-freeradius. Does this mean adding images with these tools > over the docker based openwisp installation image or these tools > independently and isolatedly running in a container? > each module has its own URLs and APIs that are not admin related which are used to provide configurations, update the network topology, communicate with freeradius and so on, each one of these group of features should run in isolation. > If it's the latter, can you please provide some context to understand so > that I can put them in the picture correctly; > example: can a user need just OpenWISP Admin interface(password reset, > email confirmation) isolated or we are going to use it in future for > development/testing purposes! > A more realistic scenario is a user who wants to use only admin + radius module, or admin + controller module. But we should not add restrictions on which containers the users want to use because we should consider this to be a base on which users and developers can build a solution tailored to their needs with custom modules. > "Create one or more set of images based on Alpine Linux and python 3.7 > which have all the python packages needed for the different services." > > Does that multiple set of images mean each set with different commonly > used configurations of openwisp for "plug-and-play" for a lot of basic uses? > **Where each set includes an openwisp instance image and all the other > approriate dedicated containers with configurations. > Images usually do not have configurations, only pre-installed system packages and the python packages needed to run the OpenWISP module of that container. We may also decide to have one image that is good for all the official modules, we have to do some research and analyze pros and cons. > > > "Provide the websocket server of OpenWISP in a dedicated container" > > To the best of my understanding, websockets is managed by django-channels, > so I am unable to understand the contents of this container! What is the > expected duty that this container is to perform? (Please let me know If my > approah here is incorrect and I need to research something. > django-channels is the framework with which you build the websocket server, but the actual logic that allows you to do anything with the websocket is in OpenWISP. At the moment only OpenWISP Controller has some websocket logic (inherited from django-loci) but in the future we will have more. The duty of this container is to serve the websocket server and process data coming from websocket clients. Immagine the same installation we have today, but instead of having it on a single VM, we have it spread on different containers, each container dedicated to a single service: the containers which receive more traffic can be scaled up, either vertically with more resources (RAM, CPU) or horizontally with more containers if possible (if a load balancer in front of the containers is available to distribute traffic, we can do this with nginx for all the containers which serve HTTP or WebSocket requests, with the celery containers we don't need a load balancer because they read from the broker service which in our case is redis by default). I hope is clearer now! Fed -- 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.
