Le 18/07/2014 16:28, Guillem Barba Domingo a écrit :
> 2014-07-18 10:06 GMT+02:00 Cédric Krier <[email protected]
> <mailto:[email protected]>>:

> 
>     This is called provisioning: https://en.wikipedia.org/wiki/Provisioning

Got it and thought about it, and the conclusion is that database
creation is different from provisionning (in the educational context at
least).
> 
>     > Running
>     > hundreds of instances is also a waste in resources (disk and memory).
> 
>     I disagree about disk waste.
>     For memory, the gain of using one process for all DB vs one process per
>     DB doesn't seem so much I measure it of ~40Mb with the full set of
>     module when starting a DB takes ~25Mb.
>     So in some way, it will double the require memory for such case but
>     still it should fit in one common server configuration.

I agree about disk space prived all processes run the same compy of the
code.
Regarding memory, big or small depend on sizing indeed. A typical school
is sized at 500 databases max at SISalp (200 average). Today I can run
200 virtual servers on one physical server, which will result as 100 000
trtond processes max, 40 000 average (instead of 1800 processes today, 9
per school)



> 
> 
> I think this part of discussion is out of thread topic.

I agree

> It has been discussed in this thread [1] where you can find the
> arguments for the change to a single-database per instance.

Thank you for this pointer, I was not aware of it. Thie feature is not
only a dev discussion as we see here.

> As I commented in that thread, I think that with Circus [2] will be
> posible (Out of the box or developing some plugin) to serve multiple
> instances/databases selected by subdomain (all of theme using the same
> external port).

You can choose the tool you want.  Multiple instances is not a complex
task. I'm just sharing a real experience with big numbers.


> With this and a flask application (for example) for the
> Instance/Database reated functions (create, drop, restore...) we can
> have a better provisioning system.

Flask is an option, not a requirement, but I agree on the idea, I do
provide a web page for teachers who do these actions (create, drop,
restore...) daily, but the idea to use "provisionning" process to create
temporary databases is more complex than it appears.

> 
> I understand that now, the Education use case is supported easyly, but a
> very good solution will be posible

I agree, and if there is no other way, I'll adapt my tools.
Nevertheless, I don't (and won't) host 100% of educational servers, and
if Tryton is not choosen by teachers (who will not use provisionning
tools), there won't be a market potential here anymore. End of the story.

> and, as you can find here [1], there
> are good reasons for the change.

I disagree. There are good reasons not to use multiple databases on a
production server, but this is not new. But multi-databases on
non-production servers is a proven advantage. I won't comment on
technical aspects since I'm not able to.
Nevertheless, I can understand education is not the first target of an
ERP. I discovered only recently that it was a key advantage which
partially explains the move from long used single-database proprietary
solutions (Cegid, Sage, SAP and PeopleSoft). It provides more
flexibility in classrooms.


> If you want, we can create a blueprint in the Tryton's wiki for this
> provisioning system and try to design it and develop with the
> collaboration of community.

I don't plan to change the current solution I use, in respect to the
stability of the installed base I have to run daily and the number of
users I would have to migrate. Nevertheless a Circus configuration to
manage separate multiple Tryton instances will probably interest several.

> 
> [1] https://groups.google.com/d/msg/tryton-dev/jrLyPxHMzeA/7TeqMzoo6sQJ
> [2] http://circus.readthedocs.org/en
> 
> -- 
> Guillem Barba
> http://www.guillem.alcarrer.net

-- 
Dominique Chabord - SISalp

Reply via email to