-
Notifications
You must be signed in to change notification settings - Fork 0
Design
The smallest piece of work considered. It is chronix’s “atomic” piece of work. An activity is associated with the parameter definitions needed to launch a job (see below).
An activity belongs to an application.
On a technical level, an Activity target can be:
- a process executable (mandatory (mag: why)
- a service call (type of service to be defined)
- an, RDBMS stored procedure call
- etc.
(the technical part should be handled by plugins, an activity being associated to one plugin. We could have a ShellActivityPlugin (default), ServiceActivityPlugin, OracleActivityPlugin, etc;)
A succession of activities with defined conditions. A chain belongs to an application.
(mag: see discussion about “with defined conditions” in “tasks” . We may want conditioning in the activity, not the chain)
An activity can be used in more than one chain
bq. (TBC (sre))
bq. (I agree, but with potentially different parameters (mag))
They condition the launch of an activity.
A condition is evaluated through a rule.
There are different kinds of conditions:
- time conditions: start time, end time, time slice (to be defined (mag))
- flow conditions: the start or the end a previous activity
- exclusion conditions: to prevent concurent execution of some activities..
A condition should, by design, be created and extended with a plugin architecture.
All conditions should have a consistent interface with a minimal common set of method. In particular a condition object should be able to be evaluated in a boolean context and return True or False according to its status and respect all boolean operator method : and, or, xor
A task represents the scheduling of a chain. A chain may have more than one task. A chain without a task is not scheduled but can be launched by a specific event (see below).
A task can define the chain profile. Chain can have multiple profiles that can change their behaviour.
I don’t know about this. We are actually talking of different sets of (parameter values, conditions) for a given activity. These should be defined more at the chain level than the task level, since a chain is often defined only for a given conditions/parameters combinaison. Ideally, we would have a three layered parameter system :
* Activity: parameter definition (no values)
* Parameters set: used in chains. A set (param values, conditions). May be used in multiple chains.
* Task: may overload the set (or, most often, just some values of the set) used by the chain (or define the values left void in the chain)
Note that the set
An event can be emitted by:
- a task when starting or ending
- a call to the event CLI
- a call to the event API
- a call to the event web service
An event is always received by a job scheduler (see below “Main parts”).
An event can be used to fire up a task.
When an activity scheduled by a task is elected for actual execution, it become a Job. Typical status of a Job are : waitingForExecution, Running, Supended, Aborting, Finish
Links must be done between status and return code of the underlying process.
Chronix is splitted in three main parts:
- the repository: it is in charge of all the configuration. It is mainly used during design/conception steps and for change management operation (workplan update). It is not intended to be mandatory for runtime.
- the job scheduler: central part of Chronix, the job scheduler compute the workplan, listen to event from other shedulers, send events to other scheduler and execute jobs.
- the admin console: the console is a central point to gather all runtime information and be able to control job execution (suspend, stop, restart, force start..)
Each part is discussed below.
- Production analysts
- They develop and maintain the plan
- Production pilots ?
- Read only, for reference?
- Functional leaders
- They specify the plan, giving functional constraints and desires (does not concern the repository in the first phase of the project)
- The whole plan for a subset of the IS (typically: the plan of an application)
- Version data
- input: manual — develompents
- input: manual — specifications
- output: asynchronous or manual — to nodes — subset of the whole configuration concerning a given node. (pull or push ?)
Interfaces:
- GUI
- CLI
Both interfaces should offer full functionality. Priority is given to the GUI over CLI for the dev.
- save
- Low availability required.
- Data is critical.
- Administrators
- Push (or pull?) the plan from the repository to the node.
- Configures the node (TCP ports, name, Unix users…)
- Scripts
- Triggers executions, change logical ressources allocations, …
- Other nodes
- Send events to a set of known nodes.
- Console
- Check batch logs & events.
- save
- purge (events, logs, …)
- monitor
- a subset of the configuration repository
- batch logs
- execution logs (stadard output logs)
- Conf
- Repo → Node
- mode to be defined
- events
- Node <→ Node
- synchronous
- Logs
- Exploitation console <- Node
- Asynchronous, batch or triggered by user.
- Log details (standard output file)
- User-triggered
- Console <- Node
Interfaces:
- CLI for scripting.
- WS for everything else.
- High availability.
- Configuration data is not critical.
- Logs, events, ????
Main functionalities:
Data stock:
Chronix core is not a visible application.
Chronix core is basically a set of Django models. No view are defined. Those models are intended to be imported by other applications.
This allow each application to store in his own database Chronix core objects.
bq. I thought the views would be used as part of the interface between the repository and the rest of Chronix. (of course, nothing HTML related). Or do you mean here that core is just a set of specifications? (mag)
There are as many core db as applications that need core objects.
We should explicit our choice: one application = one production schedule = one Chronix repository.
Plugins are to inherit from those core models (ex. Condition).
Console is a web application. It uses Chronix core and has its own private data structured in rdbms.
Repository is a web application. It use Chronix core and have its own private data structured in rdbms.
Repository also have a GUI for design and developpement. This GUI is written in Python, and uses the Qt widget library, as well as the Core-underlying Django framework.
The event listener and workplan processor are Python daemons that use Chronix core and have their own private data structured in rdbms.
(this data including a subset of Core models, as well as scheduler specific data).
The job run queue is a in memory thread safe queue which can persist its data on disk. It does not rely on a rdbms application.