v0.57.0-rc2

This release candidate has all the features from the previous release with the following updates.

Shared Hierarchial Memory Support (#3123)

• The ServiceSpec fields for shared-memory and shared-memory-size have changed to ipc-mode and shm-size respectively.
• The example ServiceSpec for SHM reflects this change.

Quota Support (#3102)

• This feature requires support for enforceRole on Marathon groups found in Marathon v1.9.30 and later.
• Development configuration options from the previous release have been removed as Marathon now provides this value.

By default Marathon does not set enforceRole=true on group creation, and existing semantics are maintained.

Deploy new service in a group with quota enabled

Hello-World is used in the example below but this is applicable to any SDK based service.
To create a service named /dev/hello-world in group dev with quota consumed from role dev

1. Create a group with enforceRole:

cat >create-group.json<<EOF
{
    "id":"/dev",
    "enforceRole":true
}
EOF

2. Create Marathon group:

dcos marathon group add create-group.json

3. Populate the service options:

cat >hello-world-dev-options.json<<EOF
{
    "service":{
        "name":"/dev/hello-world"
    }
}
EOF

NOTE the leading slash on the service-name is required. (i.e "name":"dev/hello-world") will not work.
4. Install service.

dcos package install hello-world --options=namespace-options-foo-enforce-role.json --yes

5. Ensure SDK scheduler and pods have been launched under the dev role via Mesos UI.

Migrate an existing deployed service to use quota support

To upgrade an existing service to a new version of the SDK with quota support, use the following procedure.
We will use Hello-World again pre-installed in group foo in the example below but this is applicable to any SDK based service.

1. Update Marathon group to enforce roles.

dcos marathon group update /foo enforceRole=true

2. Specify any additional upgrade options (in this case nothing)
   Create a file with the current service-name.

cat >hello-world-foo-options.json<<EOF
{
    "service":{
        "name":"/foo/hello-world"
    }
}
EOF

3. Upgrade the scheduler to use the group role.

dcos hello-world --name="/foo/hello-world" update start --options=hello-world-foo-options.json.json

4. At this point the scheduler will be upgraded and will use quota from the foo role. The deployed pods will be unaffected and will use their previous roles.
5. Issue pod replace commands as necessary to migrate the footprint to the new group role quota.

dcos hello-world --name="/foo/hello-world" pod replace hello-0

The hello-0 pod will be migrated to consume quota from foo

Strict Mode Clusters

For strict mode clusters, additional role permissions are required and must be setup before deploying the service.
Services in groups with enforceRole=true will need to provide create access to the role corresponding with their group.

Example:

• Service with name /dev/hello-world will need permissions to the dev role and the existing dev__hello-world-role

dcos security org users grant <service-account> dcos:mesos:master:reservation:role:dev create
dcos security org users grant <service-account> dcos:mesos:master:reservation:role:dev__hello-world-role create

Pod Pre-Reserved Roles

For pods which specify pre-reserved roles (eg slave_public), the scheduler will issue a hierarhical role depending on the value of enforceRole on its service group.

Example:

• Pod Pre-Reserved Role: slave_public and enforceRole=false. These permissions are required:

dcos security org users grant <service-account> dcos:mesos:master:reservation:role:slave_public/dev__hello-world-role create

• Pod Pre-Reserved Role: slave_public and enforceRole=true. These permissions are required:

dcos security org users grant <service-account> dcos:mesos:master:reservation:role:slave_public/dev create

When performing migration between legacy to enforced group roles, both permissions above will be required.