latest supported anthos version

[dfong]

i would like to be able to specify the "latest supported version" of anthos. is there an automated way of obtaining this info?

if not, i propose that there should be a text file, perhaps named ANTHOS_SUPPORTED_VERSIONS.txt. its contents would be one line per supported version, sorted by version number.

eg,

1.1.2-gke.0 1.2.0-gke.6 1.2.1-gke.4 1.2.2-gke.2 1.3.0-gke.16 1.3.1-gke.0 1.3.2-gke.1 1.4.0-gke.13 1.4.1-gke.1 1.5.0-gke.27

this is basically the same as what's in the README, only in raw form rather than markdown.

[dfong]

as a user i have found that not all revisions of this repo work with all versions of anthos. i feel it would be helpful to also list for each anthos version, the specific revision(s) of the repo that it has been tested with. of course, ideally each new version of the repo would be tested against every anthos version. but short of that, it would be helpful to give the user some idea of which revisions of the repo are compatible with which versions of anthos.

[jacobsmith928]

@dfong you might try to leverage our latest Anthos on Bare Metal terraform module. https://registry.terraform.io/modules/equinix/anthos-on-baremetal/metal/latest

[displague]

@dfong this data might be best tracked as a Terraform variable. We could track these as two separate variables, supported versions and latest version.

If this is data that you think you may need script access to, we could also consider using the .tf.json file format: https://www.terraform.io/docs/configuration/syntax-json.html#variable-blocks. I would probably just include these variables in variables.tf otherwise.

[dfong]

@jacobsmith928 ,

you might try to leverage our latest Anthos on Bare Metal terraform module.

unfortunately this isn't easy for me to do since the baremetal stuff seems to use different conventions than google-anthos.

also i need anthos 1.4 and 1.5 which doesn't seem to be supported by baremetal.

[dfong]

@displague ,

data might be best tracked as a Terraform variable. We could track these as two separate variables, supported versions and latest version.

json would be fine for my purposes, but i'm not sure about terraform. is there a reasonable way to access a terraform variable outside terraform?

alternatively, branching or tagging would work for me. that is, if each anthos version had a tag like "tested-with-VERSION" .

[gfthybridlabs]

I tried v1.6 of Anthos but got some errors around node affinity. Maybe it was transient will have to retry.

[displague]

alternatively, branching or tagging would work for me. that is, if each anthos version had a tag like "tested-with-VERSION" .

This particular format of tags would not be unique and would need to be moved around commits.

---

This is what I imagine a PR for this would look like. I'm don't know what the current set of versions should be.

anthos-version-compatibility.tf.json

{
  "variable": {
    "compatible_anthos_versions": {
      "description": "Anthos versions that are known to be compatible with this module",
      "default": ["", "", ""]
    },
    "latest_anthos_version": {
      "description": "The latest Anthos version known to be compatible with this module",
      "default": ""
    }
  }
}

This format would be easy to parse with jq for ancillary tooling.

[dfong]

@displague ,

This particular format of tags would not be unique and would need to be moved around commits.

i don't understand your objections. suppose i need anthos 1.4. i want to check out a version of google-anthos that is known to work with 1.4. under my proposed scheme, i'd be able to do that by looking for tags of the form "tested-with-1.4*" and checking out one of them.

of course it is true that the tags would need to be "moved" as further testing is done. the ability to move the tags seems like a feature, not a bug.

one argument for using tags rather than a terraform source file is, suppose we have an automated CI system in the future. you would need to check in the source file, which superficially would look like a change requiring a rebuild. i think the info about which versions have been tested is sort of metadata.