-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
CLI: Add support for using Configs as CredentialSpecs in services #1656
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.
|
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 |
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 <github@gone.nl>
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)config
as option in credential_spec