-
Notifications
You must be signed in to change notification settings - Fork 2.1k
CLI: Add support for using Configs as CredentialSpecs in services #1656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
ping @dperny @vdemeester @tiborvass PTAL |
|
split the compose-file validation for older versions to #1657 |
cdbc6d0 to
e126e9f
Compare
Codecov Report
@@ 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 |
|
Should'nt credentials be stored as Secret objects more than Configs ? |
|
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
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the temporary vendoring, seems good to me then (might require some squashing as well)
|
Thx! only the last two commits are new in this PR, other commits will disappear once the related PR's are merged |
silvin-lubecki
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just requesting changes to prevent merging it until the moby PR is merged.
e126e9f to
e453d10
Compare
|
@thaJeztah needs a PR and some updates ? |
e453d10 to
205b260
Compare
|
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) |
This comment has been minimized.
This comment has been minimized.
205b260 to
6bab2be
Compare
Signed-off-by: Sebastiaan van Stijn <[email protected]>
6bab2be to
8bceb88
Compare
|
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: turn into these objects: // assume the existence of some function `resolveConfigID(string) string`
// which takes a config name and returns its ID
credentialSpec := &swarm.CredentialSpec{
Config: resolveConfigID(strings.TrimPrefix(value, "config://")),
}func addCredentialSpecConfig(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,
},
)
} |
|
I'm going to pull down @thaJeztah's branch and make these changes myself. |
depends on
moby/moby#38672moby/moby#38632 (using a temporary vendoring),and built on top of #1655 (which isn't merged yet)configas option in credential_spec