Generate operator manifests including OLM objects

[djzager]

This PR provides tooling tools/manifest-templator and scripting hack/build-manifests.sh to generate the deploy/ directory from code.

TODO:

• Provide a method for testing this in OLM
• Operator-courier integration (May need to ask for help from @slintes to get direction).
• Nail down the rules needed for successful operation of the cluster-network-addons-operator (can't count on being able to bind to a named cluster-role)
• update https://github.com/kubevirt/cluster-network-addons-operator#deployment with new path to manifests and requirement to create the namespace

[phoracek]

Thanks for this PR, I really appreciate it. I have some questions, but more that requests for a change it's me trying to understand what is the scope of CSV and relation between this operator and HCO/KubeVirt.

[phoracek]

@djzager you can leave 3rd point (to make minimal cluster role) to us, it is absolutely fine if you keep it like this (or even do "*") in this PR. I don't want to steal too much time from you.

[phoracek]

Also, could you please update https://github.com/kubevirt/cluster-network-addons-operator#deployment with new path to manifests and requirement to create the namespace?

[djzager]

Also, could you please update https://github.com/kubevirt/cluster-network-addons-operator#deployment with new path to manifests and requirement to create the namespace?

I can do this, I'm going to make all of the other code changes before I update the README. Adding this to the todo.

@djzager you can leave 3rd point (to make minimal cluster role) to us, it is absolutely fine if you keep it like this (or even do "*") in this PR. I don't want to steal too much time from you.

I'll give it a couple of shots and see how it goes. Won't shut this door yet 😎

[phoracek]

@djzager please see https://github.com/kubevirt/cluster-network-addons-operator/pull/42/files#r272296585

[phoracek]

Looks good so far :)

[djzager]

To summarize the changes in "Take version from image tag":

• Add a new make target manifests to generate the deploy directory.
• Remove the version pkg, I think that would surprise developers coming from other kubevirt projects
• Make the CSV_VERSION come from the IMAGE_TAG in the makefile, defaulting to latest. When using latest we'll make the CSV_VERSION 0.0.0 which should obviously be an unreleased version.

You should now be able to add a release process in travis to simply make the IMAGE_TAG=${TRAVIS_TAG and the CSV_VERSION will be handled from that. Handling when an unreleased CSV_VERSION (in the future) replaces a released version is left to be figured out later.

[ovirt-infra]

Hello contributor, thanks for submitting a PR for this project!

I am the bot who triggers "standard-CI" builds for this project.
As a security measure, I will not run automated tests on PRs that are not from white-listed contributors.

In order to allow automated tests to run, please ask one of the project maintainers to review the code and then do one of the following:

1. Type ci test please on this PR to trigger automated tests for it.
2. Type ci add to whitelist on this PR to trigger automated tests for it and also add you to the contributor white-list so that your future PRs will be tested automatically. ( keep in mind this list might be overwritten if the job XML is refreshed, for permanent whitelisting, please follow need to change the deployment command #3 option )
3. If you are planning to contribute to more than one project, maybe it's better to ask them to add you to the project organization, so you'll be able to run tests for all the organization's projects.

[phoracek]

Looks good! Thanks :)

[phoracek]

@djzager could you remove the "WIP" if it's ready to be merged?