Add fake operator for testing Operator Policy #286
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not having control over operators used in testing makes tests inconsistent. This commit adds a fake operator for testing that is locally built, and uses a locally hosted registry in KinD. It lives in its own catalog.
Ref: https://issues.redhat.com/browse/ACM-11160
Details:
Majority of the code goes under the
fake-operator-test
folder, which I'll be explaining by subfolder below. I'll then outline things that have yet to be completed.fake-catalog
This folder contains everything required to build a catalog, originally scaffolded using the
opm
tool. I have not modified anything after initial scaffolding.fake-operator
This folder contains everything that goes into building the fake operator bundle. This was originally scaffolded using
operator-sdk
following these instructions, but I removed the majority of it, and changed the dockerfile to specify a container that sleeps indefinitely (usingtail -f /dev/null
as an entrypoint). Another important point is that the make targetmake bundle
uses theconfig
subfolder to generate the bundle. I modified therbac
folder where I commented outservice_account.yaml
in the kustomization file, since it was giving me weird serviceaccount errors on the deployments. I also modifiedmanager/manager.yaml
to not contain a command under thecontainers
part of the spec, since on deployment this would give an error where the command wouldn't run. Documentation here (you might need to ctrl-f 'command') seems to claim that the dockerfileENTRYPOINT
is used instead.scripts
This folder contains two shell files
local-registry.sh
andcreate-catalog.sh
.local-registry.sh
creates a locally hosted registry following these instructions hosted atlocalhost:5001
.create-catalog.sh
does everything else required to make the catalogsource available, from building the operator bundle, building the catalog bundle, and applying it. It also applies a serviceaccount that seems to be needed to install deployments properly (but doesn't seem to be applied automatically). I wasn't too sure about this, so it should probably be examined a bit more thoroughly. Also, the deployment seems to fail anyways.Files:
fake-operator-template.yaml
This file is required for building the catalogsource.
kind-registry-config.yaml
Part of hosting the kind registry
kind-registry-configmap.yaml
Also part of hosting the kind registry
TODOs:
make kind-bootstrap-cluster-dev