search

openshift / oadp-operator

OADP Operator
Apache License 2.0
78 stars 72 forks source link

Add to e2e test adding all default plugins to velero deployment doesn't cause image pull errors #631

Open kaovilai opened 2 years ago

kaovilai commented 2 years ago

This test checks that all default images are pullable and don't conflict with each other.

openshift-bot commented 2 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

kaovilai commented 2 years ago

/lifecycle frozen

mateusoliveira43 commented 11 months ago

What are all default images? these? https://github.com/openshift/oadp-operator/blob/master/config/manager/manager.yaml#L39-L56

how should be a test to check they don't conflict with each other?

kaovilai commented 11 months ago

What are all default images? these? https://github.com/openshift/oadp-operator/blob/master/config/manager/manager.yaml#L39-L56

yes. Adding them all at once should cause add all the plugins to container and event/pod should tell us if there are image pull errors. Though this may only prove that the upstream quay images are pullable.

how should be a test to check they don't conflict with each other?

I was thinking that each plugin initcontainer essentially copy dirs into /plugin folder

FROM scratch
COPY --from=build /go/bin/velero-plugin-for-aws /plugins/
COPY --from=build /go/bin/cp-plugin /bin/cp-plugin

It would be wise to check that no more than one plugin uses path velero-plugin-for-aws for example. In other words, if there are 5 plugins, you would expect there to be 5 dirs under /plugins/ in velero pod (in addition to any velero core plugins if any).