GetPluginInfoRequest: clarify rules around name field

[jdef]

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?

[jsafrane]

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]

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]

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

[akutz]

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]

@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]

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]

I want to say 1.13? Ever since they went non-experimental.

…

On Thu, Oct 26, 2017 at 5:10 PM, Schley Andrew Kutz < ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwxZh3epPJCugE88YpmYWNA5riw6hUYks5swPUngaJpZM4NjFtE> .

-- - Brian Goff

[akutz]

[saad-ali]

Closed with #149