Note: You are currently viewing documentation for Moodle 4.0. Up-to-date documentation for the latest stable version of Moodle may be available here: VMoodle Block.

VMoodle Block: Difference between revisions

From MoodleDocs
mNo edit summary
Line 19: Line 19:
===Prerequisites===
===Prerequisites===


The VMoodle blocks provides a complete and complex virtualisation process for Moodles and a set of network level administration capabilities. For the block running properly, some non standard features of Moodle must be obtained. These are not numerous and easy to patch within a standard 1.9 codebase.
The VMoodle blocks provides a complete and complex virtualisation process for Moodles and a set of network level administration capabilities. For the block running properly. COmpared to the original version in Moodle 1.9, Moodle 2 version of Moodle 2 will need less core changes to operate in full feature range.


* The VMoodle bloc uses extensively block bound XMLRPC calls. Standard Moodle DO NOT provide support for block level XMLRPC. [http://tracker.moodle.org/browse/MDL-23194]. This point is still under discussion for 1.9 old codebase, and being resolved in Moodle 2.0.
* block bound XMLRPC calls. => natively resolved in Moodle 2.x new service registration method.
* The block is extensible, i.e. provides some parts that admit sub-plugins (typically like the resource module, but resource handling is done by standard code). Sub-plugins are supported in modules, but not in blocks. Moodle.org WILL NOT soluce this requirement. [http://tracker.moodle.org/browse/MDL-20378]
* Block sub-plugins => Now supported in the generic "subplugins" infrastructure.
* VMoodle based networks in a virtualisation configuration are intended to build coherent distributed platforms within an institutional environement. Urbanisation of such systems will often take some benefit of using extensively XMLRPC interactions between nodes for enhancing the distributed consistance. Standard Moodle codebase ensures MNET keys are renewed when a user jumps from a node to a remote node, but key ARE NOT renewed automatically when coming to obsolescence. The effect is that after a key has gone away, all services based on XMLRPC will be broken untill key exchange has not been restored again. The VMoodle block provides an "automatic MNET key rotation" enhancement that  fixes this situation. [http://tracker.moodle.org/browse/MDL-23195]
* VMoodle based networks in a virtualisation configuration are intended to build coherent distributed platforms within an institutional environement. Urbanisation of such systems will often take some benefit of using extensively XMLRPC interactions between nodes for enhancing the distributed consistance. Standard Moodle codebase ensures MNET keys are renewed when a user jumps from a node to a remote node, but key ARE NOT renewed automatically when coming to obsolescence. The effect is that after a key has gone away, all services based on XMLRPC will be broken untill key exchange has not been restored again. The VMoodle block provides an "automatic MNET key rotation" enhancement that  fixes this situation. [http://tracker.moodle.org/browse/MDL-23195]. This point is not resolved in Moodle 2.0 architecture and still needs a patch in the MNET core library.


VMoodle distribution is provided with adequate patchs for all these requirements.
VMoodle distribution is provided with adequate patchs for all these requirements.

Revision as of 15:01, 19 September 2012

VMoodle is a non standard infrastructure embedded within a Moodle block. It provides technical toolset to deploy and manage a set of virtualized Moodles from a single codebase. All virtualized moodles will run their own instance independantely one from each other, or according themselves in building a Moodle Network cooperation strategy.

This work is the result of a couple of years of developement with the participation of Intel Corp.

One of the key effect of using VMoodling virtualisation is that maintenance of multiple Moodle running with similar equipement get much easyer and saves a lot of time.

Moodle virtualisation process is achieved using a dynamic configuration definition, stored in a Moodle moodle instance so called "master instance". Virtualising such configuration allows dynamic switching of database and moodledata context when entering a Moodle page.

As was mentioned above, all the Moodle clones are completely independant and WILL NOT share any data. Using many instances with an adequate MNET strategy allows making string and powerfull distributed Moodle configuration aiming at huge organisations.

Installation

Compatibility

VMoodle supports now MySQL databases and (less tested) PostGre.

Note that Moodle do not support PostGre schemas at install time.

Prerequisites

The VMoodle blocks provides a complete and complex virtualisation process for Moodles and a set of network level administration capabilities. For the block running properly. COmpared to the original version in Moodle 1.9, Moodle 2 version of Moodle 2 will need less core changes to operate in full feature range.

  • block bound XMLRPC calls. => natively resolved in Moodle 2.x new service registration method.
  • Block sub-plugins => Now supported in the generic "subplugins" infrastructure.
  • VMoodle based networks in a virtualisation configuration are intended to build coherent distributed platforms within an institutional environement. Urbanisation of such systems will often take some benefit of using extensively XMLRPC interactions between nodes for enhancing the distributed consistance. Standard Moodle codebase ensures MNET keys are renewed when a user jumps from a node to a remote node, but key ARE NOT renewed automatically when coming to obsolescence. The effect is that after a key has gone away, all services based on XMLRPC will be broken untill key exchange has not been restored again. The VMoodle block provides an "automatic MNET key rotation" enhancement that fixes this situation. [1]. This point is not resolved in Moodle 2.0 architecture and still needs a patch in the MNET core library.

VMoodle distribution is provided with adequate patchs for all these requirements.

IMPORTANT NOTE : On Mysql, VMoodle provides Moodle instance capturing for making deployement templates. This assumes the master Moodle controlling deployments need having a Myslq user that has DATABASE CREATE permission.

Block Installation

VMoodle block will install just as a usual Moodle block. Subplugins patch can be installed later, causing sub-plugins to be installed in a second stage :

  1. Unzip the block code in the "blocks" folder of your Moodle install.
  2. Trigger the administraton/notification menu.

VMoodle Block Features

Features Adressing the "Moodle Factory" Administration

  • Virtualisation Hook for the standard 'config.php' file
  • Deployment of new instances from within the Master instance administration
  • Moodle snapshot to create platform templates for further deployment
  • On demand Moodle deployment
  • Deployement of virtualized Moodle within a Moodle Network strategy

Features Adressing the "MNetwork Level Administration"

Multiplying instances will ever raise issues of administration because increasing the amount of information to be managed and complexity of the system. The VMoodle block provides a super-administration toolset allowing distributing administration commands across a Moodle Network so getting things faster even when the number of Moodle gets quite high. This administration layer provides a command framework for extensibility.

  • SQL orders can be distributed on all managed nodes
  • Role comparison and sync between many nodes
  • Capability resync between many nodes
  • Massive upgrade of all nodes when upgrading or installing new plugins.

Access to Mnetwork Level Administration

You may access to the MNET level administration clicking on the link "Administrate" showing in the footer of the "VMoodle" bloc instance.

Three subservices are available :

See Also

VMoodle Virtualization block Modules and Plugins database entry.