Create a minimum documentation page

[ArangoGutierrez]

This patch cleans up the Readme and creates a very minimal documentation page
Signed-off-by: Carlos Eduardo Arango Gutierrez [email protected]

[marquiz]

Nice work @ArangoGutierrez!

Some notes and comments when quickly skimming through the patch.

[ArangoGutierrez]

/assign marquiz

[marquiz]

My only open comments are related to parameterizing the operator and operand versions in docs/_config.yml.

Also, we need some index.html in the site root. We can do e.g. redirection similar to nfd:
https://github.com/kubernetes-sigs/node-feature-discovery/blob/master/docs/index.html

[ArangoGutierrez]

gotta say verify-docs is... very difficult to please

[marquiz]

Woops 🙄 Now that I actually look at the config here (docs/_config.yml) I see that most of the things are already parameterized (version, release, container_image). Version is supposed to indicate the "release branch" (e.g. v0.2) where as release would match the full release tag (e.g. v0.2.0). The separate container_image variable is in place because staging (master) and releases use a different image registry. We'd actually only need to add operand_release there.

Also, the thinking behind the parameterization/versioning was that the master branch (what we're doing here) should actually instruct how to deploy the staging/master version of the operator. The reasoning behind is that otherwise the documentation and the version we instruct to deploy will (at some point) get out-of-sync and create confusion and/or stop to work. Getting user to deploy the latest release is handled by the documentation versioning (browsing to https://kubernetes-sigs.github.io/node-feature-discovery-operator will redirect the user to docs of the latest stable version).

Thus, my suggestion would be:

• only add operand_release parameter (in docs/_config.yml)
• use the existing release, version and container_image elsewhere which will instruct the user to deploy the staging/devel version (for the master branch)
• when this PR gets merged backport docs/ tp release-0.2 branch
  • cherry-pick all PRs to docs/ so far (ca. 4 patches)
  • backport this PR (should be quite trivial, prolly simply update _config.yml, plus, NodeFeatureDiscovery CR needs to be copied from v0.2.0)
  • these^ would create a "stable" version of the documentation in gh-pages where users would land by default

WDYT?

[ArangoGutierrez]

/retest

[ArangoGutierrez]

/label tide/merge-method-squash

[marquiz]

Thanks for your efforts @ArangoGutierrez! I think this is very good initial documentation 😄 👍

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ArangoGutierrez, marquiz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ArangoGutierrez,marquiz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment