Skip to content

Conversation

@thomasgl-orange
Copy link
Contributor

This is not a PR! (yet)

Hi there,

I've started implementing a binding class for Docker client certificates. Now, I'm wondering, where should the code go? I've thought I should ask before spending to much time in the wrong code repository...

Options 1: add optional dependency from credentials-binding to docker-commons, and the new binding impl in credentials-binding. Same as what is proposed for SSH keys in #18, and also what I did so far in my prototype code.

Options 2: implement new bindings as optional extensions in the plugins which provides the corresponding credentials type (docker-commons, ssh-credentials), with optional dependencies from these plugins to credentials-binding.

To me, option 2 sounds better in the long term. It would avoid having one plugin with many optional dependencies, if many credentials type were to appear in the future. It also seems close to what would be the obvious choice if credentials binding was simply a standard feature of the main credentials plugin.
What do you think/prefer?

Thanks,
Thomas.

@thomasgl-orange thomasgl-orange force-pushed the feature/docker-credentials branch 2 times, most recently from fdb6714 to 14ad622 Compare September 9, 2016 08:23
@thomasgl-orange thomasgl-orange force-pushed the feature/docker-credentials branch from 14ad622 to 06398bf Compare September 9, 2016 13:43
@jglick
Copy link
Member

jglick commented Sep 9, 2016

I would suggest just having a hard (not optional) dependency on credentials-binding in “domain” plugins like docker-commons.

@thomasgl-orange
Copy link
Contributor Author

Thanks Jesse for your suggestion. I think you're right. I'll close this PR, replaced it by:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants