OKD 4.6.0-0.okd-2021-02-14-205305 (#7)

okd:  disconnected installation with load balancer services and dynamic storage provisioning

.github/CONTRIBUTING.md

@@ -9,7 +9,7 @@ several ways to contribute, and we appreciate all of them.
 
 ## What Goes Where
 
-This repository contains a OKD The Hard Way labs and configuration files.
+This repository contains the OKD The Hard Way labs documentation and resources.
 
 If you are porting OKD The Hard Way to a different environment, that code should
 go in a seperate repository. Of course, if your port requires in changes in this
@@ -18,32 +18,34 @@ code base, we encourage you to contribute them here.
 ## Bug Reports
 
 While the OKD The Hard Way is designed to be a reliable, it is not bug free, and
-we can't fix what we don't know, so please report liberally. If you're not sure
-if something is a bug or not, feel free to file a bug anyway.
+we can not fix what we do not know, so please report liberally. If you are not
+sure if something is a bug or not, feel free to file a bug anyway.
 
 If you have the chance, before reporting a bug, please [search existing
-issues](https://github.com/raballew/okd-the-hard-way/issues), as it's possible
-that someone else has already reported your error. This doesn't always work, and
-sometimes it's hard to know what to search for, so consider this extra credit.
-We won't mind if you accidentally file a duplicate report.
+issues](https://github.com/raballew/okd-the-hard-way/issues), as it is possible
+that someone else has already reported your error. This does not always work,
+and sometimes it is hard to know what to search for, so consider this extra
+credit. We will not mind if you accidentally file a duplicate report.
 
 Opening an issue is as easy writing an e-mail to one of the contributors and
 filling out the fields. Here's a template that you can use to file a bug, though
-it's not necessary to use it exactly:
+it is not necessary to use it exactly:
 
-    <short summary of the bug>
+```txt
+<short summary of the bug>
 
-    I tried this code:
+I tried this code:
 
-    <code sample that causes the bug>
+<code sample that causes the bug>
 
-    I expected to see this happen: <explanation>
+I expected to see this happen: <explanation>
 
-    Instead, this happened: <explanation>
+Instead, this happened: <explanation>
 
-    ## Meta
+## Meta
 
-    environment:
+environment:
+```
 
 All three components are important: what you did, what you expected, what
 happened instead. Please include the environment you tested on as well as any
@@ -59,7 +61,7 @@ helpful.
 Fork the [project](https://github.com/raballew/okd-the-hard-way) and check out
 your copy locally.
 
-```shell
+```bash
 git clone [email protected]:username/okd-the-hard-way.git
 cd okd-the-hard-way
 git remote add upstream git://github.com/raballew/okd-the-hard-way.git
@@ -69,26 +71,26 @@ git remote add upstream git://github.com/raballew/okd-the-hard-way.git
 
 Create a feature branch and start hacking:
 
-```shell
-git checkout -b my-branch -t origin/master
+```bash
+git checkout -b my-branch -t origin/main
 ```
 
-You should always start new feature branches from `upstream/master`. Try not to
+You should always start new feature branches from `upstream/main`. Try not to
 stack up changes on local branches. We try to resolve pull requests in a timely
 manner so you shouldn't have too many outstanding changes in flight.
 
 ### Step 3: Commit
 
 Make sure git knows your name and email address:
 
-```shell
+```bash
 git config --global user.name "J. Random User"
 git config --global user.email "[email protected]"
 ```
 
 Add and commit:
 
-```shell
+```bash
 git add my/changed/files
 git commit
 ```
@@ -135,14 +137,14 @@ subsystem (or subsystems) your changes touch.
 
 Use `git rebase` (not `git merge`) to sync your work from time to time.
 
-```shell
+```bash
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 ```
 
 ### Step 5: Push
 
-```shell
+```bash
 git push origin my-branch
 ```
 
@@ -151,37 +153,37 @@ branch. Click the 'Pull Request' button and fill out the form.
 
 ### Step 6: Discuss and update
 
-You will probably get feedback or requests for changes to your Pull Request.
+You will probably get feedback or requests for changes to your pull request.
 This is a big part of the submission process so don't be disheartened!
 
 In general the relevant team members will review a pull request, ask for any
 changes, and get support from the larger team before merging a PR. If you are
 curious about the specifics, feel free to read through the specific process.
 
-To make changes to an existing Pull Request, make the changes to your branch.
+To make changes to an existing pull request, make the changes to your branch.
 When you push that branch to your fork, GitHub will automatically update the
 Pull Request.
 
 You can push more commits to your branch:
 
-```shell
+```bash
 git add my/changed/files
 git commit
 git push origin my-branch
 ```
 
-Feel free to post a comment in the Pull Request to ping reviewers if you are
+Feel free to post a comment in the pull request to ping reviewers if you are
 awaiting an answer on something.
 
-Before its ready to merge, your Pull Request should contain a minimal number of
+Before its ready to merge, your pull request should contain a minimal number of
 commits (see notes about [rewriting-history](#rewriting-history)).
 
 ### Step 7: Landing
 
-In order to land, a Pull Request needs to be reviewed and approved by at least
+In order to land, a pull request needs to be reviewed and approved by at least
 one person with commit access to the OKD The Hard Way repository and pass the
 continuous integration tests. After that, as long as there are no objections,
-the Pull Request can be merged.
+the pull request can be merged.
 
 ## Issue Triage
 
@@ -197,7 +199,7 @@ leave a comment letting us know if it is or is not.
 
 ### Rewriting History
 
-Once the reviewer approves your Pull Request, they might ask you to clean up the
+Once the reviewer approves your pull request, they might ask you to clean up the
 commits. There are a lot of reasons for this. If you have a lot of fixup
 commits, and you merge all of them directly, the git history will be bloated.
 Or, if your recent commit fixes your previous commit in the same PR, then you

LICENSE → LICENSE.md

@@ -1,6 +1,7 @@
 MIT License
+===========
 
-Copyright (c) 2020 Paul Wallrabe
+Copyright (c) 2021 Paul Wallrabe
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of
 this software and associated documentation files (the "Software"), to deal in

README.md

@@ -14,38 +14,62 @@ setup the way they are and troubleshoot more advanced issues.
 ## Cluster Details
 
 OKD The Hard Way guides you trough bootstrapping a highly available OKD cluster
-on UPI in an disconnected environment following best practices.
+on UPI in a disconnected environment following practices used in real world
+scenarios.
 
 ### Nodes
 
-| # | OS               | RAM  | CPU  |  Disk  | Usage        |
-| - | ---------------- | ---- | ---- | ------ | ------------ |
-| 1 | Fedora           | 8 GB | 2    | 50 GB  | services     |
-| 1 | Fedora Core OS   | 8 GB | 2    | 50 GB  | bootstrap    |
-| 3 | Fedora Core OS   | 8 GB | 2    | 50 GB  | control      |
-| 3 | Fedora Core OS   | 8 GB | 2    | 50 GB  | compute      |
-| 3 | Fedora Core OS   | 8 GB | 2    | 50 GB  | infra        |
+| # | OS               | RAM   | CPU  |  Disk           | Usage         |
+| - | ---------------- | ----- | ---- | --------------- | ------------- |
+| 1 | Fedora           | 8 GB  | 2    | 256 GB          | services      |
+| 1 | Fedora Core OS   | 16 GB | 4    | 128 GB          | bootstrap     |
+| 3 | Fedora Core OS   | 16 GB | 4    | 128 GB          | master        |
+| 3 | Fedora Core OS   | 16 GB | 4    | 128 GB          | compute       |
+| 3 | Fedora Core OS   | 16 GB | 4    | 128 GB          | infra         |
+| 3 | Fedora Core OS   | 32 GB | 8    | 128 GB + 256 GB | storage       |
 
 ### Components
 
-* [OKD
-  4.5.0-0.okd-2020-08-12-020541](https://github.com/openshift/okd/releases/tag/4.5.0-0.okd-2020-08-12-020541)
-  * [Kubernetes 1.18.3](https://github.com/kubernetes/kubernetes/releases)
-  * [Fedora CoreOS
-    32.20200629.3.0](https://getfedora.org/en/coreos?stream=stable)
+* [OKD 4.6.0-0.okd-2021-02-14-205305](https://github.com/openshift/okd/releases)
+  * [Kubernetes 1.19.2](https://github.com/kubernetes/kubernetes/releases)
+  * [Fedora CoreOS 33.20210104.3](https://builds.coreos.fedoraproject.org/browser)
+* [Rook Ceph 1.5.7](https://github.com/rook/rook)
+* [MetalLB 0.95.0](https://github.com/metallb/metallb)
 
 ## Labs
 
+This lab can be split into three parts. The first part will guide you through
+all steps required to setup a new cluster.
+
 * [Prerequisites](docs/00-prerequisites.md)
 * [Hypervisor](docs/01-hypervisor.md)
 * [Services](docs/02-services.md)
 * [Installation](docs/03-installation.md)
-* [Authentication](docs/04-authentication.md)
-* [Permissions](docs/05-permissions.md)
-* [Nodes](docs/06-nodes.md)
+
+Part two will then prepare the cluster for multitenant production workloads.
+
+* [Authentication](docs/10-authentication.md)
+* [Permissions](docs/11-permissions.md)
+* [Nodes](docs/12-nodes.md)
+* [Operator Lifecycle Manager](docs/13-olm.md)
+* [Storage](docs/14-storage.md)
+* [Networking](docs/15-networking.md)
+* [Operations](docs/16-operations.md)
+
+Everything mentioned in parts one and two is explained in detail but the
+drawback is that all the steps need to be performed manually. In the event of a
+disaster it will take quite some time to recover from the outage. Therefore the
+third part leverages the previously gained knowledge to build a fully automated
+process to spin up and handle common tasks while maintaining the cluster.
+
+* [Deploy](docs/20-deploy.md)
+* [Maintain](docs/21-maintain.md)
+* [Usage](docs/22-usage.md)
 
 Whenever things break or an unexpected issue occurs, please refer to the
-[troubleshooting](docs/99-troubleshooting.md) section.
+[troubleshooting](docs/99-troubleshooting.md) section. You can also create a new
+[issue](https://github.com/raballew/okd-the-hard-way/issues/new/choose) if you
+have the feeling that something is wrong or could be done better.
 
 ## Contributing
 
@@ -57,4 +81,4 @@ through any needed changes.
 
 ## License
 
-Licensed under MIT license ([LICENSE](LICENSE)).
+Licensed under MIT license ([LICENSE.md](LICENSE.md)).

docs/00-prerequisites.md

@@ -3,36 +3,38 @@
 ## Accounts
 
 * [Red Hat Network Account](https://www.redhat.com/wapps/ugc/register.html)
+* [Docker Hub Account](https://hub.docker.com/signup) with no rate limit
 
 ## Bare Metal Server
 
 This tutorials relies on the capabilities of a single bare metal server and
 virtualization. This makes it easy to troubleshoot issues on the one hand but
 increases the requirements for a suitable machine on the other hand.
 
-The following system specifications are recommended:
+The following system specifications are recommended for the hypervisor node:
 
-* 1 TB storage (use NVMe SSDs if possible) with more than 750 GB free in `/`
-* 128 GB RAM
-* 32 CPU cores
+* 3 TB storage (use NVMe or SSD) in `/home/`
+* 256 GB RAM
+* 64 CPU cores
 * 1 GBit/s network interface
 * Internet access
 * Virtualization capabilities
-* Fedora 32 installed
+* Fedora 33 installed
 
-If this setup does not fit into your budget or you are not able to find a
+If this setup does not fit into your budget or if you are not able to find a
 machine with this specifications Kernel-based Virtual Machines (KVMs) are used
 in this lab and might solve this problem. KVM is an open source virtualization
 technology which converts your Linux machine into a type-1 bare-metal hypervisor
 that allows you to run multiple virtual machines (VMs) or guest VMs. The KVM
 hypervisor automatically overcommits CPUs and memory. This means that more
 virtualized CPUs and memory can be allocated to virtual machines than there are
 physical resources on the system. This is possible because most processes do not
-access all of their allocated resources all the time.
+access all of their allocated resources all the time. Just make sure that your
+system never really requests more resources than actually physically available.
 
 ## Time
 
 The total time needed will vary but without any previous knowledge you will
-probably need a week or two to fully understand everything shown here.
+probably need a week or two to complete and understand the lab.
 
 Next: [Hypervisor](01-hypervisor.md)