Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Multi Tenant Self Hosted Enviroments
by
cgucker
Let me respond inline. On Sun, May 21, 2023 at 12:22 PM Xavier Brochard <notifications@odoo-community.org> wrote: > > In case Cloudpepper is not what you want, Ivan Yelizariev has made a > package to help multi tenant Odoo hosting (see its modules on > apps.odoo.com). There is also some bash scripts from the french provider > Sisalp that you can download from http://download.sisalp.net/scripts/. > You might also use the Yunohost solution, there is a good Odoo package > (any version). Thank you, I'm going to dig into the scripts. I also took a look at Yunohost and it seems a little basic based on my background and experiences. I'm not adverse to getting my hands a little dirty, I just didn't want to recreate the wheel with my own efforts. I've been giving my original question some additional thought. I'm trying to understand how Odoo got to the point of multi-domain (being able to add multiple websites) in the data plane, but not breaking away the control plane (configuration functions) from the remaining data plane functions. That is, dbfilter is intended to assign a specific host or FQDN to facilitate the control plane functions, but there isn't a function to administrate the relationships with the data plane. In other words, within Odoo, there is no way to dynamically maintain a list of vhost domains and associate them with their respective databases and actually see the state of each vhost as they relate to their database and mark them as active or inactive, which would allow for the duplications or migrations from one database to another without collisions. I am aware that I am drifting into the core components of Odoo, but if there was a way to assign a specific "control plane domain", the dbfilter could be used just on that domain to facilitate control plane functionality, while all of the data plane functionality would be presented within the GUI and dynamically serve the active domains without having to be handled by the dbfilter. This would allow central administration via the tenant_name.mycontrolplane.com, while allowing all of their configured domains, provided there are no conflicts with other tenants would not be subject to the dbfilter. It would make the reverse proxy configuration a lot easier as well, as all queries would just be forwarded and no domain specific configurations would be required. Is this line of thinking correct, or am I missing something? Also, if this functionality existed, a multi-tenant setup would be able to be accomplished without the need to do any external tinkering from Odoo, except for the TLS certificates, but there's a module for that. > But beware, self-hosting require work. While it's easy for personal > projects, it require a lot of time when it comes professional. I ran a > hosting company in the 90's, I know what I am talking about. I didn't > knew about Cloudpepper, but it looks very good. I am very well aware of the work required to perform self-hosting functions. I too ran a service provider in the early 90s and evolved to run the platform engineering team for a large scale digital advertising provider. I'm not afraid of automation or orachistration, but only when absolutely needed. If we can fix my concerns within the application, it would require a lot less of an effort to administrate. Personally, if things went this well, I'd rather put my time and effort into scaling with a CDN provider than continue to tinker with Odoo's current lack of control plane scalability. For the time being, I'm going down the path of a single tenant per instance, but once I get this not for profit setup, I'll return into figuring out what is required to resolve what I see as a control plane issue without removing existing functionality. Thank you again for your recommendations, it's much appreciated. Charles
