auto tenant db setup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

auto tenant db setup

frank
"hi all,
I wanted to investigate whether the following ‘runtime’ tenant setup approach would work and potentially code up a solution to ensure the same.

Problem:
My humble interpretation is that there seems to be a bit of work involved when setting up a new tenant and in certain models (i.e. Saas self service) this is an operational overhead that I particularly need to overcome (from talking to some of the users it seems the challenge is mutual).

Proposal:

Single DB approach:
Feedback seems to indicate most of the audience prefers separate db instances for the more comprehensive usage of ofbiz. The only real alternative appears to be a data separation of sorts which might be way too big of an undertaking?
Multi DB approach
a) The assumption is that runtime (in my world) means a self service approach (i.e. a new tenant registers then they should automatically have access to a new tenant db instance; ‘seamlessly’)
b) When a new tenant registers I intend to automatically create a new tenant entry  in the tenant  tables  (I assume this is not currently available?) ; we’ll avoid/exclude the container based jndi hot deploy functionality (this is too specific to the relevant container used)
c) The tenant registration would use an available tenant db schema (i.e. pre-configured pool of tenant db’s through a pooling job process) from a pool of tenant db schemas; this assumes that any upgrades to db’s obviously would go through a non-runtime process to upgrade any tenant db’s (i.e. datasources defined in a tenantdata .xml)
d) Some peripheral housekeeping stuff I will develop to auto create a pool of tenant db’s through a job , decommissioning of datasources based on some configurable heuristics.

Any concerns/suggestions? Is this already been done anywhere and we can use/extend the code? Do you think this is not possible at all and if so why? (I appreciate my product knowledge is still very limited so your input is appreciated)

p.s. I am happy to include/exclude this from the product repository; up to you guys to decide whether you feel this would be useful no worries?

thanks all!

Frank”
Reply | Threaded
Open this post in threaded view
|

Re: auto tenant db setup

BJ Freeman
I started a couple of threads related to setup and some of the things
you discussed. they did not get anywhere at the time.
couple of Jiras you many be interested in
https://issues.apache.org/jira/browse/OFBIZ-635
https://issues.apache.org/jira/browse/OFBIZ-3908


frank sent the following on 9/27/2010 5:38 PM:


>
> "hi all,
> I wanted to investigate whether the following ‘runtime’ tenant setup
> approach would work and potentially code up a solution to ensure the same.
>
> Problem:
> My humble interpretation is that there seems to be a bit of work involved
> when setting up a new tenant and in certain models (i.e. Saas self service)
> this is an operational overhead that I particularly need to overcome (from
> talking to some of the users it seems the challenge is mutual).
>
> Proposal:
>
> Single DB approach:
> Feedback seems to indicate most of the audience prefers separate db
> instances for the more comprehensive usage of ofbiz. The only real
> alternative appears to be a data separation of sorts which might be way too
> big of an undertaking?
> Multi DB approach
> a) The assumption is that runtime (in my world) means a self service
> approach (i.e. a new tenant registers then they should automatically have
> access to a new tenant db instance; ‘seamlessly’)
> b) When a new tenant registers I intend to automatically create a new tenant
> entry  in the tenant  tables  (I assume this is not currently available?) ;
> we’ll avoid/exclude the container based jndi hot deploy functionality (this
> is too specific to the relevant container used)
> c) The tenant registration would use an available tenant db schema (i.e.
> pre-configured pool of tenant db’s through a pooling job process) from a
> pool of tenant db schemas; this assumes that any upgrades to db’s obviously
> would go through a non-runtime process to upgrade any tenant db’s (i.e.
> datasources defined in a tenantdata .xml)
> d) Some peripheral housekeeping stuff I will develop to auto create a pool
> of tenant db’s through a job , decommissioning of datasources based on some
> configurable heuristics.
>
> Any concerns/suggestions? Is this already been done anywhere and we can
> use/extend the code? Do you think this is not possible at all and if so why?
> (I appreciate my product knowledge is still very limited so your input is
> appreciated)
>
> p.s. I am happy to include/exclude this from the product repository; up to
> you guys to decide whether you feel this would be useful no worries?
>
> thanks all!
>
> Frank”
>