Vous avez reçu un message "Your GitLab account has been locked ..." ? Pas d'inquiétude : lisez cet article https://docs.gricad-pages.univ-grenoble-alpes.fr/help/unlock/

Commit 63af8181 authored by Millian Poquet's avatar Millian Poquet
Browse files

Merge branch 'road-to-3.0'

parents c5d6bb69 da50f010
Pipeline #15283 passed with stages
in 14 minutes and 51 seconds
......@@ -10,6 +10,34 @@ Batsim's public API includes:
[//]: ==========================================================================
## [Unreleased]
### Changed (**breaks protocol**)
- ``SUBMIT_PROFILE`` has been renamed ``REGISTER_PROFILE``.
Trying to register an already existing profile will now fail.
- ``SUBMIT_JOB`` has been renamed ``REGISTER_JOB``.
Trying to register an already existing job will now fail.
The possibility to register profiles from within a ``REGISTER_JOB`` event has
been discarded: Now use ``REGISTER_PROFILE`` then ``REGISTER_JOB``.
- The content of the ``config`` object of the ``SIMULATION_BEGINS`` event has
been changed. It is now flattened and contains the following keys:
``redis-enabled``, ``redis-hostname``, ``redis-port``, ``redis-prefix``,
``profiles-forwarded-on-submission``, ``dynamic-jobs-enabled`` and
``dynamic-jobs-acknowledged``.
### Changed (**breaks command-line interface**)
- Removal of the ``--config-file`` option.
Now specify your desired features by the Batsim CLI options.
- Removal of the ``--enable-sg-process-tracing`` option.
You can now use ``--sg-cfg`` to do the same.
- ``--batexec`` has been renamed ``--no-sched``.
- ``--allow-time-sharing`` has been split into two options
``--enable-time-sharing-on-compute`` and
``--disable-time-sharing-on-storage``, as resource roles have been introduced.
### Added (new command-line options)
- New ``--sg-cfg`` option, that allows to set SimGrid configuration options.
- New ``--dump-execution-context`` option, that dumps the command execution
context on the standard output. This allows external tools to understand
the execution context of a batsim command without actually parsing it.
[//]: ==========================================================================
## [2.0.0] - 2018-02-20
......
# Configuration
The configuration is a JSON file with a dictionnary of value. Here is the
default configuration:
```json
{
"redis": {
"enabled": false,
"hostname": "127.0.0.1",
"port": 6379,
"prefix": "default"
},
"job_submission": {
"forward_profiles": false,
"from_scheduler": {
"enabled": false,
"acknowledge": true
}
},
"job_kill": {
"forward_profiles": false
}
}
```
This configuration can be override using the ``--config-file`` option. Each
field present in the file will be used and the fields that are not provided
keeps the default value.
......@@ -21,17 +21,16 @@ occurs in Batsim in the simulation, the following steps occur:
ZeroMQ is used in both processes (Batsim uses a ZMQ REQ socket, the
scheduler a ZMQ REP one).
The behavior of this protocol depends on the
[configuration](./configuration.md):
The behavior of this protocol depends on the command line options:
- If Redis is enabled, job metadata is stored into a Redis server and not sent
through the protocol. In this case, the protocol is only used for
synchronization purposes. More information about Redis conventions are
described [there](data_storage_description.md).
- Batsim may or may not forward job profile information to the scheduler when
jobs are submitted (see [JOB_SUBMITTED](#job_submitted) documentation)
- Dynamic jobs submissions can be enabled or disabled.
Many parameters of job submissions can be adjusted, please refer to the
[Dynamic submission of jobs](#dynamic-submission-of-jobs) documentation for
- Dynamic jobs (and profiles) registration can be enabled or disabled.
Many parameters of job registration can be adjusted, please refer to the
[Dynamic registration of jobs](#dynamic-registration-of-jobs) documentation for
more details.
# Message Composition
......@@ -109,8 +108,8 @@ Constraints on the message format are defined here:
- [EXECUTE_JOB](#execute_job)
- [CALL_ME_LATER](#call_me_later)
- [KILL_JOB](#kill_job)
- [SUBMIT_JOB](#submit_job)
- [SUBMIT_PROFILE](#submit_profile)
- [REGISTER_JOB](#register_job)
- [REGISTER_PROFILE](#register_profile)
- [SET_RESOURCE_STATE](#set_resource_state)
- [SET_JOB_METADATA](#set_job_metadata)
- [CHANGE_JOB_STATE](#change_job_state)
......@@ -230,11 +229,11 @@ This message allows a peer to notify something to its counterpart.
There is no expected acknowledgement when sending such message.
For now, Batsim can **notify** the scheduler of the following:
- **no_more_static_job_to_submit**: Batsim tells the scheduler that it has no more jobs to submit from the static submitters. This means that all jobs in the workloads have already been submitted to the scheduler and the scheduler cannot expect more jobs to arrive (except the potential ones through dynamic submission).
- **no_more_static_job_to_submit**: Batsim tells the scheduler that it has no more jobs to submit from the static submitters. This means that all jobs in the workloads have already been submitted to the scheduler and the scheduler cannot expect more jobs to arrive (except the potential ones through dynamic registration).
For now, the scheduler can **notify** Batsim of the following:
- **submission_finished**: The scheduler tells Batsim that dynamic job submissions are over, which allows Batsim to stop the simulation. This message **MUST** be sent if ``"scheduler_submission": {"enabled": true}`` is configures, in order to finish the simulation. See [Configuration documentation](./configuration.md) for more details.
- **continue_submission**: The scheduler tells Batsim that it have sent a ``submission_finished`` NOTIFY prematurely and that Batsim should re-enable dynamic submissions of jobs.
- **registration_finished**: The scheduler tells Batsim that dynamic job and profile registration are over, which allows Batsim to eventually stop the simulation. This message **MUST** be sent if the ``--enable-dynamic-jobs`` command line option is set.
- **continue_registration**: The scheduler tells Batsim that it have sent a ``registration_finished`` NOTIFY prematurely and that Batsim should re-enable dynamic registration of jobs and profiles.
- **data**: the type of notification
......@@ -251,7 +250,15 @@ or
{
"timestamp": 42.0,
"type": "NOTIFY",
"data": { "type": "submission_finished" }
"data": { "type": "registration_finished" }
}
```
or
```json
{
"timestamp": 42.0,
"type": "NOTIFY",
"data": { "type": "continue_registration" }
}
```
......@@ -270,16 +277,15 @@ BATSIM ---> SCHEDULER
Sent at the beginning of the simulation. Once it has been sent,
and if redis is enabled, meta-information can be read from Redis.
Batsim configuration is sent through the ``config`` object (in ``data``).
Any custom information can be added into the
[Batsim configuration](./configuration.md), which gives a generic way to give
metainformation from Batsim to any scheduler at runtime.
Batsim configuration is sent through the ``config`` object (in ``data``) and forwards multiple command line
options to the scheduler.
- **data**:
- **nb_resources**: the number of resources
- **nb_compute_resources**: the number of compute resources
- **nb_storage_resources**: the number of storage resources
- **allow_time_sharing**: whether time sharing is enabled or not
- **allow_time_sharing_on_compute**: whether time sharing on compute machines is enabled or not
- **allow_time_sharing_on_storage**: whether time sharing on storage machines is enabled or not
- **config**: the Batsim configuration
- **compute_resources**: information about the compute resources
- **id**: unique resource number
......@@ -304,7 +310,8 @@ metainformation from Batsim to any scheduler at runtime.
"nb_resources": 4,
"nb_compute_resources": 4,
"nb_storage_resources": 0,
"allow_time_sharng": false,
"allow_time_sharing_on_compute": false,
"allow_time_sharing_on_storage": true,
"config": {
"redis": {
"enabled": false,
......@@ -415,17 +422,14 @@ have been submitted and executed (or rejected). When receiving this message, the
### JOB_SUBMITTED
The content of this message depends on the
[Batsim configuration](./configuration.md).
The content of this message depends whether Redis is enabled or not.
This event means that one job has been submitted within Batsim.
It is sent whenever a job coming from Batsim inputs (workloads and workflows)
has been submitted.
If dynamic job submissions are enabled (the configuration contains
``{"job_submission": { "from_scheduler": {"enabled": true}}}``), this message
is sent as a reply to a [SUBMIT_JOB](#submit_job) message if and only if
dynamic job submissions acknowledgements are enabled
(``{"job_submission": {"from_scheduler": {"acknowledge": true}}}``).
If dynamic job registrations are enabled, this message
is sent as a reply to a [REGISTER_JOB](#register_job) message if and only if
dynamic job registration acknowledgements are enabled.
The ``job_id`` field is always sent and contains a unique job identifier.
If redis is enabled (``{"redis": {"enabled": true}}``),
......@@ -434,8 +438,7 @@ Otherwise (if redis is disabled), a JSON description of the job is forwarded
in the ``job`` field.
A JSON description of the job profile is sent if and only if
profiles forwarding is enabled
(``{"job_submission": {"forward_profiles": true}}``).
profiles forwarding is enabled.
- **data**: a job id and optional information depending on the configuration
- **example without redis and without forwarded profiles**:
......@@ -739,15 +742,14 @@ Batsim acknowledges it with one [JOB_KILLED](#job_killed) event.
}
```
### SUBMIT_JOB
### REGISTER_JOB
Submits a job (from the scheduler) at the current simulation time.
Job submissions from the scheduler must
be enabled in the [configuration](./configuration.md)
(``{"job_submission": {"from_scheduler": {"enabled": true}}``).
The submission is acknowledged by default, but acknowledgments can be disabled
in the configuration
(``{"job_submission": {"from_scheduler": {"acknowledge": false}}}``).
Registers a job (from the scheduler) at the current simulation time.
Jobs registration from the scheduler must
be enabled with a command line option (`--enable-dynamic-jobs`).
Acknowledgment of job registrations can be enabled by the `acknowledge-dynamic-jobs` command
line option, which makes Batsim send a [JOB_SUBMITTED](#job_submitted) event
back to the scheduler.
**Note:** The workload name SHOULD be present in the job description id field
with the notation ``WORKLOAD!JOB_NAME``. If it is not present it will be added
......@@ -763,7 +765,7 @@ to the job description provided in the acknowledgment message
```json
{
"timestamp": 10.0,
"type": "SUBMIT_JOB",
"type": "REGISTER_JOB",
"data": {
"job_id": "w12!45",
}
......@@ -773,7 +775,7 @@ to the job description provided in the acknowledgment message
```json
{
"timestamp": 10.0,
"type": "SUBMIT_JOB",
"type": "REGISTER_JOB",
"data": {
"job_id": "dyn!my_new_job",
"job":{
......@@ -781,20 +783,15 @@ to the job description provided in the acknowledgment message
"res": 1,
"id": "dyn!my_new_job",
"walltime": 12.0
},
"profile":{
"type": "delay",
"delay": 10
}
}
}
```
### SUBMIT_PROFILE
### REGISTER_PROFILE
Submits a profile (from the scheduler). Job submissions from the scheduler must
be enabled in the [configuration](./configuration.md)
(``{"job_submission": {"from_scheduler": {"enabled": true}}``).
Registers a profile (from the scheduler). Jobs registration from the scheduler must
be enabled with a command line option (`--enable-dynamic-jobs`).
- **data**: A workload name, profile name, and the data of the profile.
......@@ -805,7 +802,7 @@ be enabled in the [configuration](./configuration.md)
```json
{
"timestamp": 10.0,
"type": "SUBMIT_PROFILE",
"type": "REGISTER_PROFILE",
"data": {
"workload_name": "dyn_wl1",
"profile_name": "delay_10s",
......@@ -884,19 +881,18 @@ complex dynamic jobs.
The way to do some operations with the protocol is shown in this section.
## Executing jobs
Depending on the [configuration](./configuration.md), jobs information might
Depending on the command line options, jobs information might
either be transmitted through the protocol or Redis.
![executing_jobs_figure](protocol_img/job_submission_and_execution.png)
## Dynamic submission of jobs
## Dynamic registration of jobs
Jobs are in most cases given as Batsim inputs, which are submitted within
Batsim (the scheduler knows about them via [JOB_SUBMITTED](#job_submitted) events).
However, jobs can also be submitted from the scheduler throughout the
However, jobs can also be submitted from the scheduler (via registration events) throughout the
simulation. For this purpose:
- dynamic job submissions **must** be enabled in the
[Batsim configuration](./configuration.md)
- the scheduler **must** tell Batsim when it has finished submitting dynamic
- dynamic jobs registration **must** be enabled via the `--enable-dynamic-jobs` command line option.
- the scheduler **must** tell Batsim when it has finished registering dynamic
jobs (via a [NOTIFY](#notify) event).
Otherwise, Batsim will wait for new simulation events forever,
causing either a SimGrid deadlock or an infinite loop at the end of the
......@@ -905,21 +901,20 @@ simulation. For this purpose:
SimGrid deadlocks during the simulation. If at some simulation time all
Batsim workloads/workflows inputs have been executed and nothing is happening
on the platform, this might lead to a SimGrid deadlock. If the scheduler
knows that it will submit a dynamic job in the future, it should ask Batsim
knows that it will register a dynamic job in the future, it should ask Batsim
to call it at this timestamp via a [CALL_ME_LATER](#call_me_later) event.
The protocol behavior of dynamic submissions is customizable in the
[Batsim configuration](./configuration.md):
- Batsim might or might not send acknowledgements when jobs have been submitted.
The protocol behavior of dynamic registrations is customizable via the command line options.
- Batsim might or might not send acknowledgements when jobs have been registered.
- Metainformation are sent via Redis if Redis is enabled, or directly via the
protocol otherwise.
A simple scheduling algorithm using dynamic job submissions can be found in
A simple scheduling algorithm using dynamic jobs registration can be found in
[Batsched](https://gitlab.inria.fr/batsim/batsched/blob/master/src/algo/submitter.cpp).
This implementation should work whether Redis is enabled and whether dynamic
job submissions are acknowledged.
jobs registration are acknowledged.
The following two figures outline how submissions should be done
The following two figures outline how registrations should be done
(depending whether Redis is enabled or not).
### Without Redis
......
......@@ -32,9 +32,9 @@ The behavior of this protocol depends on Batsim :ref:`cli`.
In this case, the protocol is only used for synchronization purposes.
More information about Redis conventions are described in :ref:`redis`.
- Batsim may or may not forward job profile information to the scheduler when jobs are submitted (see JOB_SUBMITTED_ documentation).
- Dynamic jobs submissions can be enabled or disabled.
Many parameters of job submissions can be adjusted.
Please refer to `Dynamic submission of jobs`_ for more details.
- Dynamic jobs (and profile) registration can be enabled or disabled.
Many parameters of jobs registration can be adjusted.
Please refer to `Dynamic registration of jobs`_ for more details.
Message Composition
-------------------
......@@ -117,8 +117,8 @@ Table of Events
- EXECUTE_JOB_
- CALL_ME_LATER_
- KILL_JOB_
- SUBMIT_JOB_
- SUBMIT_PROFILE_
- REGISTER_JOB_
- REGISTER_PROFILE_
- SET_RESOURCE_STATE_
- SET_JOB_METADATA_
- CHANGE_JOB_STATE_
......@@ -237,8 +237,8 @@ For now, Batsim can **notify** the scheduler of the following.
For now, the scheduler can **notify** Batsim of the following.
- ``submission_finished``: The scheduler tells Batsim that dynamic job submissions are over, therefore allowing Batsim to stop the simulation. This event **MUST** be sent if scheduler submission is enabled (see :ref:`cli`).
- ``continue_submission``: The scheduler tells Batsim that it has sent a ``submission_finished`` NOTIFY_ prematurely and that Batsim should re-enable dynamic submissions of jobs...
- ``registration_finished``: The scheduler tells Batsim that dynamic job registrations are over, therefore allowing Batsim to stop the simulation eventually. This event **MUST** be sent if dynamic jobs registration is enabled (see :ref:`cli`).
- ``continue_registration``: The scheduler tells Batsim that it has sent a ``registration_finished`` NOTIFY_ prematurely and that Batsim should re-enable dynamic registration of jobs...
**data**: The type of notification, as a string.
......@@ -255,7 +255,15 @@ For now, the scheduler can **notify** Batsim of the following.
{
"timestamp": 42.0,
"type": "NOTIFY",
"data": { "type": "submission_finished" }
"data": { "type": "registration_finished" }
}
.. code:: json
{
"timestamp": 42.0,
"type": "NOTIFY",
"data": { "type": "continue_registration" }
}
--------------
......@@ -278,7 +286,8 @@ Batsim configuration is sent through the ``config`` object (in ``data``). Custom
- ``nb_resources``: The number of resources in the simulated platform.
- ``nb_compute_resources``: The number of compute resources in the simulated platform.
- ``nb_storage_resources``: The number of storage resources in the simulated platform.
- ``allow_time_sharing``: Whether time sharing is enabled or not (see :ref:`cli`).
- ``allow_time_sharing_on_compute``: Whether time sharing is enabled on compute machines or not (see :ref:`cli`).
- ``allow_time_sharing_on_storage``: Whether time sharing is enabled on storage machines or not (see :ref:`cli`).
- ``config``: The Batsim configuration.
- ``compute_resources``: Information about the compute resources.
......@@ -423,17 +432,16 @@ The content of this event depends on how Batsim has been called (see :ref:`cli`)
This event means that one job has been submitted within Batsim. It is
sent whenever a job coming from Batsim inputs (workloads and workflows)
has been submitted. If dynamic job submissions are enabled, this
has been submitted. If dynamic jobs registration is enabled, this
event is sent as a reply to a SUBMIT_JOB_ event if
and only if dynamic job submissions acknowledgements are also enabled.
More information can be found in `Dynamic submission of jobs`_.
and only if dynamic jobs registration acknowledgements are also enabled.
More information can be found in `Dynamic registration of jobs`_.
The ``job_id`` field is always sent and contains a unique job
identifier. If redis is enabled, ``job_id`` is the only forwarded field. Otherwise (i.e., if redis is disabled), a JSON description of the job is forwarded in the ``job``
field.
A JSON description of the job profile is sent if and only if profiles
forwarding is enabled.
A JSON description of the job profile is sent if and only if profiles forwarding is enabled (see :ref:`cli`).
**data**: a job id and optional information depending on how Batsim has been called (see :ref:`cli`).
......@@ -749,14 +757,14 @@ before the kill), Batsim acknowledges it with one JOB_KILLED_ event.
"data": {"job_ids": ["w0!1", "w0!2"]}
}
SUBMIT_JOB
REGISTER_JOB
~~~~~~~~~~
Submit a job (from the scheduler) at the current simulation time.
REgisters a job (from the scheduler) at the current simulation time.
Job submissions from the scheduler must be enabled (see :ref:`cli`).
The submission is acknowledged by default, but acknowledgments can be disabled (see :ref:`cli`).
More information can be found in `Dynamic submission of jobs`_.
Jobs registration from the scheduler must be enabled (see :ref:`cli`).
Acknowledgment of registrations can be enabled (see :ref:`cli`).
More information can be found in `Dynamic registration of jobs`_.
**Important note:** The workload name SHOULD be present in the job description id
field with the notation ``WORKLOAD!JOB_NAME``. If it is not present it
......@@ -771,7 +779,7 @@ Example **without redis** : The whole job description goes through the protocol.
{
"timestamp": 10.0,
"type": "SUBMIT_JOB",
"type": "REGISTER_JOB",
"data": {
"job_id": "dyn!my_new_job",
"job":{
......@@ -779,10 +787,6 @@ Example **without redis** : The whole job description goes through the protocol.
"res": 1,
"id": "dyn!my_new_job",
"walltime": 12.0
},
"profile":{
"type": "delay",
"delay": 10
}
}
}
......@@ -793,20 +797,20 @@ Example **with redis** : The job and profile description, if unknown to Batsim y
{
"timestamp": 10.0,
"type": "SUBMIT_JOB",
"type": "REGISTER_JOB",
"data": {
"job_id": "w12!45",
}
}
SUBMIT_PROFILE
REGISTER_PROFILE
~~~~~~~~~~~~~~
Submits a profile (from the scheduler).
Registers a profile (from the scheduler).
Job submissions from the scheduler must be enabled (see :ref:`cli`).
More information can be found in `Dynamic submission of jobs`_.
Jobs registration from the scheduler must be enabled (see :ref:`cli`).
More information can be found in `Dynamic registration of jobs`_.
**data**: A workload name, profile name, and the data of the profile.
......@@ -816,7 +820,7 @@ Example **without redis** : The whole profile description goes through the proto
{
"timestamp": 10.0,
"type": "SUBMIT_PROFILE",
"type": "REGISTER_PROFILE",
"data": {
"workload_name": "dyn_wl1",
"profile_name": "delay_10s",
......@@ -910,34 +914,34 @@ jobs information might either be transmitted through the protocol or Redis.
:scale: 100 %
:alt: Executing jobs
.. _dynamic_job_submission:
.. _dynamic_job_registration:
Dynamic submission of jobs
Dynamic registration of jobs
--------------------------
Jobs are in most cases given as Batsim inputs, which are submitted
within Batsim (the scheduler knows about them via
JOB_SUBMITTED_ events).
However, jobs can also be submitted from the scheduler throughout the
However, jobs can also be submitted from the scheduler (via registration events) throughout the
simulation. For this purpose:
- Dynamic job submissions **must** be enabled (see :ref:`cli`).
- The scheduler **must** tell Batsim when it has finished submitting dynamic jobs (via a NOTIFY_ event).
- Dynamic jobs registration **must** be enabled (see :ref:`cli`).
- The scheduler **must** tell Batsim when it has finished registering dynamic jobs (via a NOTIFY_ event).
Otherwise, Batsim will wait for new simulation events forever, causing either a SimGrid deadlock or an infinite loop at the end of the simulation.
- the scheduler **must** make sure that Batsim has enough information to avoid SimGrid deadlocks during the simulation.
If at some simulation time all Batsim workloads/workflows inputs have been executed and nothing is happening on the platform, this might lead to a SimGrid deadlock.
If the scheduler knows that it will submit a dynamic job in the future, it should ask Batsim to call it at this timestamp via a CALL_ME_LATER_ event.
If the scheduler knows that it will register a dynamic job in the future, it should ask Batsim to call it at this timestamp via a CALL_ME_LATER_ event.
The protocol behavior of dynamic submissions is customizable (see :ref:`cli`).
- Batsim might or might not send acknowledgements when jobs have been submitted.
The protocol behavior of dynamic registrations is customizable (see :ref:`cli`).
- Batsim might or might not send acknowledgements when jobs have been registered.
- Metainformation are sent via Redis if Redis is enabled, or directly via the protocol otherwise.
A simple scheduling algorithm using dynamic job submissions can be found in
A simple scheduling algorithm using dynamic jobs registration can be found in
the `batsched submitter algorithm`_.
This implementation should work whether Redis is enabled and whether dynamic job submissions are acknowledged.
This implementation should work whether Redis is enabled and whether dynamic job registrations are acknowledged.
The following two figures outline how submissions should be done
The following two figures outline how registrations should be done
(depending on whether Redis is enabled or not).
Without Redis
......
This diff is collapsed.
......@@ -71,15 +71,19 @@ struct MainArguments
std::map<std::string, std::string> hosts_roles_map; //!< The hosts/roles mapping to be added to the hosts properties.
// Execution context
rapidjson::Document config_file; //!< The configuration file
std::string socket_endpoint; //!< The Decision process socket endpoint
bool redis_enabled; //!< Whether Redis is enabled
std::string redis_hostname; //!< The Redis (data storage) server host name
int redis_port; //!< The Redis (data storage) server port
std::string redis_prefix; //!< The Redis (data storage) instance prefix
// Job related
bool forward_profiles_on_submission; //!< Stores whether the profile information of submitted jobs should be sent to the scheduler
bool dynamic_registration_enabled; //!< Stores whether the scheduler will be able to register jobs and profiles during the simulation
bool ack_dynamic_registration; //!< Stores whether Batsim will acknowledge dynamic job registrations (emit JOB_SUBMITTED events)
// Output
std::string export_prefix; //!< The filename prefix used to export simulation information
bool enable_simgrid_process_tracing; //!< If set to true, this option enables the tracing of SimGrid processes
bool enable_schedule_tracing; //!< If set to true, the schedule is exported to a Pajé trace file
bool enable_machine_state_tracing; //!< If set to true, this option enables the tracing of the machine states into a CSV time series.
......@@ -95,7 +99,10 @@ struct MainArguments
bool terminate_with_last_workflow; //!< If true, allows to ignore the jobs submitted after the last workflow termination
// Other
bool allow_time_sharing; //!< Allows/forbids time sharing. Two jobs can run on the same machine if and only if time sharing is allowed.
std::list<std::pair<std::string, std::string>> simgrid_config; //!< The list of configuration options to pass to SimGrid.
bool dump_execution_context; //!< Instead of running the simulation, print the execution context as JSON on the standard output.
bool allow_time_sharing_on_compute; //!< Allows/forbids time sharing on compute machines. Two jobs can run on the same machine if and only if time sharing is allowed.
bool allow_time_sharing_on_storage; //!< Allows/forbids time sharing on storage machines. Two jobs can run on the same machine if and only if time sharing is allowed.
ProgramType program_type; //!< The program type (Batsim or Batexec at the moment)
std::string pfs_host_name; //!< The name of the SimGrid host which serves as parallel file system (a.k.a. large-capacity storage tier)
std::string hpst_host_name; //!< The name of the SimGrid host which serves as the high-performance storage tier
......
......@@ -50,13 +50,12 @@ struct BatsimContext
RedisStorage storage; //!< The RedisStorage
rapidjson::Document config_file; //!< The configuration file
rapidjson::Document config_json; //!< The configuration information sent to the scheduler
bool redis_enabled; //!< Stores whether Redis should be used
bool submission_forward_profiles; //!< Stores whether the profile information of submitted jobs should be sent to the scheduler
bool submission_sched_enabled; //!< Stores whether the scheduler will be able to send jobs along the simulation
bool submission_sched_finished = false; //!< Stores whether the scheduler has finished submitting jobs.
bool submission_sched_ack; //!< Stores whether Batsim will acknowledge dynamic job submission (emit JOB_SUBMITTED events)
bool kill_forward_profiles; //!< Stores whether the profile information of killed jobs should be sent to the scheduler
bool registration_sched_enabled; //!< Stores whether the scheduler will be able to register jobs and profiles during the simulation
bool registration_sched_finished = false; //!< Stores whether the scheduler has finished submitting jobs.
bool registration_sched_ack; //!< Stores whether Batsim will acknowledge dynamic job submission (emit JOB_SUBMITTED events)
bool terminate_with_last_workflow; //!< If true, allows to ignore the jobs submitted after the last workflow termination
......@@ -72,7 +71,8 @@ struct BatsimContext
bool energy_used; //!< Stores whether the energy part of Batsim should be used
bool smpi_used; //!< Stores whether SMPI should be used
bool allow_time_sharing; //!< Stores whether time sharing (using the same machines to compute different jobs) should be allowed
bool allow_time_sharing_on_compute; //!< Stores whether time sharing (using the same machines to compute different jobs) should be allowed on compute machines
bool allow_time_sharing_on_storage; //!< Stores whether time sharing (using the same machines to compute different jobs) should be allowed on storage machines
bool trace_schedule; //!< Stores whether the resulting schedule should be outputted
bool trace_machine_states; //!< Stores whether the machines states should be outputted
std::string platform_filename; //!< The name of the platform file
......
......@@ -69,11 +69,11 @@ std::string ip_message_type_to_string(IPMessageType type)
case IPMessageType::JOB_SUBMITTED:
s = "JOB_SUBMITTED";
break;
case IPMessageType::JOB_SUBMITTED_BY_DP:
s = "JOB_SUBMITTED_BY_DP";
case IPMessageType::JOB_REGISTERED_BY_DP:
s = "JOB_REGISTERED_BY_DP";
break;
case IPMessageType::PROFILE_SUBMITTED_BY_DP:
s = "PROFILE_SUBMITTED_BY_DP";
case IPMessageType::PROFILE_REGISTERED_BY_DP:
s = "PROFILE_REGISTERED_BY_DP";
break;
case IPMessageType::JOB_COMPLETED:
s = "JOB_COMPLETED";
......@@ -129,11 +129,11 @@ std::string ip_message_type_to_string(IPMessageType type)
case IPMessageType::KILLING_DONE:
s = "KILLING_DONE";
break;
case IPMessageType::END_DYNAMIC_SUBMIT:
s = "END_DYNAMIC_SUBMIT";
case IPMessageType::END_DYNAMIC_REGISTER:
s = "END_DYNAMIC_REGISTER";
break;
case IPMessageType::CONTINUE_DYNAMIC_SUBMIT:
s = "CONTINUE_DYNAMIC_SUBMIT";
case IPMessageType::CONTINUE_DYNAMIC_REGISTER:
s = "CONTINUE_DYNAMIC_REGISTER";
break;
case IPMessageType::TO_JOB_MSG:
s = "TO_JOB_MSG";
......@@ -168,14 +168,14 @@ IPMessage::~IPMessage()
JobSubmittedMessage * msg = (JobSubmittedMessage *) data;
delete msg;
} break;
case IPMessageType::JOB_SUBMITTED_BY_DP:
case IPMessageType::JOB_REGISTERED_BY_DP:
{
JobSubmittedByDPMessage * msg = (JobSubmittedByDPMessage *) data;
JobRegisteredByDPMessage * msg = (JobRegisteredByDPMessage *) data;
delete msg;
} break;
case IPMessageType::PROFILE_SUBMITTED_BY_DP:
case IPMessageType::PROFILE_REGISTERED_BY_DP:
{
ProfileSubmittedByDPMessage * msg = (ProfileSubmittedByDPMessage *) data;
ProfileRegisteredByDPMessage * msg = (ProfileRegisteredByDPMessage *) data;
delete msg;
} break;
case IPMessageType::JOB_COMPLETED:
......@@ -263,10 +263,10 @@ IPMessage::~IPMessage()
KillingDoneMessage * msg = (KillingDoneMessage *) data;