kubevirt / hyperconverged-cluster-operator / 3361 / 1
81%
main: 76%

LAST BUILD BRANCH: bump-kubevirtci
DEFAULT BRANCH: main
Ran
Files 3
Run time 24s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 80.204% (+0.05%) from 80.154%
3361.1

push

travis-ci

web-flow 
get ready for pod placement selectors (#718)

Introduce
spec.infra.affinity
spec.infra.nodeSelector
spec.infra.tolerations
spec.workloads.affinity
spec.workloads.nodeSelector
spec.workloads.tolerations
for affinity, nodeSelector and tolerations as corev1.Affinity,
map[string]string and []corev1.Toleration objects on HCO CR.

The first one will let the user specify affinity
for HCO managed infra pods.
Then nodeselector to express the same concept with
a simpler language.
iAnd the third one extra (on top of default ones) tolerations
for HCO managed infra pods.

And the same also for workloads specific pods.

This is not going to address the operators because
that can be performed just with a nodeselector
on the OLM subscription object.

The user will be allowed to specify them on HCO CR,
HCO will propagate them to the CR of components
operators according to their APIs.
HCO will continuously reconcile affinity, nodeSelectors
and tolerations on components CR according
to what the user specified on the HCO CR.

Using a validating webhook, HCO will accept updates
to spec.placement.workloads
if and only if no HCO related workload exists
on the cluster to avoid having to deal with
complex migrations of VMs or DVs.
In order to detect if HCO can accept the update,
HCO will try to update Kubevirt and CDI CRs in
dry-run mode expecting them to eventually refuse
the update due to existing workloads.

Signed-off-by: Simone Tiraboschi <stirabos@redhat.com>

1256 of 1566 relevant lines covered (80.2%)

39.36 hits per line

Source Files on job 3361.1