Skip to content

Writing BtrPlace extensions

Jump to bottom
Fabien Hermenier edited this page Oct 16, 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.

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

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.

The mapping process

The mapping between a user-level view and the choco-level view is done using the ChocoMapper.mapView that is accessible from any ChocoScheduler Parameters. Internally, the Reflection API is used to instante the Choco view and the mapper expects a constructor for the ChocoView that takes the user-level view as a unique parameter.

Injection workflow

The Choco CSP is generated incrementally from a core problem.

  1. A ReconfigurationProblem is created. This problem 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 can force the state-change. VMTransitions implementations create the necessary variables to control the state transition. 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 ChocoView associated to the ModelView are instantiated.
  3. The CSP code for the ChocoView is created through their inject() method so they can create variables. The injection ordering satisfies the dependencies declared in getDependencies()
  4. The CSP code for the constraints is created through their inject() method. At this moment, it is then safe to access any ChocoView variable
  5. Every view are queried a second time using their beforeSolve() method. This enables to optimise some code. Again the possible dependencies between the views are considered.
  6. The specialised problem is solved by calling ReconfigurationProblem.solve()

Inside the view, the developer must implement at minima the inject() method

TODO***

Clone this wiki locally