This means that SIP and VINO must be tightly be coupled in that either VINO must know the set of topology labels expected by SIP (current implementation) or SIP must know the set of topology labels provided by VINO. Also it restricts users from defining and using their own custom topology labels.
Proposed change
Replace the topologySpread field/enum with a topologyKey field which allows an arbitrary label key. For example:
topologyKey: vino.airshipit.org/rack (or whatever other topology may be present on a BMH)
instead of
topologySpread: PerRack
Then SIP itself no longer needs to have knowledge of VINO, only the SIP CR author needs to have knowledge of the BMH ineventory topology labels they are consuming.
seaneagan
commented
3 years ago
Problem description (if applicable) Currently we support some form of anti-affinity based on an enum of topology domains: https://github.com/airshipit/sip/blob/f224ee3d42c53be0aac3d69101536b6b53ec2558/pkg/api/v1/sipcluster_types.go#L148 mapped to hard coded BMH labels: https://github.com/airshipit/sip/blob/5be3440637f691beea3d912bb248eb687588929a/pkg/vbmh/machines.go#L255
This means that SIP and VINO must be tightly be coupled in that either VINO must know the set of topology labels expected by SIP (current implementation) or SIP must know the set of topology labels provided by VINO. Also it restricts users from defining and using their own custom topology labels.
Proposed change
Replace the
topologySpreadfield/enum with atopologyKeyfield which allows an arbitrary label key. For example:topologyKey: vino.airshipit.org/rack(or whatever other topology may be present on a BMH) instead oftopologySpread: PerRackThen SIP itself no longer needs to have knowledge of VINO, only the SIP CR author needs to have knowledge of the BMH ineventory topology labels they are consuming.