CLI: Add support for using Configs as CredentialSpecs in services

[thaJeztah]

depends on moby/moby#38672moby/moby#38632 (using a temporary vendoring), and built on top of #1655 (which isn't merged yet)

• Improve validation of credential_spec in compose schema (I'll split that to a separate PR as well)
• Add compose schema 3.8
• Add config as option in credential_spec

[thaJeztah]

ping @dperny@vdemeester@tiborvass PTAL

[thaJeztah]

split the compose-file validation for older versions to #1657

[codecov-io]

Codecov Report

Merging #1656 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@ Coverage Diff @@## master #1656 +/- ##
==========================================
+ Coverage 56.26% 56.34% +0.07% 
==========================================
Files 308 308 Lines 21293 21306 +13 ==========================================
+ Hits 11980 12004 +24 + Misses 8439 8428 -11 
Partials 874 874

[simonferquel]

Should'nt credentials be stored as Secret objects more than Configs ?

[thaJeztah]

IIUC, the content of the credentials-spec doesn't contain sensitive data (implementation-wise, it wouldn't make a big difference currently, as both are encrypted and use the same storage)

…

On 4 Feb 2019, at 10:31, Simon Ferquel ***@***.***> wrote: Should'nt credentials be stored as Secret objects more than Configs ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[simonferquel]

Aside from the temporary vendoring, seems good to me then (might require some squashing as well)

[thaJeztah]

Thx! only the last two commits are new in this PR, other commits will disappear once the related PR's are merged

[silvin-lubecki]

LGTM, just requesting changes to prevent merging it until the moby PR is merged.

[vdemeester]

@thaJeztah needs a PR and some updates ?

[thaJeztah]

Rebased on top of #1700, but there's still discussion about the current implementation in moby, so let's hold off merging this until that's in moby/moby#38777 (comment)

/cc @ddebroy@dperny@wk8

[dperny]

Final implementation for CredentialSpecs through swarm configs is done, so this can move forward.

The implementation of this feature requires two things: the Config needs to be in the ConfigReferences for the service, and the Config used for the CredentialSpec needs to be specified by ID, not by name.

Because ConfigReferences already must include the ConfigID, the logic we use to fill in that field should be used in turn to fill in the CredentialSpec field in the Service object appropriately. My vision of the CLI is to have this flag:

--credential-spec config://my-config-name

turn into these objects:

// assume the existence of some function `resolveConfigID(string) string`// which takes a config name and returns its IDcredentialSpec:=&swarm.CredentialSpec{
Config: resolveConfigID(strings.TrimPrefix(value, "config://")),
}

funcaddCredentialSpecConfig(spec*swarm.ServiceSpec, c*swarm.Config) {
spec.TaskTemplate.ContainerSpec.Configs=append(spec.TaskTemplate.ContainerSpec.Configs,
&swarm.ConfigReference{
Runtime: &swarm.ConfigReferenceRuntimeTarget{},
ConfigID: c.ID,
ConfigName: c.Name,
},
)
}

[dperny]

I'm going to pull down @thaJeztah's branch and make these changes myself.