Skip to content

Writing BtrPlace extensions

Jump to bottom
Fabien Hermenier edited this page Oct 18, 2019 · 9 revisions

BtrPlace is already bundled with several Views and constraints to accomodate with common concerns. In some circumstances, the library may however lack of solutions. We discuss here how to create extensions.

Generalities

BtrPlace is designed around the bridge pattern to dissociate the user API which expresses a constraint or a view and the solver API which expresses the enforcement algorithm using the choco API. Furthermore, it is pretty sweet to be able to serialise an instance into JSON to be able to replay it for debugging purpose.

Architecture

As a result, when you develop a view or a constraint, you will have to develop 3 components:

  1. the user-side code. For a view, this exhibits a part of a cluster state. For a constraint, this will exhibit the desired state.
  2. The serialisation code to produce a JSON version of your component.
  3. the solver-side code. This consists in customizing the default Choco CSP to express your requirements

The user-side API to solve-side API mapping process

The mapping between a user-level constraint or view and the choco-level equivalent is done using the ChocoMapper that is accessible from any ChocoScheduler Parameters. Internally, the Reflection API is used to instantiate the Choco object.

The choco CSP generation process

The Choco CSP is generated incrementally from a core problem called the ReconfigurationProblem

  1. The ReconfigurationProblem is created. It models that the nodes are free to change their state using NodeTransitions. The next state for every VM is however forced. By default, their state is unchanged but constraints derived from VMTransitions can force the state-change. The basic model is in charge of accounting the number of VMs per node and scheduling the actions so that they succeed according to the element states.
  2. The ChocoViews associated to the ModelView are instantiated.
  3. The CSP code for the ChocoView is created through their inject() method. Usually the views create variables and some relations between them. The injection ordering satisfies the declared dependencies.
  4. The CSP code for the constraints is injected through their inject() method. At this moment, it is then safe to access any ChocoView variable.
  5. The Choco views are queried a second time using their beforeSolve() method. This enables to some code optimisation. Again the dependencies between the views are considered.

Writing a View

User-level API

Every view derives from ModelView.

  • It must provide an identifier
  • It must be Copyable
  • It must implements equals() and hashcode()

It is also convenient to implement a static get() method to access the view inside a model once attached (example)

Remember that a view reports the initial cluster state. Accordingly, there is no notion of interpretation about the current situation.

Choco-level API

The Choco version of a constraint implements ChocoView. It expects the user-side view as a unique constructor parameter.

  • Implement the inject() view to provide here the view specific variables and basic relations between them.
  • If the view requires variables from another view, declare the dependencies in getDependencies()
  • If some late optimisation is possible, implement beforeSolve()
  • If the view can perform some problem simplification in the repair mode, it must implements getMisplaced() to state the supposed mis-placed VMs. Be careful, if this method returns all the VMs in the problem, then the repair mode will be counter-effective as it will prevent any optimisation.
  • insertAction() may be implemented if, once a solution computed, this view may modify the reconfiguration plan with view specific events.

Clone this wiki locally