Multiple Build Asset Strawman

asset_example

---
type: Asset
api_version: core/v2
metadata:
  name: jspaleta/monitoring-plugins
  namespace: default
spec:
  # Existing attributes -> added as build entry for backwards compatibility
  sha512:  asdasdas
  url: http/what.up/asset.tar.gz
  filters: []
  # New optional attributes for completeness
  priority: 0
  name: "Lowest Priority Build"
  
  # New builds section: 
  # Asset Manager will transverse list, using first matching entry
  builds:
  # First Build: centos 6 specific
  - name: "Centos 6"
    url: "something"     
    sha512:  "SoMeThInG"inux'
    priority: 10
    filters:  
    - entity.system.os == 'linux'
    - entity.system.arch == 'amd64'
    - entity.system.platform == 'centos'
    - entity.system.platform_version.split('.')[0] == '6'
  # Second Build: centos 7 specific
  - name: "Centos 7"
    url: "something else"
    sha512: "SoMeThInG"    
    priority: 9
    filters: 
    - entity.system.os == 'linux'
    - entity.system.platform == 'centos'
    - entity.system.platform_version.split('.')[0] == '7'
  # Third Build: rhel family specific
  - name: "Rhel"
    url: "something something"    
    sha512: "SoMeThInG"    
    priority: 8
    filters: 
    - entity.system.os == 'linux'
    - entity.system.platform_family == 'rhel'
  # Fourth Build: fallback linux
  - name: "Unknown Linux"
    url: "hmm"    
    sha512: "HmM"    
    priority: 1
    filters: 
    - entity.system.os == 'linux'
    

notes

Notes:
* allow org/repo  styled naming for asset to map to bonsai organization.
* priority key is used by asset manager as a tie-breaker in case where multiple builds pass filter rules.
  priority numeric value should be unique for each build to ensure deterministic operation.
* Lowest priority build in the attached example, would always match after filtering, but would never be selected on a linux system, as higher priority matching builds exist.

Benefits:
* extends Asset resource in a backward compatible way, so existing asset configs without build list continue to work.
* Allow to encode a single named asset configuration in a namespace for all asset binaries
* simplifies Bonsai UI, no need for platform/arch modular dialog.
* potentially simplifies future bonsai asset lifecycle tooling -> mapping single asset resource to each bonsai index listing. 

Caveats:
* Need to teach agent Asset Manager how to parse build list, so build list will only be compatible with newer agents.
* Would result in a multi-step refactor for bonsai:
  initially would have to support broken out configs (in a deprecated manner), and multi-build config side-by-side, until older agents were no longer supported.