Distribution: Storage driver: Manta

[tgross]

Joyent's Manta object store is available both on Triton Cloud (Joyent's public cloud) and for on-premise users of Triton. Triton implements the Docker Remote API so that end-users can deploy Docker container images pulled from the Docker Hub or a private Docker registry. I'd like to propose (and contribute) a Manta storage driver so that Triton users can host a private registry and keep their images entirely within their own data center.

Manta has a REST API somewhat similar to that of AWS S3. It differs in that Manta has a filesystem-like interface (directories, objects, links), read-after-write consistency, and per-object replication tuning.

Configuration

The proposed configuration is as follows:

storage:
    manta:
        mantaUrl: https://us-east-manta.joyent.com
        mantaAccount: registryUsername
        keyId: aa:bb:cc:dd:ee:ff:11:22:33:44:55:66:77:88:99:00
        privateKey: ~/path/to/private/key.pem
        algo: rsa-sha256
        root: /stor/<account>/registry
        version: 1

• mantaUrl (required): the Manta endpoint URL (there are multiple Joyent-hosted endpoints and on-prem customers can enter their own domains here). There is no insecure URL.
• mantaAccount (required): the Manta user account that the registry will use to interact with Manta.
• keyId (required): the MD5 key ID of the SSH key associated with the account the registry will use.
• privateKey (required): the private key of the SSH key associated with the account the registry will use.
• algo (optional): the algorithm used for signing requests to Manta. Currently only rsa-sha256 is supported but this field is included as an optional with a default so that new algorithms can be added without breaking compatibility.
• root (required): the root directory on Manta where images will be stored.

The configuration includes a user account which should be a dedicated account for the registry with only the permissions required. This is not the same user that the Docker client will use to authenticate to the registry (which can be via any auth driver, although our own sdc-docker is currently compatible with htpassword only). See the Joyent REST API Authentication docs.

Implementation

There is an existing client library joyent/gomanta which is maintained by Joyent. It uses joyent/gocommon and joyent/gosign under the hood. These libraries are well-tested in a Triton provider for Hashicorp's Terraform. The implementation will closely mirror the AWS S3 implementation, swapping out the library calls where appropriate.

Misc

The gomanta library includes a localservices subpackage that can be used for integration testing on CircleCI. Joyent will be able to commit to maintaining this contribution in the future; Manta is an important pillar of our work so we want to ensure that Docker users can take full advantage of it.

[stevvooe]

@tgross This looks like a very complete proposal. Thank you!

A few items:

1. Do you have a PR?
2. How will it be tested by our CI system?
3. Who will maintain the driver?

While we want the registry to be deployable in a number of environments, we want to ensure that issues get answered in a reasonable amount of time. It would be good to ensure that you or someone else can guarantee that they will be available for ongoing maintenance such that future changes to the registry can be made with confidence. It sounds like Joyent is offering this, but I want to make sure this is clear. ;)

My only other worry is the copyleft nature of the license of joyent/gomanta. I'm not sure what we need to do to ensure we are complying with the MPL.

(PS For the configuration format, please match the conventions of the existing options. We don't use camelCase and try to match the option names with other similar options (like the key file, for instance)

Anywho, I look forward to getting something like this in and appreciate the complete proposal.

[tgross]

Do you have a PR?

Not yet. I ran into a snag inasmuch as Manta apparently doesn't yet support multi-part uploads. Trying to hack this into the client was going to be an awful lot of work given that Manta will support multi-part uploads very soon (RFD65 should be shipping within the next month or two). Additionally, the Joyent golang SDK is getting a bit of a rework as triton-go, which is currently a private repo, so I wanted to wait until that API settled out as well.

How will it be tested by our CI system?

There is a localservices mock package that ships with the driver that can be used for integration testing on CircleCI. If necessary, Joyent will be happy to provide access to Manta on the public cloud for testing purposes as well.

Who will maintain the driver?

That would be me or other members of the product engineering team at Joyent. At this time I'd definitely be the first line of contact.

My only other worry is the copyleft nature of the license of joyent/gomanta. I'm not sure what we need to do to ensure we are complying with the MPL.

I know that the MPL2.0 was specifically designed to help out compatibility with other licenses, but I'm fuzzy on the details myself. The in-progress triton-go library I mentioned above hasn't been licensed yet, so maybe I can convince our team that Apache licenses (or dual licensing) would be better for our SDKs. Lemme circle back on that.

[misterbisson]

Typical IANAL, but there are some FAQ answers regarding MPL that might help one of the questions above.

From https://www.mozilla.org/en-US/MPL/2.0/FAQ/:

The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions.

How does the scope of the MPL's copyleft compare with the LGPL and GPL's copyleft?

Broadly speaking, the scope of the MPL, LGPL, and GPL can be summarized this way:

• MPL: The copyleft applies to any files containing MPLed code.
• LGPL: The copyleft applies to any library based on LGPLed code.
• GPL: The copyleft applies to all software based on GPLed code.

IANAL, but the license covers individual files.

How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?

No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.

And section 1.10 of the license, explaining "modifications" from the above:

1.10. “Modifications”

means any of the following:

1. any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or

2. any new file in Source Code Form that contains any Covered Software.

Again, IANAL, but "modifications" is limited to modifications of specific files licensed under the MPL.