Get desktop application:
View/edit binary Protocol Buffers messages
* A network address. TODO(bmahler): Use this more widely.
Used in:
,May contain a hostname, IP address, or both.
* A unique ID assigned to an agent. Currently, an agent gets a new ID whenever it (re)registers with Mesos. Framework writers shouldn't assume any binding between an agent ID and and a hostname.
Used in:
, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,* Describes an agent. Note that the 'id' field is only available after an agent is registered with the master, and is made available here to facilitate re-registration.
Used in:
, , ,The configured resources at the agent. This does not include any dynamic reservations or persistent volumes that may currently exist at the agent.
The domain that this agent belongs to. If the agent's region differs from the master's region, it will not appear in resource offers to frameworks that have not enabled the REGION_AWARE capability.
Used in:
Enum fields should be optional, see: MESOS-4997.
Used in:
This must be the first enum value in this list, to ensure that if 'type' is not set, the default value is UNKNOWN. This enables enum values to be added in a backwards-compatible way. See: MESOS-4997.
This expresses the ability for the agent to be able to launch tasks of a 'multi-role' framework.
This expresses the ability for the agent to be able to launch tasks, reserve resources, and create volumes using resources allocated to a 'hierarchical-role'. NOTE: This capability is required specifically for creating volumes because a hierchical role includes '/' (slashes) in them. Agents with this capability know to transform the '/' (slashes) into ' ' (spaces).
This capability has three effects for an agent. (1) The format of the checkpointed resources, and the resources reported to master. These resources are reported in the "pre-reservation-refinement" format if none of the resources have refined reservations. If any of the resources have refined reservations, they are reported in the "post-reservation-refinement" format. The purpose is to allow downgrading of an agent as well as communication with a pre-1.4.0 master until the reservation refinement feature is actually used. See the 'Resource Format' section for more details. (2) The format of the resources reported by the HTTP endpoints. For resources reported by agent endpoints, the "pre-reservation-refinement" format is "injected" if possible. That is, resources without refined reservations will have the `Resource.role` and `Resource.reservation` set, whereas resources with refined reservations will not. See the 'Resource Format' section for more details. (3) The ability for the agent to launch tasks, reserve resources, and create volumes using resources that have refined reservations. See `ReservationInfo.reservations` section for more details. NOTE: Resources are said to have refined reservations if it uses the `Resource.reservations` field, and `Resource.reservations_size() > 1`.
This expresses the ability for the agent to handle resource provider related operations. This includes the following: (1) The ability to report resources that are provided by some local resource providers through the resource provider API. (2) The ability to provide operation feedback.
This expresses the capability for the agent to handle persistent volume resize operations safely. This capability is turned on by default.
* Describes an attribute that can be set on a machine. For now, attributes and resources share the same "value" type, but this may change in the future and attributes may only be string based.
Used in:
, , , ,* Describes the container configuration to run a CSI plugin component.
Used in:
Used in:
* Describes a CSI plugin.
Used in:
The type of the CSI plugin. This uniquely identifies a CSI implementation. For instance: org.apache.mesos.csi.test Please follow to Java package naming convention (https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions) to avoid conflicts on type names.
The name of the CSI plugin. There could be multiple instances of a type of CSI plugin within a Mesos cluster. The name field is used to distinguish these instances. It should be a legal Java identifier (https://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html) to avoid conflicts on concatenation of type and name. The type and name together provide the means to uniquely identify a storage backend and its resources in the cluster, so the operator should ensure that the concatenation of type and name is unique in the cluster, and it remains the same if the instance is migrated to another agent (e.g., there is a change in the agent ID).
A list of container configurations to run CSI plugin components. The controller service will be served by the first configuration that contains `CONTROLLER_SERVICE`, and the node service will be served by the first configuration that contains `NODE_SERVICE`.
* Encapsulation of `Capabilities` supported by Linux. Reference: http://linux.die.net/man/7/capabilities.
Used in:
We start the actual values at an offset(1000) because Protobuf 2 uses the first value as the default one. Separating the default value from the real first value helps to disambiguate them. This is especially valuable for backward compatibility. See: MESOS-4997.
Used in:
* Linux control group (cgroup) information.
Used in:
Configuration of a blkio cgroup subsystem.
(message has no fields)
(message has no fields)
Used in:
Stats are grouped by block devices. If `device` is not set, it represents `Total`.
blkio.sectors
blkio.time
blkio.io_serviced
blkio.io_service_bytes
blkio.io_service_time
blkio.io_wait_time
blkio.io_merged
blkio.io_queued
Used in:
Used in:
(message has no fields)
Used in:
Stats are grouped by block devices. If `device` is not set, it represents `Total`.
blkio.throttle.io_serviced
blkio.throttle.io_service_bytes
Describes a stat value without the device descriptor part.
Used in:
,Required.
Required.
Configuration of a net_cls cgroup subsystem.
Used in:
The 32-bit classid consists of two parts, a 16 bit major handle and a 16-bit minor handle. The major and minor handle are represented using the format 0xAAAABBBB, where 0xAAAA is the 16-bit major handle and 0xBBBB is the 16-bit minor handle.
* Describes a general non-interpreting non-killing check for a task or executor (or any arbitrary process/command). A type is picked by specifying one of the optional fields. Specifying more than one type is an error. NOTE: This API is subject to change and the related feature is experimental.
Used in:
The type of the check.
Command check.
HTTP check.
TCP check.
Amount of time to wait to start checking the task after it transitions to `TASK_RUNNING` or `TASK_STARTING` if the latter is used by the executor.
Interval between check attempts, i.e., amount of time to wait after the previous check finished or timed out to start the next check.
Amount of time to wait for the check to complete. Zero means infinite timeout. After this timeout, the check attempt is aborted and no result is reported. Note that this may be considered a state change and hence may trigger a check status change delivery to the corresponding scheduler. See `CheckStatusInfo` for more details.
Describes a command check. If applicable, enters mount and/or network namespaces of the task.
Used in:
Describes an HTTP check. Sends a GET request to http://<host>:port/path. Note that <host> is not configurable and is resolved automatically to 127.0.0.1.
Used in:
Port to send the HTTP request.
HTTP request path.
Describes a TCP check, i.e. based on establishing a TCP connection to the specified port. Note that <host> is not configurable and is resolved automatically to 127.0.0.1.
Used in:
Used in:
,* Describes the status of a check. Type and the corresponding field, i.e., `command` or `http` must be set. If the result of the check is not available (e.g., the check timed out), these fields must contain empty messages, i.e., `exit_code` or `status_code` will be unset. NOTE: This API is subject to change and the related feature is experimental.
Used in:
The type of the check this status corresponds to.
Status of a command check.
Status of an HTTP check.
Status of a TCP check.
Used in:
Exit code of a command check. It is the result of calling `WEXITSTATUS()` on `waitpid()` termination information on Posix and calling `GetExitCodeProcess()` on Windows.
Used in:
HTTP status code of an HTTP check.
Used in:
Whether a TCP connection succeeded.
* Describes a command, executed via: '/bin/sh -c value'. Any URIs specified are fetched before executing the command. If the executable field for an uri is set, executable file permission is set on the downloaded file. Otherwise, if the downloaded file has a recognized archive extension (currently [compressed] tar and zip) it is extracted into the executor's working directory. This extraction can be disabled by setting `extract` to false. In addition, any environment variables are set before executing the command (so they can be used to "parameterize" your command).
Used in:
, , , , , , , , ,There are two ways to specify the command: 1) If 'shell == true', the command will be launched via shell (i.e., /bin/sh -c 'value'). The 'value' specified will be treated as the shell command. The 'arguments' will be ignored. 2) If 'shell == false', the command will be launched by passing arguments to an executable. The 'value' specified will be treated as the filename of the executable. The 'arguments' will be treated as the arguments to the executable. This is similar to how POSIX exec families launch processes (i.e., execlp(value, arguments(0), arguments(1), ...)). NOTE: The field 'value' is changed from 'required' to 'optional' in 0.20.0. It will only cause issues if a new framework is connecting to an old master.
Enables executor and tasks to run as a specific user. If the user field is present both in FrameworkInfo and here, the CommandInfo user value takes precedence.
Used in:
In case the fetched file is recognized as an archive, extract its contents into the sandbox. Note that a cached archive is not copied from the cache to the sandbox in case extraction originates from an archive in the cache.
If this field is "true", the fetcher cache will be used. If not, fetching bypasses the cache and downloads directly into the sandbox directory, no matter whether a suitable cache file is available or not. The former directs the fetcher to download to the file cache, then copy from there to the sandbox. Subsequent fetch attempts with the same URI will omit downloading and copy from the cache as long as the file is resident there. Cache files may get evicted at any time, which then leads to renewed downloading. See also "docs/fetcher.md" and "docs/fetcher-cache-internals.md".
The fetcher's default behavior is to use the URI string's basename to name the local copy. If this field is provided, the local copy will be named with its value instead. If there is a directory component (which must be a relative path), the local copy will be stored in that subdirectory inside the sandbox.
* ID used to uniquely identify a container. If the `parent` is not specified, the ID is a UUID generated by the agent to uniquely identify the container of an executor run. If the `parent` field is specified, it represents a nested container.
Used in:
, , , , , , , , , , , , , ,* Describes a container configuration and allows extensible configurations for different container implementations. NOTE: `ContainerInfo` may be specified, e.g., by a task, even if no container image is provided. In this case neither `MesosInfo` nor `DockerInfo` is set, the required `type` must be `MESOS`. This is to address a case when a task without an image, e.g., a shell script with URIs, wants to use features originally designed for containers, for example custom network isolation via `NetworkInfo`.
Used in:
, , , , , , , ,Only one of the following *Info messages should be set to match the type.
A list of network requests. A framework can request multiple IP addresses for the container.
Linux specific information for the container.
(POSIX only) rlimits of the container.
If specified a tty will be attached to the container entrypoint.
Used in:
The docker image that is going to be passed to the registry.
Allowing arbitrary parameters to be passed to docker CLI. Note that anything passed to this field is not guaranteed to be supported moving forward, as we might move away from the docker CLI.
With this flag set to true, the docker containerizer will pull the docker image from the registry even if the image is already downloaded on the agent.
The name of volume driver plugin.
Since 1.0
Network options.
Used in:
Used in:
Protocol to expose as (ie: tcp, udp).
Used in:
All container implementation types.
Used in:
* Container related information that is resolved during container setup. The information is sent back to the framework as part of the TaskStatus message.
Used in:
,This field can be reliably used to identify the container IP address.
Information about Linux control group (cgroup).
Information about Executor PID.
* Credential used in various places for authentication and authorization. NOTE: A 'principal' is different from 'FrameworkInfo.user'. The former is used for authentication and authorization while the latter is used to determine the default user under which the framework's executors/tasks are run.
Used in:
,* Credentials used for framework authentication, HTTP authentication (where the common 'username' and 'password' are captured as 'principal' and 'secret' respectively), etc.
* Describes information about a device.
Used in:
Used in:
, ,* Describes a device whitelist entry that expose from host to container.
Used in:
Used in:
* Service discovery information. The visibility field restricts discovery within a framework (FRAMEWORK), within a Mesos cluster (CLUSTER), or places no restrictions (EXTERNAL). Each port in the ports field also has an optional visibility field. If visibility is specified for a port, it overrides the default service-wide DiscoveryInfo.visibility for that port. The environment, location, and version fields provide first class support for common attributes used to differentiate between similar services. The environment may receive values such as PROD/QA/DEV, the location field may receive values like EAST-US/WEST-US/EUROPE/AMEA, and the version field may receive values like v2.0/v0.9. The exact use of these fields is up to each service discovery system.
Used in:
, ,Used in:
,Used in:
* Describes a domain. A domain is a collection of hosts that have similar characteristics. Mesos currently only supports "fault domains", which identify groups of hosts with similar failure characteristics. Frameworks can generally assume that network links between hosts in the same fault domain have lower latency, higher bandwidth, and better availability than network links between hosts in different domains. Schedulers may prefer to place network-intensive workloads in the same domain, as this may improve performance. Conversely, a single failure that affects a host in a domain may be more likely to affect other hosts in the same domain; hence, schedulers may prefer to place workloads that require high availability in multiple domains. (For example, all the hosts in a single rack might lose power or network connectivity simultaneously.) There are two kinds of fault domains: regions and zones. Regions offer the highest degree of fault isolation, but network latency between regions is typically high (typically >50 ms). Zones offer a modest degree of fault isolation along with reasonably low network latency (typically <10 ms). The mapping from fault domains to physical infrastructure is up to the operator to configure. In cloud environments, regions and zones can be mapped to the "region" and "availability zone" concepts exposed by most cloud providers, respectively. In on-premise deployments, regions and zones can be mapped to data centers and racks, respectively. Both masters and agents can be configured with domains. Frameworks can compare the domains of two hosts to determine if the hosts are in the same zone, in different zones in the same region, or in different regions. Note that all masters in a given Mesos cluster must be in the same region.
Used in:
, ,Used in:
Used in:
Used in:
* Represents duration in nanoseconds.
Used in:
, , , , , , , ,* Describes a collection of environment variables. This is used with CommandInfo in order to set environment variables before running a command. The contents of each variable may be specified as a string or a Secret; only one of `value` and `secret` must be set.
Used in:
Used in:
In Mesos 1.2, the `Environment.variables.value` message was made optional. The default type for `Environment.variables.type` is now VALUE, which requires `value` to be set, maintaining backward compatibility. TODO(greggomann): The default can be removed in Mesos 2.1 (MESOS-7134).
Only one of `value` and `secret` must be set.
Used in:
* A framework-generated ID to distinguish an executor. Only one executor with the same ID can be active on the same agent at a time. However, reusing executor IDs is discouraged.
Used in:
, , , , , , , , , ,* Describes information about an executor.
Used in:
, , , , , , ,For backwards compatibility, if this field is not set when using `LAUNCH` operation, Mesos will infer the type by checking if `command` is set (`CUSTOM`) or unset (`DEFAULT`). `type` must be set when using `LAUNCH_GROUP` operation. TODO(vinod): Add support for explicitly setting `type` to `DEFAULT` in `LAUNCH` operation.
TODO(benh): Make this required.
Executor provided with a container will launch the container with the executor's CommandInfo and we expect the container to act as a Mesos executor.
'source' is an identifier style string used by frameworks to track the source of an executor. This is useful when it's possible for different executor ids to be related semantically. NOTE: 'source' is exposed alongside the resource usage of the executor via JSON on the agent. This allows users to import usage information into a time series database for monitoring. This field is deprecated since 1.0. Please use labels for free-form metadata instead.
Since 1.0.
This field can be used to pass arbitrary bytes to an executor.
Service discovery information for the executor. It is not interpreted or acted upon by Mesos. It is up to a service discovery system to use this information as needed and to handle executors without service discovery information.
When shutting down an executor the agent will wait in a best-effort manner for the grace period specified here before forcibly destroying the container. The executor must not assume that it will always be allotted the full grace period, as the agent may decide to allot a shorter period and failures / forcible terminations may occur.
Labels are free-form key value pairs which are exposed through master and agent endpoints. Labels will not be interpreted or acted upon by Mesos itself. As opposed to the data field, labels will be kept in memory on master and agent processes. Therefore, labels should be used to tag executors with lightweight metadata. Labels should not contain duplicate key-value pairs.
Used in:
Mesos provides a simple built-in default executor that frameworks can leverage to run shell commands and containers. NOTES: 1) `command` must not be set when using a default executor. 2) Default executor only accepts a *single* `LAUNCH` or `LAUNCH_GROUP` operation. 3) If `container` is set, `container.type` must be `MESOS` and `container.mesos.image` must not be set.
For frameworks that need custom functionality to run tasks, a `CUSTOM` executor can be used. Note that `command` must be set when using a `CUSTOM` executor.
* Describes a File.
Used in:
,Absolute path to the file.
Number of hard links.
Total size in bytes.
Last modification time.
Represents a file's mode and permission bits. The bits have the same definition on all systems and is portable.
User ID of owner.
Group ID of owner.
* Describes possible filters that can be applied to unused resources (see SchedulerDriver::launchTasks) to influence the allocator.
Used in:
, , ,Time to consider unused resources refused. Note that all unused resources will be considered refused and use the default value (below) regardless of whether Filters was passed to SchedulerDriver::launchTasks. You MUST pass Filters with this field set to change this behavior (i.e., get another offer which includes unused resources sooner or later than the default). If this field is set to a number of seconds greater than 31536000 (365 days), then the resources will be considered refused for 365 days. If it is set to a negative number, then the default value will be used.
* Flag consists of a name and optionally its value.
Used in:
,* A unique ID assigned to a framework. A framework can reuse this ID in order to do failover (see MesosSchedulerDriver).
Used in:
, , , , , , , , , , , , , , ,* Describes a framework.
Used in:
, , , , ,Used to determine the Unix user that an executor or task should be launched as. When using the MesosSchedulerDriver, if the field is set to an empty string, it will automagically set it to the current user. When using the HTTP Scheduler API, the user has to be set explicitly.
Name of the framework that shows up in the Mesos Web UI.
Note that 'id' is only available after a framework has registered, however, it is included here in order to facilitate scheduler failover (i.e., if it is set then the MesosSchedulerDriver expects the scheduler is performing failover).
The amount of time (in seconds) that the master will wait for the scheduler to failover before it tears down the framework by killing all its tasks/executors. This should be non-zero if a framework expects to reconnect after a failure and not lose its tasks/executors. NOTE: To avoid accidental destruction of tasks, production frameworks typically set this to a large value (e.g., 1 week).
If set, agents running tasks started by this framework will write the framework pid, executor pids and status updates to disk. If the agent exits (e.g., due to a crash or as part of upgrading Mesos), this checkpointed data allows the restarted agent to reconnect to executors that were started by the old instance of the agent. Enabling checkpointing improves fault tolerance, at the cost of a (usually small) increase in disk I/O.
Roles are the entities to which allocations are made. The framework must have at least one role in order to be offered resources. Note that `role` is deprecated in favor of `roles` and only one of these fields must be used. Since we cannot distinguish between empty `roles` and the default unset `role`, we require that frameworks set the `MULTI_ROLE` capability if setting the `roles` field.
Used to indicate the current host from which the scheduler is registered in the Mesos Web UI. If set to an empty string Mesos will automagically set it to the current hostname if one is available.
This field should match the credential's principal the framework uses for authentication. This field is used for framework API rate limiting and dynamic reservations. It should be set even if authentication is not enabled if these features are desired.
This field allows a framework to advertise its web UI, so that the Mesos web UI can link to it. It is expected to be a full URL, for example http://my-scheduler.example.com:8080/.
This field allows a framework to advertise its set of capabilities (e.g., ability to receive offers for revocable resources).
Labels are free-form key value pairs supplied by the framework scheduler (e.g., to describe additional functionality offered by the framework). These labels are not interpreted by Mesos itself. Labels should not contain duplicate key-value pairs.
Used in:
Enum fields should be optional, see: MESOS-4997.
Used in:
This must be the first enum value in this list, to ensure that if 'type' is not set, the default value is UNKNOWN. This enables enum values to be added in a backwards-compatible way. See: MESOS-4997.
Receive offers with revocable resources. See 'Resource' message for details.
Receive the TASK_KILLING TaskState when a task is being killed by an executor. The executor will examine this capability to determine whether it can send TASK_KILLING.
Indicates whether the framework is aware of GPU resources. Frameworks that are aware of GPU resources are expected to avoid placing non-GPU workloads on GPU agents, in order to avoid occupying a GPU agent and preventing GPU workloads from running! Currently, if a framework is unaware of GPU resources, it will not be offered *any* of the resources on an agent with GPUs. This restriction is in place because we do not have a revocation mechanism that ensures GPU workloads can evict GPU agent occupants if necessary. TODO(bmahler): As we add revocation we can relax the restriction here. See MESOS-5634 for more information.
Receive offers with resources that are shared.
Indicates that (1) the framework is prepared to handle the following TaskStates: TASK_UNREACHABLE, TASK_DROPPED, TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN, and (2) the framework will assume responsibility for managing partitioned tasks that reregister with the master. Frameworks that enable this capability can define how they would like to handle partitioned tasks. Frameworks will receive TASK_UNREACHABLE for tasks on agents that are partitioned from the master. Without this capability, frameworks will receive TASK_LOST for tasks on partitioned agents. NOTE: Prior to Mesos 1.5, such tasks will be killed by Mesos when the agent reregisters (unless the master has failed over). However due to the lack of benefit in maintaining different behaviors depending on whether the master has failed over (see MESOS-7215), as of 1.5, Mesos will not kill these tasks in either case.
This expresses the ability for the framework to be "multi-tenant" via using the newly introduced `roles` field, and examining `Offer.allocation_info` to determine which role the offers are being made to. We also expect that "single-tenant" schedulers eventually provide this and move away from the deprecated `role` field.
This capability has two effects for a framework. (1) The framework is offered resources in a new format. The offered resources have the `Resource.reservations` field set rather than `Resource.role` and `Resource.reservation`. In short, an empty `reservations` field denotes unreserved resources, and each `ReservationInfo` in the `reservations` field denotes a reservation that refines the previous one. See the 'Resource Format' section for more details. (2) The framework can create refined reservations. A framework can refine an existing reservation via the `Resource.reservations` field. For example, a reservation for role `eng` can be refined to `eng/front_end`. See `ReservationInfo.reservations` for more details. NOTE: Without this capability, a framework is not offered resources that have refined reservations. A resource is said to have refined reservations if it uses the `Resource.reservations` field, and `Resource.reservations_size() > 1`.
EXPERIMENTAL.
Indicates that the framework is prepared to receive offers for agents whose region is different from the master's region. Network links between hosts in different regions typically have higher latency and lower bandwidth than network links within a region, so frameworks should be careful to only place suitable workloads in remote regions. Frameworks that are not region-aware will never receive offers for remote agents; region-aware frameworks are assumed to implement their own logic to decide which workloads (if any) are suitable for placement on remote agents.
* Describes a health check for a task or executor (or any arbitrary process/command). A type is picked by specifying one of the optional fields. Specifying more than one type is an error.
Used in:
Amount of time to wait to start health checking the task after it transitions to `TASK_RUNNING` or `TASK_STATING` if the latter is used by the executor.
Interval between health checks, i.e., amount of time to wait after the previous health check finished or timed out to start the next health check.
Amount of time to wait for the health check to complete. After this timeout, the health check is aborted and treated as a failure. Zero means infinite timeout.
Number of consecutive failures until the task is killed by the executor.
Amount of time after the task is launched during which health check failures are ignored. Once a check succeeds for the first time, the grace period does not apply anymore. Note that it includes `delay_seconds`, i.e., setting `grace_period_seconds` < `delay_seconds` has no effect.
The type of health check.
Command health check.
HTTP health check.
TCP health check.
Describes an HTTP health check. Sends a GET request to scheme://<host>:port/path. Note that <host> is not configurable and is resolved automatically, in most cases to 127.0.0.1. Default executors treat return codes between 200 and 399 as success; custom executors may employ a different strategy, e.g. leveraging the `statuses` field.
Used in:
Currently "http" and "https" are supported.
Port to send the HTTP request.
HTTP request path.
NOTE: It is up to the custom executor to interpret and act on this field. Setting this field has no effect on the default executors. TODO(haosdent): Deprecate this field when we add better support for success and possibly failure statuses, e.g. ranges of success and failure statuses.
Describes a TCP health check, i.e. based on establishing a TCP connection to the specified port.
Used in:
Port expected to be open.
Used in:
Used in:
* Describe an image used by tasks or executors. Note that it's only for tasks or executors launched by MesosContainerizer currently.
Used in:
, ,Only one of the following image messages should be set to match the type.
With this flag set to false, the mesos containerizer will pull the docker/appc image from the registry even if the image is already downloaded on the agent.
Protobuf for specifying an Appc container image. See: https://github.com/appc/spec/blob/master/spec/aci.md
Used in:
The name of the image.
An image ID is a string of the format "hash-value", where "hash" is the hash algorithm used and "value" is the hex encoded string of the digest. Currently the only permitted hash algorithm is sha512.
Optional labels. Suggested labels: "version", "os", and "arch".
Used in:
The name of the image. Expected format: [REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG|@TYPE:DIGEST] See: https://docs.docker.com/reference/commandline/pull/
Credential to authenticate with docker registry. NOTE: This is not encrypted, therefore framework and operators should enable SSL when passing this information. This field has never been used in Mesos before and is deprecated since Mesos 1.3. Please use `config` below (see MESOS-7088 for details).
Since 1.3.
Docker config containing credentials to authenticate with docker registry. The secret is expected to be a docker config file in JSON format with UTF-8 character encoding.
Used in:
* A request to return some resources occupied by a framework.
Used in:
,This is the same OfferID as found in normal offers, which allows re-use of some of the OfferID-only messages.
URL for reaching the agent running on the host. This enables some optimizations as described in MESOS-3012, such as allowing the scheduler driver to bypass the master and talk directly with an agent.
The framework that should release its resources. If no specifics are provided (i.e. which agent), all the framework's resources are requested back.
Specified if the resources need to be released from a particular agent. All the framework's resources on this agent are requested back, unless further qualified by the `resources` field.
This InverseOffer represents a planned unavailability event in the specified interval. Any tasks running on the given framework or agent may be killed when the interval arrives. Therefore, frameworks should aim to gracefully terminate tasks prior to the arrival of the interval. For reserved resources, the resources are expected to be returned to the framework after the unavailability interval. This is an expectation, not a guarantee. For example, if the unavailability duration is not set, the resources may be removed permanently. For other resources, there is no guarantee that requested resources will be returned after the unavailability interval. The allocator has no obligation to re-offer these resources to the prior framework after the unavailability.
A list of resources being requested back from the framework, on the agent identified by `agent_id`. If no resources are specified then all resources are being requested back. For the purpose of maintenance, this field is always empty (maintenance always requests all resources back).
Used in:
* Describes a kill policy for a task. Currently does not express different policies (e.g. hitting HTTP endpoints), only controls how long to wait between graceful and forcible task kill: graceful kill --------------> forcible kill grace_period Kill policies are best-effort, because machine failures / forcible terminations may occur. NOTE: For executor-less command-based tasks, the kill is performed via sending a signal to the task process: SIGTERM for the graceful kill and SIGKILL for the forcible kill. For the docker executor-less tasks the grace period is passed to 'docker stop --time'.
Used in:
, ,The grace period specifies how long to wait before forcibly killing the task. It is recommended to attempt to gracefully kill the task (and send TASK_KILLING) to indicate that the graceful kill is in progress. Once the grace period elapses, if the task has not terminated, a forcible kill should occur. The task should not assume that it will always be allotted the full grace period. For example, the executor may be shutdown more quickly by the agent, or failures / forcible terminations may occur.
* Key, value pair used to store free form user-data.
Used in:
* Collection of labels. Labels should not contain duplicate key-value pairs.
Used in:
, , , , , , , , , , , , ,* Encapsulation for Linux specific configuration. E.g, capabilities, limits etc.
Used in:
Since 1.4.0, deprecated in favor of `effective_capabilities`.
The set of capabilities that are allowed but not initially granted to tasks.
Represents the set of capabilities that the task will be executed with.
If set as 'true', the container shares the pid namespace with its parent. If the container is a top level container, it will share the pid namespace with the agent. If the container is a nested container, it will share the pid namespace with its parent container. This field will be ignored if 'namespaces/pid' isolator is not enabled.
* Represents a single machine, which may hold one or more agents. NOTE: In order to match an agent to a machine, both the `hostname` and `ip` must match the values advertised by the agent to the master. Hostname is not case-sensitive.
Used in:
, , , , ,* Holds information about a single machine, its `mode`, and any other relevant information which may affect the behavior of the machine.
Signifies that the machine may be unavailable during the given interval. See comments in `Unavailability` and for the `unavailability` fields in `Offer` and `InverseOffer` for more information.
Describes the several states that a machine can be in. A `Mode` applies to a machine and to all associated agents on the machine.
Used in:
In this mode, a machine is behaving normally; offering resources, executing tasks, etc.
In this mode, all agents on the machine are expected to cooperate with frameworks to drain resources. In general, draining is done ahead of a pending `unavailability`. The resources should be drained so as to maximize utilization prior to the maintenance but without knowingly violating the frameworks' requirements.
In this mode, a machine is not running any tasks and will not offer any of its resources. Agents on the machine will not be allowed to register with the master.
* Describes a master. This will probably have more fields in the future which might be used, for example, to link a framework webui to a master webui.
Used in:
,The IP address (only IPv4) as a packed 4-bytes integer, stored in network order. Deprecated, use `address.ip` instead.
The TCP port the Master is listening on for incoming HTTP requests; deprecated, use `address.port` instead.
In the default implementation, this will contain information about both the IP address, port and Master name; it should really not be relied upon by external tooling/frameworks and be considered an "internal" implementation field.
The server's hostname, if available; it may be unreliable in environments where the DNS configuration does not resolve internal hostnames (eg, some public cloud providers). Deprecated, use `address.hostname` instead.
The running Master version, as a string; taken from the generated "master/version.hpp".
The full IP address (supports both IPv4 and IPv6 formats) and supersedes the use of `ip`, `port` and `hostname`. Since Mesos 0.24.
The domain that this master belongs to. All masters in a Mesos cluster should belong to the same region.
Used in:
Used in:
The master can handle slaves whose state changes after reregistering.
* Metric consists of a name and optionally its value.
Used in:
,* Describes how the mount will be propagated for a volume. See the following doc for more details about mount propagation: https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
Used in:
Used in:
The volume in a container will receive new mounts from the host or other containers, but filesystems mounted inside the container won't be propagated to the host or other containers. This is currently the default behavior for all volumes.
The volume in a container will receive new mounts from the host or other containers, and its own mounts will be propagated from the container to the host or other containers.
* Describes a network request from a framework as well as network resolution provided by Mesos. A framework may request the network isolator on the Agent to isolate the container in a network namespace and create a virtual network interface. The `NetworkInfo` message describes the properties of that virtual interface, including the IP addresses and network isolation policy (network group membership). The NetworkInfo message is not interpreted by the Master or Agent and is intended to be used by Agent and Master modules implementing network isolation. If the modules are missing, the message is simply ignored. In future, the task launch will fail if there is no module providing the network isolation capabilities (MESOS-3390). An executor, Agent, or an Agent module may append NetworkInfos inside TaskStatus::container_status to provide information such as the container IP address and isolation groups.
Used in:
,When included in a ContainerInfo, each of these represent a request for an IP address. Each request can specify an explicit address or the IP protocol to use. When included in a TaskStatus message, these inform the framework scheduler about the IP addresses that are bound to the container interface. When there are no custom network isolator modules installed, this field is filled in automatically with the Agent IP address.
Name of the network which will be used by network isolator to determine the network that the container joins. It's up to the network isolator to decide how to interpret this field.
A group is the name given to a set of logically-related interfaces that are allowed to communicate among themselves. Network traffic is allowed between two container interfaces that share at least one network group. For example, one might want to create separate groups for isolating dev, testing, qa and prod deployment environments.
To tag certain metadata to be used by Isolator/IPAM, e.g., rack, etc.
Specifies a request for an IP address, or reports the assigned container IP address. Users can request an automatically assigned IP (for example, via an IPAM service) or a specific IP by adding a NetworkInfo to the ContainerInfo for a task. On a request, specifying neither `protocol` nor `ip_address` means that any available address may be assigned.
Used in:
Specify IP address requirement. Set protocol to the desired value to request the network isolator on the Agent to assign an IP address to the container being launched. If a specific IP address is specified in ip_address, this field should not be set.
Statically assigned IP provided by the Framework. This IP will be assigned to the container by the network isolator module on the Agent. This field should not be used with the protocol field above. If an explicit address is requested but is unavailable, the network isolator should fail the task.
Specifies a port mapping request for the task on this network.
Used in:
Protocol to expose as (ie: tcp, udp).
Used in:
, ,* Describes some resources available on an agent. An offer only contains resources from a single agent.
Used in:
, , ,URL for reaching the agent running on the host.
The domain of the agent.
Executors of the same framework running on this agent.
Signifies that the resources in this Offer may be unavailable during the given interval. Any tasks launched using these resources may be killed when the interval arrives. For example, these resources may be part of a planned maintenance schedule. This field only provides information about a planned unavailability. The unavailability interval may not necessarily start at exactly this interval, nor last for exactly the duration of this interval. The unavailability may also be forever! See comments in `Unavailability` for more details.
An offer represents resources allocated to *one* of the roles managed by the scheduler. (Therefore, each `Offer.resources[i].allocation_info` will match the top level `Offer.allocation_info`).
Defines an operation that can be performed against offers.
Used in:
, ,NOTE: The `id` field will allow frameworks to indicate that they wish to receive feedback about an operation. Since this feature is not yet implemented, the `id` field should NOT be set at present. See MESOS-8054.
EXPERIMENTAL.
EXPERIMENTAL.
EXPERIMENTAL.
EXPERIMENTAL.
EXPERIMENTAL.
Used in:
Create a `MOUNT` or `BLOCK` disk resource backed by a CSI volume from a `RAW` disk resource. In the typical case where the `RAW` disk resource has a profile and no source ID, a new CSI volume will be provisioned by Mesos to back the returned `MOUNT` or `BLOCK` disk resource. However, the `RAW` disk resource can instead have no profile but a source ID, indicating that it is already backed by a CSI volume in one of the following scenarios: (1) The CSI volume is preprovisioned out-of-band. (2) The CSI volume is provisioned by Mesos, but Mesos has lost the corresponding `MOUNT` or `BLOCK` resource metadata. This could happen if there has been a change in the agent ID or resource provider ID where the volume belongs. In the above cases, Mesos won't provision a new CSI volume, but instead will simply return a `MOUNT` or `BLOCK` disk resource backed by the same CSI volume, with the profile specified in this call. NOTE: For the time being, this API is subject to change and the related feature is experimental.
Used in:
NOTE: Only `MOUNT` or `BLOCK` is allowed in this field.
Apply the specified profile to the created disk. This field must be set if `source` does not have a profile, and must not be set if it has one. NOTE: The operation will fail If the specified profile is unknown to Mesos, i.e., not reported by the disk profile adaptor.
Used in:
Destroy a disk resource backed by a CSI volume. In the typical case where the CSI plugin of the volume supports volume deprovisioning and the disk resource is a `MOUNT` or `BLOCK` disk with a profile known to Mesos, the volume will be deprovisioned and a `RAW` disk resource with the same profile but no source ID will be returned. However, the following scenarios could lead to different outcomes: (1) If the CSI plugin supports volume deprovisioning but the profile of the disk resource is unknown to the disk profile adaptor, or the disk resource is a `RAW` disk with no profile but a source ID (see above for possible scenarios), the volume will be deprovisioned but no resource will be returned. (2) If the CSI plugin does not support volume deprovisioning, the volume won't be deprovisioned and a `RAW` disk resource with no profile but the same source ID will be returned. NOTE: For the time being, this API is subject to change and the related feature is experimental.
Used in:
NOTE: Only a `MOUNT`, `BLOCK` or `RAW` disk is allowed in this field.
Grow a volume by an additional disk resource. NOTE: This is currently experimental and only for persistent volumes created on ROOT/PATH disk.
Used in:
TODO(vinod): Deprecate this in favor of `LaunchGroup` below.
Used in:
Unlike `Launch` above, all the tasks in a `task_group` are atomically delivered to an executor. `NetworkInfo` set on executor will be shared by all tasks in the task group. TODO(vinod): Any volumes set on executor could be used by a task by explicitly setting `Volume.source` in its resources.
Used in:
Used in:
Shrink a volume by the size specified in the `subtract` field. NOTE: This is currently experimental and only for persistent volumes created on ROOT/PATH disk.
Used in:
See comments in `Value.Scalar` for maximum precision supported.
Used in:
EXPERIMENTAL.
EXPERIMENTAL.
EXPERIMENTAL.
EXPERIMENTAL.
Used in:
* A unique ID assigned to an offer.
Used in:
, , , , , , ,* Describes an operation, similar to `Offer.Operation`, with some additional information.
Used in:
, ,All the statuses known to this operation. Some of the statuses in this list might not have been acknowledged yet. The statuses are ordered.
This is the internal UUID for the operation, which is kept independently from the framework-specified operation ID, which is optional.
* A framework-generated ID to distinguish an operation. The ID must be unique within the framework.
Used in:
, , ,* Describes possible operation states.
Used in:
Default value if the enum is not set. See MESOS-4997.
Initial state.
TERMINAL: The operation was successfully applied.
TERMINAL: The operation failed to apply.
TERMINAL: The operation description contains an error.
TERMINAL: The operation was dropped due to a transient error.
The operation affects an agent that has lost contact with the master, typically due to a network failure or partition. The operation may or may not still be pending.
The operation affected an agent that the master cannot contact; the operator has asserted that the agent has been shutdown, but this has not been directly confirmed by the master. If the operator is correct, the operation is not pending and this is a terminal state; if the operator is mistaken, the operation may still be pending and might return to a different state in the future.
The operation affects an agent that the master recovered from its state, but that agent has not yet re-registered. The operation can transition to `OPERATION_UNREACHABLE` if the corresponding agent is marked as unreachable, and will transition to another status if the agent re-registers.
The master has no knowledge of the operation. This is typically because either (a) the master never had knowledge of the operation, or (b) the master forgot about the operation because it garbage collected its metadata about the operation. The operation may or may not still be pending.
* Describes the current status of an operation.
Used in:
, , ,While frameworks will only receive status updates for operations on which they have set an ID, this field is optional because this message is also used internally by Mesos components when the operation's ID has not been set.
Converted resources after applying the operation. This only applies if the `state` is `OPERATION_FINISHED`.
Statuses that are delivered reliably to the scheduler will include a `uuid`. The status is considered delivered once it is acknowledged by the scheduler.
If the operation affects resources from a local resource provider, both `agent_id` and `resource_provider_id` will be set. If the operation affects resources that belong to an external resource provider, only `resource_provider_id` will be set. In certain cases, e.g., invalid operations, neither `uuid`, `slave_id` nor `resource_provider_id` will be set, and the scheduler does not need to acknowledge this status update.
* A generic (key, value) pair used in various places for parameters.
Used in:
, ,* Collection of Parameter.
Used in:
* Describes a sample of events from "perf stat". Only available on Linux. NOTE: Each optional field matches the name of a perf event (see "perf list") with the following changes: 1. Names are downcased. 2. Hyphens ('-') are replaced with underscores ('_'). 3. Events with alternate names use the name "perf stat" returns, e.g., for the event "cycles OR cpu-cycles" perf always returns cycles.
Used in:
Start of sample interval, in seconds since the Epoch.
Duration of sample interval, in seconds.
Hardware event.
Software event.
Hardware cache event.
* Named port used for service discovery.
Used in:
Port number on which the framework exposes a service.
Name of the service hosted on this port.
Layer 4-7 protocol on which the framework exposes its services.
This field restricts discovery within a framework (FRAMEWORK), within a Mesos cluster (CLUSTER), or places no restrictions (EXTERNAL). The visibility setting for a Port overrides the general visibility setting in the DiscoveryInfo.
This can be used to decorate the message with metadata to be interpreted by external applications such as firewalls.
* Collection of ports.
Used in:
* Encapsulation for POSIX rlimits, see http://pubs.opengroup.org/onlinepubs/009695399/functions/getrlimit.html. Note that some types might only be defined for Linux. We use a custom prefix to avoid conflict with existing system macros (e.g., `RLIMIT_CPU` or `NOFILE`).
Used in:
Used in:
Either both are set or both are not set. If both are not set, it represents unlimited. If both are set, we require `soft` <= `hard`.
Used in:
* Rate (queries per second, QPS) limit for messages from a framework to master. Strictly speaking they are the combined rate from all frameworks of the same principal.
Used in:
Leaving QPS unset gives it unlimited rate (i.e., not throttled), which also implies unlimited capacity.
Principal of framework(s) to be throttled. Should match FrameworkInfo.principal and Credential.principal (if using authentication).
Max number of outstanding messages from frameworks of this principal allowed by master before the next message is dropped and an error is sent back to the sender. Messages received before the capacity is reached are still going to be processed after the error is sent. If unspecified, this principal is assigned unlimited capacity. NOTE: This value is ignored if 'qps' is not set.
* Collection of RateLimit. Frameworks without rate limits defined here are not throttled unless 'aggregate_default_qps' is specified.
Items should have unique principals.
All the frameworks not specified in 'limits' get this default rate. This rate is an aggregate rate for all of them, i.e., their combined traffic is throttled together at this rate.
All the frameworks not specified in 'limits' get this default capacity. This is an aggregate value similar to 'aggregate_default_qps'.
* Describes a request for resources that can be used by a framework to proactively influence the allocator. If 'agent_id' is provided then this request is assumed to only apply to resources on that agent.
Used in:
* Describes a resource from a resource provider. The `name` field is a string like "cpus" or "mem" that indicates which kind of resource this is; the rest of the fields describe the properties of the resource. A resource can take on one of three types: scalar (double), a list of finite and discrete ranges (e.g., [1-10, 20-30]), or a set of items. A resource is described using the standard protocol buffer "union" trick. Note that "disk" and "mem" resources are scalar values expressed in megabytes. Fractional "cpus" values are allowed (e.g., "0.5"), which correspond to partial shares of a CPU.
Used in:
, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,The role that this resource is reserved for. If "*", this indicates that the resource is unreserved. Otherwise, the resource will only be offered to frameworks that belong to this role. NOTE: Frameworks must not set this field if `reservations` is set. See the 'Resource Format' section for more details. TODO(mpark): Deprecate once `reservations` is no longer experimental.
If this is set, this resource was dynamically reserved by an operator or a framework. Otherwise, this resource is either unreserved or statically reserved by an operator via the --resources flag. NOTE: Frameworks must not set this field if `reservations` is set. See the 'Resource Format' section for more details. TODO(mpark): Deprecate once `reservations` is no longer experimental.
The stack of reservations. If this field is empty, it indicates that this resource is unreserved. Otherwise, the resource is reserved. The first `ReservationInfo` may have type `STATIC` or `DYNAMIC`, but the rest must have `DYNAMIC`. One can create a new reservation on top of an existing one by pushing a new `ReservationInfo` to the back. The last `ReservationInfo` in this stack is the "current" reservation. The new reservation's role must be a child of the current reservation's role. NOTE: Frameworks must not set this field if `reservation` is set. See the 'Resource Format' section for more details. TODO(mpark): Deprecate `role` and `reservation` once this is stable.
EXPERIMENTAL.
If this is set, the resources are revocable, i.e., any tasks or executors launched using these resources could get preempted or throttled at any time. This could be used by frameworks to run best effort tasks that do not need strict uptime or performance guarantees. Note that if this is set, 'disk' or 'reservation' cannot be set.
If this is set, the resources are shared, i.e. multiple tasks can be launched using this resource and all of them shall refer to the same physical resource on the cluster. Note that only persistent volumes can be shared currently.
This was initially introduced to support MULTI_ROLE capable frameworks. Frameworks that are not MULTI_ROLE capable can continue to assume that the offered resources are allocated to their role.
Used in:
,If set, this resource is allocated to a role. Note that in the future, this may be unset and the scheduler may be responsible for allocating to one of its roles.
Used in:
Describes how this disk resource will be mounted in the container. If not set, the disk resource will be used as the sandbox. Otherwise, it will be mounted according to the 'container_path' inside 'volume'. The 'host_path' inside 'volume' is ignored. NOTE: If 'volume' is set but 'persistence' is not set, the volume will be automatically garbage collected after task/executor terminates. Currently, if 'persistence' is set, 'volume' must be set.
Describes a persistent disk volume. A persistent disk volume will not be automatically garbage collected if the task/executor/agent terminates, but will be re-offered to the framework(s) belonging to the 'role'. NOTE: Currently, we do not allow persistent disk volumes without a reservation (i.e., 'role' cannot be '*').
Used in:
,A unique ID for the persistent disk volume. This ID must be unique per role on each agent. Although it is possible to use the same ID on different agents in the cluster and to reuse IDs after a volume with that ID has been destroyed, both practices are discouraged.
This field indicates the principal of the operator or framework that created this volume. It is used in conjunction with the "destroy" ACL to determine whether an entity attempting to destroy the volume is permitted to do so. NOTE: This field should match the FrameworkInfo.principal of the framework that created the volume.
Describes where a disk originates from.
Used in:
,The vendor of this source. If present, this field provides the means to uniquely identify the storage backend of this source in the cluster.
EXPERIMENTAL.
The identifier of this source. This field maps onto CSI volume IDs and is not expected to be set by frameworks. If both `vendor` and `id` are present, these two fields together provide the means to uniquely identify this source in the cluster.
EXPERIMENTAL.
Additional metadata for this source. This field maps onto CSI volume attributes and is not expected to be set by frameworks.
EXPERIMENTAL.
This field serves as an indirection to a set of storage vendor specific disk parameters which describe the properties of the disk. The operator will setup mappings between a profile name to a set of vendor specific disk parameters. And the framework will do disk selection based on profile names, instead of vendor specific disk parameters. Also see the DiskProfileAdaptor module.
EXPERIMENTAL.
A mounted file-system set up by the Agent administrator. This can only be used exclusively: a framework cannot accept a partial amount of this disk.
Used in:
Path to mount point (e.g., /mnt/raid/disk0). If the path is a relative path, it is relative to the agent work directory.
A folder that can be located on a separate disk device. This can be shared and carved up as necessary between frameworks.
Used in:
Path to the folder (e.g., /mnt/raid/disk0). If the path is a relative path, it is relative to the agent work directory.
Used in:
,Describes a reservation. A static reservation is set by the operator on the command-line and they are immutable without agent restart. A dynamic reservation is made by an operator via the '/reserve' HTTP endpoint or by a framework via the offer cycle by sending back an 'Offer::Operation::Reserve' message. NOTE: We currently do not allow frameworks with role "*" to make dynamic reservations.
Used in:
,The type of this reservation. NOTE: This field must not be set for `Resource.reservation`. See the 'Resource Format' section for more details.
The role to which this reservation is made for. NOTE: This field must not be set for `Resource.reservation`. See the 'Resource Format' section for more details.
Indicates the principal, if any, of the framework or operator that reserved this resource. If reserved by a framework, the field should match the `FrameworkInfo.principal`. It is used in conjunction with the `UnreserveResources` ACL to determine whether the entity attempting to unreserve this resource is permitted to do so.
Labels are free-form key value pairs that can be used to associate arbitrary metadata with a reserved resource. For example, frameworks can use labels to identify the intended purpose for a portion of the resources the framework has reserved at a given agent. Labels should not contain duplicate key-value pairs.
Used in:
Used in:
(message has no fields)
Allow the resource to be shared across tasks.
Used in:
(message has no fields)
* A unique ID assigned to a resource provider. Currently, a resource provider gets a new ID whenever it (re)registers with Mesos.
Used in:
, , , , , ,* Describes a resource provider. Note that the 'id' field is only available after a resource provider is registered with the master, and is made available here to facilitate re-registration.
Used in:
, , , ,The type of the resource provider. This uniquely identifies a resource provider implementation. For instance: org.apache.mesos.rp.local.storage Please follow to Java package naming convention (https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions) to avoid conflicts on type names.
The name of the resource provider. There could be multiple instances of a type of resource provider. The name field is used to distinguish these instances. It should be a legal Java identifier (https://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html) to avoid conflicts on concatenation of type and name.
The stack of default reservations. If this field is not empty, it indicates that resources from this resource provider are reserved by default, except for the resources that have been reserved or unreserved through operations. The first `ReservationInfo` may have type `STATIC` or `DYNAMIC`, but the rest must have `DYNAMIC`. One can create a new reservation on top of an existing one by pushing a new `ReservationInfo` to the back. The last `ReservationInfo` in this stack is the "current" reservation. The new reservation's role must be a child of the current one.
EXPERIMENTAL.
EXPERIMENTAL.
Storage resource provider related information.
Used in:
* A snapshot of resource usage statistics.
Used in:
,Snapshot time, in seconds since the Epoch.
CPU Usage Information: Total CPU time spent in user mode, and kernel mode.
Number of CPUs allocated.
cpu.stat on process throttling (for contention issues).
mem_total_bytes was added in 0.23.0 to represent the total memory of a process in RAM (as opposed to in Swap). This was previously reported as mem_rss_bytes, which was also changed in 0.23.0 to represent only the anonymous memory usage, to keep in sync with Linux kernel's (arguably erroneous) use of terminology.
Total memory + swap usage. This is set if swap is enabled.
Hard memory limit for a container.
Soft memory limit for a container.
TODO(chzhcn) mem_file_bytes and mem_anon_bytes are deprecated in 0.23.0 and will be removed in 0.24.0.
mem_cache_bytes is added in 0.23.0 to represent page cache usage.
Since 0.23.0, mem_rss_bytes is changed to represent only anonymous memory usage. Note that neither its requiredness, type, name nor numeric tag has been changed.
This is only set if swap is enabled.
Number of occurrences of different levels of memory pressure events reported by memory cgroup. Pressure listening (re)starts with these values set to 0 when agent (re)starts. See https://www.kernel.org/doc/Documentation/cgroups/memory.txt for more details.
Disk Usage Information for executor working directory.
Per disk (resource) statistics.
Cgroups blkio statistics.
Perf statistics.
Network Usage Information:
The kernel keeps track of RTT (round-trip time) for its TCP sockets. RTT is a way to tell the latency of a container.
Network traffic flowing into or out of a container can be delayed or dropped due to congestion or policy inside and outside the container.
Network SNMP statistics for each container.
* Describes a snapshot of the resource usage for executors.
Agent's total resources including checkpointed dynamic reservations and persistent volumes.
Used in:
This includes resources used by the executor itself as well as its active tasks.
Current resource usage. If absent, the containerizer cannot provide resource usage.
The container id for the executor specified in the executor_info field.
Non-terminal tasks.
Used in:
* Describes a Role. Roles can be used to specify that certain resources are reserved for the use of one or more frameworks.
Used in:
Used in:
* Secret used to pass privileged information. It is designed to provide pass-by-value or pass-by-reference semantics, where the REFERENCE type can be used by custom modules which interact with a secure back-end.
Used in:
, ,Only one of `reference` and `value` must be set.
Can be used by modules to refer to a secret stored in a secure back-end. The `key` field is provided to permit reference to a single value within a secret containing arbitrary key-value pairs. For example, given a back-end secret store with a secret named "my-secret" containing the following key-value pairs: { "username": "my-user", "password": "my-password } the username could be referred to in a `Secret` by specifying "my-secret" for the `name` and "username" for the `key`.
Used in:
Used in:
Used to pass the value of a secret.
Used in:
* Status is used to indicate the state of the scheduler and executor driver after function calls.
* Describes the information about (pseudo) TTY that can be attached to a process running in a container.
Used in:
,Used in:
* Describes a task, similar to `TaskInfo`. `Task` is used in some of the Mesos messages found below. `Task` is used instead of `TaskInfo` if: 1) we need additional IDs, such as a specific framework, executor, or agent; or 2) we do not need the additional data, such as the command run by the task or the health checks. These additional fields may be large and unnecessary for some Mesos messages. `Task` is generally constructed from a `TaskInfo`. See protobuf::createTask.
Used in:
, ,Latest state of the task.
These fields correspond to the state and uuid of the latest status update forwarded to the master. NOTE: Either both the fields must be set or both must be unset.
Service discovery information for the task. It is not interpreted or acted upon by Mesos. It is up to a service discovery system to use this information as needed and to handle tasks without service discovery information.
Container information for the task.
Specific user under which task is running.
* Describes a group of tasks that belong to an executor. The executor will receive the task group in a single message to allow the group to be launched "atomically". NOTES: 1) `NetworkInfo` must not be set inside task's `ContainerInfo`. 2) `TaskInfo.executor` doesn't need to set. If set, it should match `LaunchGroup.executor`.
Used in:
,* A framework-generated ID to distinguish a task. The ID must remain unique while the task is active. A framework can reuse an ID _only_ if the previous task with the same ID has reached a terminal state (e.g., TASK_FINISHED, TASK_KILLED, etc.). However, reusing task IDs is strongly discouraged (MESOS-2198).
Used in:
, , , , , , , , , , , , , , , , , , , , ,* Describes a task. Passed from the scheduler all the way to an executor (see SchedulerDriver::launchTasks and Executor::launchTask). Either ExecutorInfo or CommandInfo should be set. A different executor can be used to launch this task, and subsequent tasks meant for the same executor can reuse the same ExecutorInfo struct.
Used in:
, , ,Task provided with a container will launch the container as part of this task paired with the task's CommandInfo.
A health check for the task. Implemented for executor-less command-based tasks. For tasks that specify an executor, it is the executor's responsibility to implement the health checking.
A general check for the task. Implemented for all built-in executors. For tasks that specify an executor, it is the executor's responsibility to implement checking support. Executors should (all built-in executors will) neither interpret nor act on the check's result. NOTE: Check support in built-in executors is experimental. TODO(alexr): Consider supporting multiple checks per task.
A kill policy for the task. Implemented for executor-less command-based and docker tasks. For tasks that specify an executor, it is the executor's responsibility to implement the kill policy.
Labels are free-form key value pairs which are exposed through master and agent endpoints. Labels will not be interpreted or acted upon by Mesos itself. As opposed to the data field, labels will be kept in memory on master and agent processes. Therefore, labels should be used to tag tasks with light-weight meta-data. Labels should not contain duplicate key-value pairs.
Service discovery information for the task. It is not interpreted or acted upon by Mesos. It is up to a service discovery system to use this information as needed and to handle tasks without service discovery information.
Maximum duration for task completion. If the task is non-terminal at the end of this duration, it will fail with the reason `REASON_MAX_COMPLETION_TIME_REACHED`. Mesos supports this field for executor-less tasks, and tasks that use Docker or default executors. It is the executor's responsibility to implement this, so it might not be supported by all custom executors.
* Describes a resource limitation that caused a task failure.
Used in:
, ,This field contains the resource whose limits were violated. NOTE: 'Resources' is used here because the resource may span multiple roles (e.g. `"mem(*):1;mem(role):2"`).
* Describes possible task states. IMPORTANT: Mesos assumes tasks that enter terminal states (see below) imply the task is no longer running and thus clean up any thing associated with the task (ultimately offering any resources being consumed by that task to another task).
Used in:
, , , ,Initial state. Framework status updates should not use.
The task is being launched by the executor.
NOTE: This should only be sent when the framework has the TASK_KILLING_STATE capability.
The task is being killed by the executor.
The task finished successfully on its own without external interference.
TERMINAL.
TERMINAL: The task failed to finish successfully.
TERMINAL: The task was killed by the executor.
TERMINAL: The task description contains an error.
In Mesos 1.3, this will only be sent when the framework does NOT opt-in to the PARTITION_AWARE capability. NOTE: This state is not always terminal. For example, tasks might transition from TASK_LOST to TASK_RUNNING or other states when a partitioned agent reregisters.
The task failed but can be rescheduled.
The task failed to launch because of a transient error. The task's executor never started running. Unlike TASK_ERROR, the task description is valid -- attempting to launch the task again may be successful.
TERMINAL.
The task was running on an agent that has lost contact with the master, typically due to a network failure or partition. The task may or may not still be running.
The task is no longer running. This can occur if the agent has been terminated along with all of its tasks (e.g., the host that was running the agent was rebooted). It might also occur if the task was terminated due to an agent or containerizer error, or if the task was preempted by the QoS controller in an oversubscription scenario.
TERMINAL.
The task was running on an agent that the master cannot contact; the operator has asserted that the agent has been shutdown, but this has not been directly confirmed by the master. If the operator is correct, the task is not running and this is a terminal state; if the operator is mistaken, the task may still be running and might return to RUNNING in the future.
The master has no knowledge of the task. This is typically because either (a) the master never had knowledge of the task, or (b) the master forgot about the task because it garbage collected its metadata about the task. The task may or may not still be running.
* Describes the current status of a task.
Used in:
, , , ,Possible message explaining state.
TODO(benh): Use in master/agent.
Statuses that are delivered reliably to the scheduler will include a 'uuid'. The status is considered delivered once it is acknowledged by the scheduler. Schedulers can choose to either explicitly acknowledge statuses or let the scheduler driver implicitly acknowledge (default). TODO(bmahler): This is currently overwritten in the scheduler driver and executor driver, but executors will need to set this to a valid RFC-4122 UUID if using the HTTP API.
Describes whether the task has been determined to be healthy (true) or unhealthy (false) according to the `health_check` field in `TaskInfo`.
Contains check status for the check specified in the corresponding `TaskInfo`. If no check has been specified, this field must be absent, otherwise it must be present even if the check status is not available yet. If the status update is triggered for a different reason than `REASON_TASK_CHECK_STATUS_UPDATED`, this field will contain the last known value. NOTE: A check-related task status update is triggered if and only if the value or presence of any field in `CheckStatusInfo` changes. NOTE: Check support in built-in executors is experimental.
Labels are free-form key value pairs which are exposed through master and agent endpoints. Labels will not be interpreted or acted upon by Mesos itself. As opposed to the data field, labels will be kept in memory on master and agent processes. Therefore, labels should be used to tag TaskStatus message with light-weight meta-data. Labels should not contain duplicate key-value pairs.
Container related information that is resolved dynamically such as network address.
The time (according to the master's clock) when the agent where this task was running became unreachable. This is only set on status updates for tasks running on agents that are unreachable (e.g., partitioned away from the master).
If the reason field indicates a container resource limitation, this field optionally contains additional information.
Detailed reason for the task status update. Refer to docs/task-state-reasons.md for additional explanation.
Used in:
, ,TODO(jieyu): The default value when a caller doesn't check for presence is 0 and so ideally the 0 reason is not a valid one. Since this is not used anywhere, consider removing this reason.
No longer used.
Describes the source of the task status update.
Used in:
Used in:
* Represents time since the epoch, in nanoseconds.
Used in:
, , , , ,* When the network bandwidth caps are enabled and the container is over its limit, outbound packets may be either delayed or dropped completely either because it exceeds the maximum bandwidth allocation for a single container (the cap) or because the combined network traffic of multiple containers on the host exceeds the transmit capacity of the host (the share). We can report the following statistics for each of these conditions exported directly from the Linux Traffic Control Queueing Discipline. id : name of the limiter, e.g. 'tx_bw_cap' backlog : number of packets currently delayed bytes : total bytes seen drops : number of packets dropped in total overlimits : number of packets which exceeded allocation packets : total packets seen qlen : number of packets currently queued rate_bps : throughput in bytes/sec rate_pps : throughput in packets/sec requeues : number of times a packet has been delayed due to locking or device contention issues More information on the operation of Linux Traffic Control can be found at http://www.lartc.org/lartc.html.
Used in:
* Represents a URL.
Used in:
,* Describes a UUID.
Used in:
, , , , , , , ,Used in:
* Represents an interval, from a given start time over a given duration. This interval pertains to an unavailability event, such as maintenance, and is not a generic interval.
Used in:
, , ,When added to `start`, this represents the end of the interval. If unspecified, the duration is assumed to be infinite.
* Describes an Attribute or Resource "value". A value is described using the standard protocol buffer "union" trick.
Used in:
Used in:
, ,Used in:
, , , ,Scalar values are represented using floating point. To reduce the chance of unpredictable floating point behavior due to roundoff error, Mesos only supports three decimal digits of precision for scalar resource values. That is, floating point values are converted to a fixed point format that supports three decimal digits of precision, and then converted back to floating point on output. Any additional precision in scalar resource values is discarded (via rounding).
Used in:
, ,Used in:
,Used in:
, ,* Version information of a component.
Used in:
,* Describes a volume mapping either from host to container or vice versa. Both paths can either refer to a directory or a file.
Used in:
,TODO(gyliu513): Make this as `optional` after deprecation cycle of 1.0.
Path pointing to a directory or file in the container. If the path is a relative path, it is relative to the container work directory. If the path is an absolute path, that path must already exist.
Absolute path pointing to a directory or file on the host or a path relative to the container work directory.
The source of the volume is an Image which describes a root filesystem which will be provisioned by Mesos.
Used in:
read-write.
read-only.
Describes where a volume originates from.
Used in:
Enum fields should be optional, see: MESOS-4997.
The source of the volume created by docker volume driver.
The volume/secret isolator uses the secret-fetcher module (third-party or internal) downloads the secret and makes it available at container_path.
Used in:
Driver of the volume, it can be flocker, convoy, raxrey etc.
Name of the volume.
Volume driver specific options.
Absolute path pointing to a directory or file on the host.
Used in:
Describe a path from a container's sandbox. The container can be the current container (SELF), or its parent container (PARENT). PARENT allows all child containers to share a volume from their parent container's sandbox. It'll be an error if the current container is a top level container.
Used in:
A path relative to the corresponding container's sandbox. Note that upwards traversal (i.e. ../../abc) is not allowed.
Used in:
Used in:
This must be the first enum value in this list, to ensure that if 'type' is not set, the default value is UNKNOWN. This enables enum values to be added in a backwards-compatible way. See: MESOS-4997.
TODO(gyliu513): Add IMAGE as volume source type.
* Named WeightInfo to indicate resource allocation priority between the different roles.
Used in:
,Related role name.