Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: Multi Tenant Self Hosted Enviroments

by
cgucker
- 21/05/2023 23:30:33
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

Reference