Some thoughts about modularization

    The main problem with the current version is that all objects (domain, dns, mail) are considered as an unique entity. We shouldn't redo the same error here. So, when a domain is added, if setup of one object (DNS, mail...) that compose the entity fail, the recovery process should only take care of what that was failed... For that we will have to provide a error management per object (Mail, DNS ...) status. Since the data in GUI are normalized, that will change nothing the main database. Only error notification will be sent to the administrator/reseller. And then, the administrator have to take care only about errors per object and not to regenerate all the configuration.... Sure, an specific per object debug interface should be provided too.


    Note: Sorry for my poor english here, Hard for me to explain who I see the concept.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    ok, I try to repeat...
    domain creation -> gui puts data for dns, web and the default mail adresses into the db -> the daemons on the respective servers are trying to setup the respective services (dns, web, mail) - if one fails (eg. web) then the daemon on the webserver needs to tell this to the central/control server (put in the db) and the other daemons need to roll back.
    So... how do the other daemons know what was the configuration was before the creation (ok, that's easy - but on a change, then the satus before is relevant) - maybe it's an option if there's a sort of daemon on the central/control server which "knows" the status of "before" and can through another setup/clean/etc command to the daemons which need to rollback... so the main "intelligence" is centralized....
    If all three servers (in this example) are giving the feedback "ok/successfully done" then the central daemon can recycle the rollback infos...


    Now, maybe the central database may also have two sides: one of the actual state of the whole system (a dns table, a mail table etc) and one (maybe only one table) with all the todos/jobs, in a queue or so... - if a job has been finished the central daemon puts the info in the correct tables so the gui also "knows" about the changes (so: the gui does not see a domain until it's really created - but it should show the state that the creation is in progress..)...
    There are pros and cons about a job-queue...
    pro: the daemon does not need to check several tables, maybe easier to rollback
    con: the gui need to add the info of e.g. "domain creation in progress" from this separate table...
    hm...


    The todo/job queue table needs to be very flexible (eg. a big text field with XML infos) because we do not know what sort of commands may come (with external modules)...


    just some thoughts....
    Joxi

    Edited once, last by joximu ().

    Hi guys,


    I couldn't find any more informations about introducing *MS* in i-MSCP.. Did you make any progress with this discussion since end of 2010? ;)

    Edited once, last by maur ().