Repository files navigation

Provides an API for theorderly, harmonious, and completemanagement of DC/OS service packages.

Teamcity CI :Build & Compile andIntegration Tests

• Running tests
  • Scala style checks
  • Unit Tests
    • Scoverage
  • Integration Tests
    • Scoverage
    • Requirements
    • Running the tests
      • Example configurations
• Running Cosmos
  • Cosmos Admin Portal
• Project structure
  • RPC Conventions
• Versions & Compatibility
  • DC/OS
  • Universe
    • Repository Format
    • Packaging Version
• API Documentation
  • Cosmos Version 0.3.x
• Reporting Problems

This project enforces certain scalastyle rules. To run those check against the code run:

sbt scalastyle

There is a suite of unit tests that can be ran by runningsbt clean test:test

To generate anscoverage report for unittests run the following command:

sbt clean coverage test:test coverageReport coverageAggregate

The generated report can then be found attarget/scala-2.12/scoverage-report/index.html

NOTE: You should never run coverage at the same time as one-jar because the produced one-jar willcontains scoverage instrumented class files and will fail to run.

There is a suite of integration tests that can be ran by runningsbt clean it:test

At this time it is not possible to easily generate an scoverage report for the integration suiteincosmos-server. This is due to some classpath scoping issues related to the cosmos serverbeing forked before the integration suite is ran.

• A running DC/OS cluster

The integration tests support three ways of configuring the tests. This is done using the followingsystem properties:

1. com.mesosphere.cosmos.dcosUri - Location of the DC/OS cluster as an HTTP URL.
2. com.mesosphere.cosmos.boot - Iftrue or undefined the integration tests will automaticallyexecute the Cosmos defined in this repository. Iffalse then the integration tests will notexecute a Cosmos.
3. com.mesosphere.cosmos.test.CosmosIntegrationTestClient.CosmosClient.uri - This property is notrequired. If set to a URL, it will override the default value. The integration tests assume thatthe Cosmos described in this system property is configured to control the same cluster described incom.mesosphere.cosmos.dcosUri

1. Run the integration tests against the Cosmos implemented in this repo. This is done byautomatically starting an in process ZooKeeper cluster and a Cosmos server that controls a DC/OScluster. This configuration can be enabled by setting thecom.mesosphere.cosmos.dcosUrisystem property.

export COSMOS_AUTHORIZATION_HEADER="token=$(http --ignore-stdin<dcos-host-url>/acs/api/v1/auth/login uid=<dcos-user> password=<user-password>| jq -r".token")"sbt -Dcom.mesosphere.cosmos.dcosUri=<dcos-host-url> \    clean it:test

2. Run the integration tests against the Cosmos running in a DC/OS cluster. This configuration canbe enabled by setting thecom.mesosphere.cosmos.dcosUri andcom.mesosphere.cosmos.boot=falsesystem properties.

export COSMOS_AUTHORIZATION_HEADER="token=$(http --ignore-stdin<dcos-host-url>/acs/api/v1/auth/login uid=<dcos-user> password=<user-password>| jq -r".token")"sbt -Dcom.mesosphere.cosmos.dcosUri=<dcos-host-url> \    -Dcom.mesosphere.cosmos.boot=false \    clean it:test

3. Run the integration tests against a Cosmos already configured to control a DC/OS cluster. Thisconfiguration can be enabled by setting thecom.mesosphere.cosmos.dcosUri,com.mesosphere.cosmos.boot=false andcom.mesosphere.cosmos.test.CosmosIntegrationTestClient.CosmosClient.uri system properties.

export COSMOS_AUTHORIZATION_HEADER="token=$(http --ignore-stdin<dcos-host-url>/acs/api/v1/auth/login uid=<dcos-user> password=<user-password>| jq -r".token")"sbt -Dcom.mesosphere.cosmos.dcosUri=<dcos-host-url> \    -Dcom.mesosphere.cosmos.boot=false \    -Dcom.mesosphere.cosmos.test.CosmosIntegrationTestClient.CosmosClient.uri=http://localhost:7070 \    clean it:test

To run a single test, something like the following can be used in the sbt console:

# to run a single test suiteit:testOnly*ServiceUpdateSpec# To run a single test from a single suiteit:testOnly*ServiceUpdateSpec -- -z"user should be able to update a service via custom manager"

Cosmos requires a ZooKeeper instance to be available. It looks for one atzk://localhost:2181/cosmos by default; to override with an alternate<zk-uri>, specify the flag-com.mesosphere.cosmos.zookeeperUri <zk-uri> on the command line when starting Cosmos (seebelow).

We also need a One-JAR to run Cosmos:

sbt oneJar

The jar will be created in thecosmos-server/target/scala-2.12/ directory. This can be executedwith:

java -jar cosmos-server/target/scala-2.12/cosmos-server_2.12-<version>-SNAPSHOT-one-jar.jar \     -com.mesosphere.cosmos.dcosUri<dcos-host-url>

It can also be executed with ZooKeeper authentication with:

export ZOOKEEPER_USER<user>export ZOOKEEPER_SECRET<secret>java -jar cosmos-server/target/scala-2.12/cosmos-server_2.12-<version>-SNAPSHOT-one-jar.jar \     -com.mesosphere.cosmos.dcosUri<dcos-host-url>

Cosmos exposes an admin portal athttp://<cosmos-host>:9990/admin. If Cosmos is running locallyand you are just interested in the metrics run the following command.

curl http://localhost:9990/admin/metrics.json

The code is organized into several subprojects, each of which has a JAR published to theSonatype OSS repository. Here's an overview:

• cosmos-test-common
  • src/main directory: defines the code and resources used by both the unit and integrationtests.
  • src/test directory: defines the unit tests and any resources they require.
• cosmos-integration-tests
  • src/main directory: defines the integration tests and any resources they require.
• The remaining subprojects define the main code for Cosmos, always within theirsrc/maindirectories.

All the list of RPCs that cosmos supports are located incom/mesosphere/cosmos/rpc package in thecosmos-common module. The RPC's are structured according to their version likev1,v2 and so on.Ascosmos grows, only the two most recent versions of rpc will be supported. Every time a new rpc isadded, the oldest rpc will be removed if there are more than two versions. In essence, this meansthat the tail version should always be considered as deprecated.

The following table outlines which version of Cosmos is bundled with each version of DC/OS

The below table is a compatibility matrix between Cosmos and Universe repository consumptionformat.

Rows represent Cosmos versions, columns represent repository formats.

The below table is a compatibility matrix between Cosmos and Universe packaging versions.

Rows represent Cosmos versions, columns represent packaging versions.

The tooling for packaging docs is atmesosphere/packaging-docs

If you encounter a problem that seems to be related to a Cosmos bug, please create an issue atDC/OS Jira. To create an issue click on theCreate button at the top and addcosmos to the component field.