Releases: mesosphere/dcos-commons
0.58.0 Log4J CVE-2021-44228
This is a patch release on v0.58.0 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.56.0 Log4J CVE-2021-44228
This is a patch release on v0.56.0 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
- Use release version of
mesos:1.8.0instead ofSNAPSHOT
0.55.4 Log4J CVE-2021-44228
This is a patch release on v0.55.4 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.55.2 Log4J CVE-2021-44228
This is a patch release on v0.55.2 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.57.3 Log4J CVE-2021-44228
This is a patch release on v0.57.3 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.57.2 Log4J CVE-2021-44228
This is a patch release on v0.57.2 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.57.0 Log4J CVE-2021-44228
This is a patch release on v0.57.0 to mitigate the Log4J CVE-2021-44228
- Bump Log4J versions to 2.16.0
0.58.0
Automatic Pod-Replacement
This release of the SDK introduces automatic-pod replacement. It is suggested to use an automatic pod-replacement failure policy with external-storage as rebuilding data associated with a pod isn't expected to be as expensive as compared to equivalent ROOT or MOUNT volumes.
Note: When enabled, automatic pod replacement applies across the service and not just a single pod type.
Replacement Failure Policy
Services implementing automatic pod replacement must specify the Replacement Failure Policy for tasks declared as permanently failing. The Replacement Failure Policy is constructed and passed to a Service Spec in a programmatic way as part of the scheduler's implementation.
Cassandra example:
Replacement Failure Policy cannot be defined in a YAML service specification.
Vertical bursting support
Previously, sidecar tasks (such as running Cassandra nodetool repair) were able to consume memory and cpu resources from the primary task. This is because Mesos previously launched all tasks in to a single cgroups. SDK v0.58.0 will instruct Mesos to launch all tasks in separate cgroups. This means that if a sidecar task actually needs more memory than that which it specifically requests, and no configuration is changed, the sidecar task will get OOM killed.
To remedy this, all frameworks should update their service specs so that ultimately the resource-limits for both the primary data service task, and side-car tasks, can be defined. Further, the templates in the Universe should expose appropriate configuration parameters so that bursting for both can be defined.
Tasks can be configured to optional consume more than they request.
With resource-limits, a task can be configured to consume more CPU or Memory than that which is requested and reserved. This is fantastic news for data-services that would permanently set aside an entire CPU so that occassional backup or repair side-car tasks can be run. To repeat a point made before, SDK service templates should expose appropriate configuration parameters so that resource-limits can be set, at the very least, for sidecar tasks.
Instead of Cassandra requiring 1 CPU for a sidecar tasks, it could instead set aside 0.1 CPU, and then set a resource limit of up to 2 CPUs. This will allow the task to run fast when their are leftover resources to run them, and leave CPUs available to service time-sensitive API requests.
This feature is opt-in, enable it by adding resource limits to your Service Spec.
PR (#3231)
Support external volumes
Cassandra example:
This feature is opt-in, enable it by adding external volumes to your Service Spec.
Design document (#3266)
0.58.0-rc3
Changes
Allowed values for External Volume Driver Name
This release will not allow any arbitrary values to be passed in the driver-name. The only accepted values are pxd for Portworx Driver and netapp for NetApp Driver.
Default External Volume Name
The naming scheme for the external volume differs for both supported drivers. Whereas, for the Portworx, the naming scheme is the same as defined in the previous release. But for the NetApp, since it does not support the hyphen - in the external volume name, so it would be replaced by the underscore _.
The SDK will now use the following scheme for external volume-name in case of the NetApp driver, where none is specified by the operator:
<svc-name> _ <pod-type> _ <pod-index>
<svc-name>: Sanitized service path with slashes/replaced to double underscore__<pod-type>: Pod-type<pod-index>: Pod-index
As an example, instances of pod type foo in service /path/to/service will be created with the following external volumes:
path__to__service_foo_1
path__to__service_foo_2
v0.58.0-rc2
Changes
Automatic Pod-Replacement
This release of the SDK introduces automatic-pod replacement. It is suggested to use an automatic pod-replacement failure policy with external-storage as rebuilding data associated with a pod isn't expected to be as expensive as compared to equivalent ROOT or MOUNT volumes.
Note: When enabled, automatic pod replacement applies across the service and not just a single pod type.
Replacement Failure Policy
Services implementing automatic pod replacement must specify the Replacement Failure Policy for tasks declared as permanently failing. The Replacement Failure Policy is constructed and passed to a Service Spec in a programmatic way as part of the scheduler's implementation.
Cassandra example:
Replacement Failure Policy cannot be defined in a YAML service specification.
Default External Volume Name
The release of the SDK makes updates the naming scheme for external volumes, this applies for cases where the operator has not explicitly specified external volume name to use.
The SDK will now use the following scheme for external-volume names where none is specified by the operator:
<svc-name>-<pod-type>-<pod-index>
-<svc-name> : Sanitized service path with slashes / replaced to double underscore __
-<pod-type> : Pod-type
-<pod-index> : Pod-index
As an example, instances of pod type foo in service /path/to/service will be created with the following external volumes:
path__to__service-foo-1
path__to__service-foo-2
If the operator explicitly specifies an external volume name of ServiceVolume, the following external volumes will be created:
ServiceVolume-1
ServiceVolume-2