Skip to content

GetPluginInfoRequest: clarify rules around name field #3

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

Closed
jdef opened this issue May 23, 2017 · 9 comments
Closed

GetPluginInfoRequest: clarify rules around name field #3

jdef opened this issue May 23, 2017 · 9 comments

Comments

@jdef
Copy link
Member

jdef commented May 23, 2017

via @saad-ali

Plugin Naming:

  1. Plugin claiming to be someone else? Shouldn't be solved here.
  2. preventing collisions: namespaced
    Should be a domain that you own.
    CO should verify the plugin.
    Name should contain domain: com.google.com/GCEPD?
@jdef jdef changed the title GetPluginInfo: clarify rules around name field GetPluginInfoRequest: clarify rules around name field May 23, 2017
jdef referenced this issue in chhsia0/mesos May 25, 2017
saad-ali added a commit to saad-ali/spec that referenced this issue Aug 21, 2017
@jsafrane
Copy link
Contributor

In addition, COs that support multiple CSI plugins need to store this name along the VolumeInfo. It can't be random Unicode junk, it should have defined components (dns labels + dots + slashes?) and limited size (as small as possible, 64 characters would be nice).

github.com/cool-project/csi, super.vendor.com/awesome-storage and so on.

@akutz
Copy link
Contributor

akutz commented Oct 26, 2017

It's not the place of the specification to manage unique plug-in names. At best plug-ins can follow the SUN naming convention. In the future there will likely need to be some registry for CSI plug-ins in order to assist with picking unique names. Even then, however, there is nothing, and should be nothing, to prevent a developer from picking any name they wish. It's up to them to ensure that their plug-in can be distributed and consumed. At that point they can follow the SUN naming convention and/or check with some registry that is used to track well-known plug-ins. I imagine a WIKI (perhaps on this repo) or some such other central knowledge base will be used to track these plug-ins.

@cpuguy83
Copy link
Contributor

Plugin naming is really even up to the cluster admin, not the plugin developer.

@akutz
Copy link
Contributor

akutz commented Oct 26, 2017

Hi @cpuguy83,

Plugin naming is really even up to the cluster admin, not the plugin developer.

I'm not sure I agree with the above statement. In the case of Docker managed plug-ins, the plug-in name is set during the packaging/build step. But at least this is declarative -- that is the name lives outside the code. The CSI model, depending on the implementation, will very likely result in some string defined as code informing the plug-in name referred to by this issue. I suppose that could relate to some EnvVar, but still.

Perhaps I'm misunderstanding you or missing something? Otherwise I do not think I'm able to agree with your statement regarding the cluster admin.

@cpuguy83
Copy link
Contributor

@akutz In docker it's still declared by the admin, though the default name comes from the repository URL: docker plugin install --alias foo cpuguy83/foo, the plugin would be named the alias.

@akutz
Copy link
Contributor

akutz commented Oct 26, 2017

Is the alias a new feature of plugin install? If so, that’s nice. We were greatly frustrated at the beginning where in order to have two instances with diff Configs you basically had to rebuild with a new ID.

@cpuguy83
Copy link
Contributor

cpuguy83 commented Oct 26, 2017 via email

@akutz
Copy link
Contributor

akutz commented Oct 26, 2017

0c4694ca-20e2-40a3-bbb7-30d837f99469

edisonxiang added a commit to edisonxiang/spec that referenced this issue Nov 16, 2017
The plugin name will be passed in through CO's
APIs by the users to refer to the plugin.
CSI should clarify the plugin name rules.
This patch sepecifies the name in Reverse domain
name notation format.

Resolves: container-storage-interface#145, container-storage-interface#3
@saad-ali
Copy link
Member

Closed with #149

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

No branches or pull requests

5 participants