Allow using AMIs built for architectures other than amd64

[ldx]

Right now kip can only use one AMI specified via bootImageSpec in provider.yaml.

However, AMIs are specific to the OS and CPU architecture. To support other architectures and OSes (ARM, mac1, etc) we need to be able to specify a boot image filter for each.

[hidalgopl]

@ldx @jrroman @henryprecheur What you guys think of having something really generic, such as:

bootImageSpec:
    amis:
      - familyRegex: "mac.*"
        owners: 689494258501
        filters: name=elotl-kip-mac*
      - familyRegex: "*" # default
        owners: 689494258501
        filters: name=elotl-kip-*

[jrroman]

@hidalgopl so the issue i see with this is it will break reverse compatibility with previous releases of kip. We could potentially add this for additional ami fields while keeping the base of owner and filter. This is the way i have been testing currently:

 16   bootImageSpec:
 17     owners: 689494258501
 18     filters: name=elotl-kip-*
 19     macfilters: name=elotl-kipmac-*
 20     armfilters: name=elotl-kiparm-*

I do however think what you have described is very clear contextually and intuitive.

[hidalgopl]

@jrroman You're right, I haven't thought about it. We can keep backwards compatibility by keeping what I proposed under new key:

 bootImageSpec:
      owners: 689494258501
      filters: name=elotl-kip-*
      overrideAMI:
       - familyRegex: "mac.*"
         owners: 689494258501
         filters: name=elotl-kip-mac*
      - familyRegex: "*" # default
        owners: 689494258501
        filters: name=elotl-kip-*

Big question is how flexible this feature needs to be. And whether we want to have different AMI for different arch, or different AMI for different instance type familiy. For our current needs keys you added are fully sufficient. However, if ever we want to be able to have different AMI for different instance type/family, introducing changes would be tricky if we already have feature that chooses AMI based on arch.

[ldx]

@jrroman You're right, I haven't thought about it. We can keep backwards compatibility by keeping what I proposed under new key:

bootImageSpec:
     owners: 689494258501
     filters: name=elotl-kip-*
     overrideAMI:
      - familyRegex: "mac.*"
        owners: 689494258501
        filters: name=elotl-kip-mac*
     - familyRegex: "*" # default
       owners: 689494258501
       filters: name=elotl-kip-*

Big question is how flexible this feature needs to be. And whether we want to have different AMI for different arch, or different AMI for different instance type familiy. For our current needs keys you added are fully sufficient. However, if ever we want to be able to have different AMI for different instance type/family, introducing changes would be tricky if we already have feature that chooses AMI based on arch.

bootImageSpec is a map[string]string, so making some values in the map lists or other data structures would break compatibility. I think an architecture prefix to keys should be a good first shot without adding too much complexity. We should get a canonical list of architectures and use those (i.e. same ones AWS uses in describe-images, e.g. x86_64, x86_64_mac, etc). So an example bootImageSpec might look like:

bootImageSpec:
  owners: 123456789
  x86_64-filters: name=elotl-kip-*
  x86_64_mac-filters: name=elotl-kip-mac-*

We can keep the current keys (filters, owners, etc) for backward compatibility.

Another missing piece: an instance family -> architecture mapping, so we know which architecture we need when starting an instance.