Skip to content
This repository has been archived by the owner on Mar 26, 2020. It is now read-only.

RFE: Label based snapshot #1094

Open
rafikc30 opened this issue Jul 30, 2018 · 5 comments
Open

RFE: Label based snapshot #1094

rafikc30 opened this issue Jul 30, 2018 · 5 comments

Comments

@rafikc30
Copy link
Member

It is very helpful if there is a way to tag snapshots with labels. This allows us to schedule snapshot operations better. Also make easy to manage snapshots based on labels

@rafikc30
Copy link
Member Author

rafikc30 commented Sep 6, 2018

Labels

Labels are a unique independent entity that can be used to tag an object. With the help of labels, we can group objects and perform different operations based on configuration values stored in the labels.

What are the Rest endpoints it supports

  1. Label create
  2. Label list
  3. Label Info
  4. Label set --> allow us to modify label configuration values
  5. Label reset --> It will reset configuration values to its default value

Where Can we use labels

The first consumer of labels will be Snapshot. We can use labels to list snapshot, delete the snapshot and perform other high-level actions.

For example, In a customer setup, a snapshot can schedule based on different labels like Monthly, Hourly, Yearly, Daily etc. Each one of this can have different configuration values. In a typical set up, the maximum number of a snapshot for the Hourly label can set to 24, while the same value will be 12 for the Monthly snapshot. So performing auto-delete based on this max values will be based on label values.

Snapshot Based Geo-replication

Labels are the first pre-requisite for Snapshot Based Geo-replication . To implement the feature we need to create an internal snapshot in a shorter interval, and the auto-delete should be true as well as the max snapshot count should be minimal. We cannot use a default value for this snapshots.

@rafikc30
Copy link
Member Author

rafikc30 commented Sep 6, 2018

@rafikc30
Copy link
Member Author

rafikc30 commented Sep 7, 2018

Moving the discussion from PR #1228.
The requirement from a snapshot perspective is very simple. Snapshot feature requires to have multiple configuration values for the different group of snapshots. Based on this values, snapshot commands behave differently. For example, if snapshots are taken for geo-replication, then it has to do automatic activation during snapshot creation, also after a certain number of snapshots, further creation should delete old snapshots. But this limit will be different from a general purpose snapshot.

This kind of actions are not triggered by a scheduler or a plugin but as part of a snapshot command. I'm not able to understand how a key-value pair can solve this.

I have not thought about any use case for other commands., My intention behind implementing it as a generic command was to make it available for other commands like volume. But I can implement this as part of snapshot endpoints.

@prashanthpai
Copy link
Contributor

For example, if snapshots are taken for geo-replication, then it has to do automatic activation during snapshot creation, also after a certain number of snapshots, further creation should delete old snapshots

This can be part of snapshot and/or georep API.

This kind of actions are not triggered by a scheduler or a plugin but as part of a snapshot command. I'm not able to understand how a key-value pair can solve this.

When you say "autodelete", usually there is someone (a separate process or thread in gd2 or a goroutine) who does the deletion. That someone has to know about when and what action to take. This information has to be stored somewhere. Depending on who this entity is, one place to store this information is metadata.

As you pointed out, in your usecase, all actions happen only when a command is issued. This wasn't clear earlier. If it's part of a synchronous command initiated by client/user, it can be part of the normal snapshot/georep API.

I have not thought about any use case for other commands., My intention behind implementing it as a generic command was to make it available for other commands like volume. But I can implement this as part of snapshot endpoints.

I'd prefer that, unless you can justify how labels can be used for usecases beyond snapshot.

@rafikc30
Copy link
Member Author

rafikc30 commented Sep 7, 2018

I have not thought about any use case for other commands., My intention behind implementing it as a generic command was to make it available for other commands like volume. But I can implement this as part of snapshot endpoints.

I'd prefer that, unless you can justify how labels can be used for usecases beyond snapshot.

Okay. At the moment, I can't think of any use case other than snapshot. I will resubmit the patch, moving it to the snapshot endpoints .

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

No branches or pull requests

3 participants