[FSunstone] Labels rework

[vichansson]

Description

• We also need a guide such as this whenever this is implemented.

Currently in FireEdge Sunstone, there is no distinction between user defined and system defined labels. That is, even if you create a new label for a user, it will be stored under the user template. But then if you apply the label to a resource, the label get's stored directly on the resource, thus turning it into a system label and so anyone with access to that resource, will subsequently also see that same USER defined label.

For this we need a clear distinction between the two types of labels.

System Labels

• Should be user-independent, and stored directly on the resource template

User Labels

• Stored on the user template
• Holds a pointer record configuration as to which resources each individual label is being applied to

The oneadmin user should also be able to configure this behavior in the fireedge configuration file, wether user and system labels should be kept separately, or if other users will be able to see each others labels. For this we need some additional metadata about each label, who created it, when was it added, unique identifiers and so on...

Assume this configuration option is called GLOBAL_LABELS

Example 1: Global Labels is set to false

Here in the LABELS configuration, each object, represents a label, where the key is a UUID and the value tied to that UUID is the label metadata, consisting of the name and labelcreated timestamps. Then in the "lookup" table, or LABEL_CONFIG map, each applied label is stored under the respective resource, where the key, in the first layer, consists of the resource ID and then contains an array of LABELS, where each object is made up of the UUID and a timestamp for when the label was added to that resource.

Example:

{
  "LABELS": {
    "uuid1": {
      "name": "Testing",
      "labelcreated": 1688880000
    },
    "uuid2": {
      "name": "Production",
      "labelcreated": 1688883600
    },
    "uuid3": {
      "name": "Development",
      "labelcreated": 1688887200
    }
  },
  "LABEL_CONFIG": {
    "VM_TEMPLATES": {
      "0": [
        { "uuid1": 1688894400 }
      ]
    },
    "VMS": {
      "1": [
        { "uuid2": 1688898000 },
        { "uuid3": 1688901600 }
      ]
    }
  }
}

This allows for quick lookups between user defined labels and resources. So when rendering the labels for a VM template for example, you extract all keys under that resource's ID, and then simply look them up, by directly accessing them from the LABELSconfig.

In this pseudo code example, we take VM template 0:

USER_TEMPLATE.LABEL_CONFIG.VM_TEMPLATES.0.KEYS() => ["uuid1"] => {for key in ["uuid1"]; return USER_TEMPLATE.LABELS.[key]} => [ { "name": "Testing", "labelcreated": 1688880000 }]

This allows users to define their own labels and store them in their own templates without interfering with other users labels at all.

Example 2: Global Labels is set to true

In this example, the labels are stored directly on the resources and thus shared between all the users that have access to those resources. And in case GLOBAL_LABELS ever changes to false, the metadata stored for those labels will be used to distribute them back as user labels instead of global/system ones. So a series of user updates will be made in that case.

{
  "VM_TEMPLATES": {
    "0": {
      "LABELS": [
        {
          "user1": [
            { "uuid1": { "name": "Testing", "dateadded": 1688894400 } }
          ]
        }
      ]
    }
  },
  "VMS": {
    "1": {
      "LABELS": [
        {
          "user2": [
            { "uuid2": { "name": "Production", "dateadded": 1688898000 } },
            { "uuid3": { "name": "Development", "dateadded": 1688901600 } }
          ]
        }
      ]
    }
  }
}

Use case
Distinguish between user defined and system/globally defined labels.

Interface Changes
Button under the settings tab that allows the oneadmin user to toggle between the GLOBAL_LABELS options.

Additional Context
Please feel free to add any other context or screenshots about the feature request here. Or any other alternative you have considered to address this new feature.

Progress Status

• Code committed
• Testing - QA
• Documentation (Release notes - resolved issues, compatibility, known issues)