Skip to content

spec: Add tags to VolumeInfo #118

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

Conversation

akutz
Copy link
Contributor

@akutz akutz commented Oct 4, 2017

This patch adds an optional field tags to VolumeInfo. The tags field is a map[string]string and can contain additional attributes related to a volume.

Related to #116, #117. cc/ @saad-ali @jieyu

This patch adds an optional field "tags" to "VolumeInfo". The "tags"
field is a "map[string]string" and can contain additional attributes
related to a volume.
@akutz akutz force-pushed the feature/vol-info-tags branch from a9e8f11 to dfd7c78 Compare October 4, 2017 22:59
@akutz akutz changed the title Add tags to VolumeInfo spec: Add tags to VolumeInfo Oct 4, 2017
@saad-ali
Copy link
Member

saad-ali commented Oct 4, 2017

This looks mostly fine to me. It does complicate VolumeInfo in that it adds a field that should be populated on responses but should not be present on requests. Wondering if there is anything we could do to make that cleaner, but I do like having essentially a single object that captures all volume attributes. So I'm not sure.

@akutz
Copy link
Contributor Author

akutz commented Oct 4, 2017

Hi Saad,

I’d argue that the validate volume caps doesn’t need the volume info obj anyway, only the handle it contains. Why not just update the validate rpc to use the handle directly?

@saad-ali
Copy link
Member

saad-ali commented Oct 4, 2017

Good point. I would support replacing VolumeInfo with id in ValidateVolumeCapabilities along with this change.

@akutz
Copy link
Contributor Author

akutz commented Oct 4, 2017

Cool. I’ll update the PR with this change when I return to my desk.

@jdef
Copy link
Member

jdef commented Oct 30, 2017

Are tags stable over time, or do they have a TTL? How are these different than metadata, other than the fact that they're not passed back into the plugin for publish/validation calls?

@jdef
Copy link
Member

jdef commented Feb 22, 2018

There are no concrete use cases for this, so I'm closing it out. We can revisit later if needed. If you disagree, please re-open for comment.

@jdef jdef closed this Feb 22, 2018
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.

3 participants