Move wow from dev-tools

wow/Upgrade-image.md

@@ -0,0 +1,64 @@
+# Metal3 node and openstack images upgrading
+
+## 1. Download the vanilla image
+
+- **Ubuntu**
+
+Download the target raw version from [ubuntu.com](https://cloud-images.ubuntu.com/)
+then convert it to `qcow2`
+
+```console
+qemu-img convert -O qcow2 ubuntu-22.04-server-cloudimg-amd64.img ubuntu-22.04-server-cloudimg-amd64.qcow2
+```
+
+- **Centos**
+
+Download the target qcow2 version directly from
+[centos.org](https://cloud.centos.org/centos/9-stream/x86_64/images/)
+
+## 2. Upload the qcow2 to both regions in citycloud
+
+The region target can be specified in the openstack rc-file, download
+and source the rc-file then run
+
+```sh
+openstack image create --disk-format qcow2 --container-format bare \
+    --private --file ./Centos-7-9-22.qcow2 CentOS-Stream-9-20220829
+```
+
+## 3. Update the source image name in the dev-tools
+
+Create a PR to update the source image name `SOURCE_IMAGE_NAME` that
+will be used when running the image building job, [for example](
+https://github.com/Nordix/metal3-dev-tools/pull/592/files).
+
+## 4. Trigger image building job
+
+Once the dev-tools PR get merged, the image building job will be
+triggered automatically and build node images with the default
+kubernetes version and the openstack images in the different regions,
+but you still need to re-trigger the job manually from jenkins to build
+the node images with old kubernetes versions needed. (Login to Jenkins
+go to openstack_node_image_building Job and click "Build with
+Parameters" after that set the kubernetes version needed).
+
+The main tests usually use two node images with different kubernetes
+minor versions needed when testing kubernetes upgrade. check
+`KUBERNETES_VERSION` and `UPGRADED_K8S_VERSION` in dev-env.
+
+The older CAPM3 releases might still need different kubernetes versions
+for their tests!
+
+## 5. Update dev-env and CAPM3
+
+After building all the necessary images and uploading them, we need to
+update the images name and location in dev-env and CAPM3 repos. Example
+PRs:
+[dev-env uplift](https://github.com/metal3-io/metal3-dev-env/pull/1069/files),
+[CAPM3 uplift](https://github.com/metal3-io/cluster-api-provider-metal3/pull/712/files).
+Please to be noted, we might need to back port the updates to the old
+releases in CAPM3.
+
+For PR testing, it is preferred to start with dev-env since the CAPM3 PR
+depends on dev-env but both PR need to go in together since after
+changing dev-env CAPM3 might be failing.

wow/cleura.md

@@ -0,0 +1,80 @@
+# Cleura Openstack
+
+## Overview
+
+Our Openstack infrastructure is provided by Cleura. The main interface is the
+web UI and can be accessed [here](https://cleura.cloud). You will need
+to have an account there, you can ask the team to get one.
+
+## Accessing the Openstack API
+
+In order to access the openstack API, you need to create a user. The web page to
+do so can be accessed in the menu, API -> Native Openstack API. You then need to
+add the projects to which the user will be authorized. Once done, you can
+download an `openstack.rc` file for each of the projects you need to access
+
+## Projects
+
+We have three projects :
+
+- **default**: The CI project, please do not create machines there
+- **dev**: The developers project
+- **dev2**: The second developers project
+
+For development purposes, please use either *dev* or *dev2*
+
+## Connectivity
+
+In the *dev* and *dev2* projects, we have a jumphost as a bastion host. No
+floating IP should be given to the VMs directly except the jumphost. All SSH
+access goes through the jumphosts.
+
+## Example SSH config
+
+In order to access the dev VMs (`10.101.10.*` or `10.201.10.*`), the SSH traffic
+needs to go through the jumphost. If you want to SSH to the jumphost itself,
+please use the metal3ci account with the correct SSH key.
+
+Replace user by your username in the following script
+
+```bash
+Host dev_jumphost
+  User <user>
+  IdentityFile /home/<user>/.ssh/id_rsa
+  StrictHostKeyChecking no
+  UserKnownHostsFile /dev/null
+  Hostname 188.212.109.109
+Host 10.101.10.*
+  User ubuntu
+  IdentityFile /home/<user>/.ssh/id_rsa
+  StrictHostKeyChecking no
+  UserKnownHostsFile no
+  ProxyCommand ssh  -W %h:%p dev_jumphost
+Host dev2_jumphost
+  User <user>
+  IdentityFile /home/<user>/.ssh/id_rsa
+  StrictHostKeyChecking no
+  UserKnownHostsFile /dev/null
+  Hostname 188.95.226.253
+Host 10.201.10.*
+  User ubuntu
+  IdentityFile /home/<user>/.ssh/id_rsa
+  StrictHostKeyChecking no
+  UserKnownHostsFile no
+  ProxyCommand ssh  -W %h:%p dev2_jumphost
+```
+
+## Create a VM
+
+You can create the VM through the web UI or the API as you wish, as long as it
+follows those rules:
+
+- no floating IP
+- port security and security group set (*default* allows only ssh as incoming
+  traffic from the jumphost or other machines in the default security group).
+  You can create your own security group if needed.
+- sensible specs (we are sharing resources)
+- network connectivity : metal3-ext-dev only , no direct connection to the
+  external network
+- don't use passwords but SSH keys
+- delete your machine when you don't need it anymore

wow/github-workflow.md

@@ -0,0 +1,252 @@
+# Github Workflow
+
+## Overview
+
+The workflow is based on the understanding that:
+
+- A project is forked from Open Source project to nordix
+- A local copy is cloned from nordix
+
+We refer to the Open Source project repo as `upstream`, `upstream/main`
+and to the forked repo in the Nordix organization as `origin`,
+`origin/main`
+
+Main branch is called `main`, containing the latest stable release.
+
+Feature development and bug fixing are done in topic branches, branched
+of `main` branch. Upon completion and code review, topic branch is
+merged into `upstream` branch.
+
+## Branches
+
+### Topic branches (features and bug fixes)
+
+Topic branches need to be branched off `main` and named
+`type/name-username`, where  type is `feature` or `fix` and `username`
+the Github username or the name of the person creating the branch, to
+mark ownership of the branch.
+
+For example, a branch name for a feature called `Add support for
+policies` by user xyz would be `feature/policy-support-xyz` or similar,
+where a `User cannot login` bug would be `fix/user-cannot-login-xyz` or
+similar.
+
+If applicable, branch name should also contain Github Issue ID, for
+example `fix/13-userr-cannot-login-xyz`.
+
+## Commit Message
+
+Commit message should be formatted as following.
+
+```sh
+Short (50 chars max or as subjected by open source repo practise) summary
+
+More detailed explainatory text, if necessary. Wrap it to about 72
+characters or so. Write your commit message in the imperative: "Fix bug"
+and not "Fixed bug" or "Fixes bug".
+
+Signed-off-by: My Name <[email protected]>
+Co-authored-by: My Colleague <[email protected]>
+```
+
+If your commit includes contributions from someone else, add this person as
+co-author by adding the Co-authored-by trailer at the end of your commit.
+
+Note that the email address might be protected by Github, then you need to
+use the address provided by Github.
+
+## Git workflow for a Github repo through Nordix
+
+### 1. Create a topic branch
+
+Create and checkout local branch where you will do your work.
+
+`git checkout -b <topic-branch> origin/main`
+
+Make sure to have the latest code from the upstream repository
+
+```sh
+git fetch upstream
+git rebase upstream/main
+```
+
+When pushing the branch for the first time, ensure correct tracking is set up:
+
+`git push -u origin <topic-branch>`
+
+### 2. Keep topic branch up-to-date
+
+When changes have been pushed to `main` branch, ensure your topic branch is up-to-date.
+
+```sh
+git fetch upstream
+git checkout <topic-branch>
+git rebase upstream/main
+```
+
+<!-- markdownlint-disable MD026 -->
+### 3. Code, test ....
+<!-- markdownlint-enable MD026 -->
+
+Do your magic :)
+
+### 4. Commit the changes
+
+Changes should be grouped into logical commits, Refer to above [commit
+message](#commit-message) for details.
+
+```sh
+git add -p # only for existing files
+git add <file> # when new file added
+git commit -S
+```
+
+### 5. Push the changes
+
+Rebase your changes on the upstream main to make sure
+to have the latest commits in
+
+```sh
+git fetch upstream
+git rebase upstream/main
+```
+
+Changes should be pushed to a correct origin branch:
+
+`git push -u origin <topic-branch>`
+
+You may need to force push your topic-branch, however this MUST be
+avoided as much as possible in this stage
+
+`git push -fu origin <topic-branch>`
+
+### 8. Squash your commits
+
+Once the pull request is approved, at this stage you should squash your commits,
+making logical units, for example introducing a single feature, squashing all
+the small fixes coming from the code review.
+
+```sh
+git fetch upstream
+git rebase -i upstream/main
+```
+
+### 9. Open an `Upstream` Pull Request
+
+When the local code review is done and commit gets 2 thumbs up(+2), an
+upstream pull request is made from same topic-branch to the open source
+project for code review.
+
+Before opening it, **please ensure your branch is up-to-date with
+`main`** branch and your commits are properly formatted.
+
+```sh
+git fetch upstream
+git checkout <topic-branch>
+git rebase upstream/main
+git push -u origin <topic-branch>
+```
+
+### 10. Upstream Code review
+
+Upstream Code review is done based on the practises defined by the open source project.
+
+Nevertheless the assumption is the pull request is ready for merge to
+the upstream when the reviewrs has given 1 or 2 thumbs up (+1 or +2).
+
+### 11. Merging the code into upstream
+
+Pull request author can merge the code after PR has thumbs up or practises
+defined by the open source project. After a successful code review, `topic`
+branch is merged to `upstream`. Merging then depends on the project and is
+usually done through the web interface. Once merged, you can
+
+```sh
+git fetch
+git checkout <topic-branch>
+```
+
+### 12. Delete the branch when needed
+
+To avoid leaving unneeded branches in the repository, delete your branch if you
+don't use it anymore.
+
+Remove the topic branch remotely only
+
+```sh
+git push origin :<topic-branch>
+```
+
+Remove the topic branch locally only
+
+```bash
+git branch -d <topic-branch>
+```
+
+## git workflow for a Nordix github repo
+
+It is exactly the same process except that steps 9. 10. and 11. do not happen.
+Instead the code is merged with the internal pull request.
+
+## How to backport
+
+Sometimes you may need to backport a commit (e.g. bug fix) from a main
+branch into a stable release branch. This involves a couple of steps as
+described below. In this example, we will use `release-0.3` as the
+stable branch in to which we will backport a specific commit from the
+`main` branch.
+
+Create and checkout to a new branch (e.g. `backport_commit_x`) based on
+the stable branch (e.g. `release-0.3`)
+
+```bash
+git checkout -b backport_commit_x origin/release-0.3
+```
+
+In order to cherry-pick a specific commit(s) you want, you will need to
+identify the commit hash(es).
+
+```bash
+git log --oneline --no-merges ..main
+```
+
+prints out all the commits in the `main` branch which aren't in the
+`release-0.3` branch in a below provided format:
+
+```text
+34a036b73 random1
+d2ff718f9 random2
+d83cb0e4b random3
+d589bcfc2 random4
+b9a16e24e random5
+eface850b random6
+```
+
+Here you need to take a copy of a SHA (e.g. `eface850b` for random6) of
+the specific commit that you want to backport into the `release-0.3`
+branch.
+
+Once you know the SHA of the commit, you can cherry-pick that commit.
+
+```bash
+git cherry-pick -x eface850b
+```
+
+If you have conflicts you will need to fix them first and then run the
+below commands before you push.
+
+```bash
+git add .
+git cherry-pick --continue
+```
+
+If you don't have conflicts or you have already fixed them, then go
+ahead and push your commit.
+
+```bash
+git push origin backport_commit_x
+```
+
+During the PR submission on the Github UI, make sure that you have
+selected the right target branch, which in our case is `release-0.3`
+branch.