gcp(tags): backward compatible extended usage

[rinor]

I need a bit more control over what goes where. The existing behavior is kept the same, unless one uses the new specific definitions.

• this config behaves the same as before:

  {
  "CloudConfig": {
  "Tags": [
    {
      "key": "instance-and-image",
      "value": "instance-image"
    }
  ]
  }
  }

• new config options - all options (you can set to true only what you need)

  {
  "CloudConfig": {
  "Tags": [
    {
      "key": "everywhere",
      "value": "image-instance-metadata-valueAtnetwork",
      "image_label": true, // added to image labels upon image build
      "instance_label": true, // added to instance labels upon instance creation
      "instance_metadata": true // added to instance custom metadata upon instance creation
      "instance_network": true,  // tag VALUE is added to instance network tags
    }
  ]
  }
  }

[eyberg]

tags are heavily used by quite a few people/orgs so I do like the backwards compatibility of this; one change that i might suggest if you want to break it up into varying types - create a new tag struct and stick an enum in it to define the type with the default choice being the old style (eg: used for everything)

[rinor]

tags are heavily used by quite a few people/orgs so I do like the backwards compatibility of this; one change that i might suggest if you want to break it up into varying types - create a new tag struct and stick an enum in it to define the type with the default choice being the old style (eg: used for everything)

what if we add an extended attribute to tags, containing the new specific attributes, that if present and set, will activate and use new functionality, i.e:

1. Existing behavior, remains unchanged, if configured as always

{
  "CloudConfig": {
    "Tags": [
      {
        "key": "instance-and-image",
        "value": "instance-image"
      }
    ]
  }
}

2. Equivalent behavior/result if using the new config

{
  "CloudConfig": {
    "Tags": [
      {
        "key": "instance-and-image",
        "value": "instance-image",
        "attribute": {
          "image_label": true,
          "instance_label": true
        }
      }
    ]
  }
}

3. If preferred and desired, feedback needed here, we could even treat an empty attribute list as not set, so this config would have the same behavior/result as (1. and 2.)

{
  "CloudConfig": {
    "Tags": [
      {
        "key": "instance-and-image",
        "value": "instance-image",
        "attribute": {}
      }
    ]
  }
}

4. And this would be different from (3.), since as soon as you add at least one field inside attribute (true or false it doesn't matter), you opt-in for the new explicit config:

   {
   "CloudConfig": {
   "Tags": [
     {
       "key": "this-goes-nowhere",
       "value": "non-existent",
       "attribute": {
         "image_label": false,
         "instance_label": false,
         "instance_network": false,
         "instance_metadata": false
       }
     }
   ]
   }
   }

In the meantime, I will update the code so we can check what it could look like

[eyberg]

yeh - makes sense - i'm good w/these changes - is this ready to merge?

[rinor]

yeh - makes sense - i'm good w/these changes - is this ready to merge?

yes, will push also the updated ops docs a bit later