Wpb 22590 1 wiab staging#101
Wpb 22590 1 wiab staging#101mohitrajain wants to merge 4 commits intowpb-22590-0-planning-updatefrom
Conversation
mohitrajain
force-pushed
the
wpb-22590-0-planning-update
branch
from
5e8d3a3 to
ab96ac5
Compare
mohitrajain
force-pushed
the
wpb-22590-1-wiab-staging
branch
from
f6c5524 to
bd7f906
Compare
| ## Introduction | ||
|
|
||
| **Wire in a Box (WIAB) Staging** is a demo installation of Wire running on a single physical machine using KVM-based virtual machines. This setup replicates the multi-node production Wire architecture in a consolidated environment suitable for testing, evaluation, and learning about Wire's infrastructure—but **not for production use**. | ||
|
|
There was a problem hiding this comment.
As a reader i read it kind of. similar to production but it does not establish the core operator intent:
staging should mirror production as closely as practical, within the limits of a single-host KVM setup.
It sounds like another demo installation where it is s staging guideline.
There was a problem hiding this comment.
We can remove the demo word from the definition and replace it with staging.
| **Wire in a Box (WIAB) Staging** is a demo installation of Wire running on a single physical machine using KVM-based virtual machines. This setup replicates the multi-node production Wire architecture in a consolidated environment suitable for testing, evaluation, and learning about Wire's infrastructure—but **not for production use**. | ||
|
|
||
| > **Important:** This is a sandbox environment. Data from a staging installation **cannot be migrated to production**. WIAB Staging is designed for experimentation, validation, and understanding Wire's deployment model. | ||
|
|
There was a problem hiding this comment.
This is obvious, isn't it? It seems we are telling users in multiple places, don't do this. If we are not certain that the user understand what is staging and prod env means, I would suggest to create a reference for these terms.
There was a problem hiding this comment.
This note is to remind that staging to production migration isn't possible and a user should start with a staging setup and then plan for production setup but the initial staging can't be converted to production.
We have created a section below ## Relation to production to make it more clear.
| - [Calling services](../../understand/overview.md#calling) will share the same k8s cluster as Wire stateful services hence, all infrastructure will be DMZ (De-militarized zone). | ||
|
|
||
| If you need a fully supported, highly-available, multi-datacenter deployment, use the **Production** path instead (see `ansible-VMs.md` and `helm-prod.md`). | ||
|
|
There was a problem hiding this comment.
What if the suggested staging env (hardware/network infra etc) is enough for a user to run their prod setup?
There was a problem hiding this comment.
As per the definition of production a staging doesn't satisfy the condition, Hence we are specifying why a staging is not a production:
- no HA, single failure domain
- no network security against wire-components
- limited wire-calling capacity
A user should never think that a staging is production.
src/how-to/install/wiab-staging.md
Outdated
| - **kubenodes (kubenode1, kubenode2, kubenode3):** Run the Kubernetes cluster and host Wire backend services | ||
| - **datanodes (datanode1, datanode2, datanode3):** Run distributed data services: | ||
| - Cassandra (distributed database) | ||
| - PostgreSQL (operational database) |
There was a problem hiding this comment.
What is operation database and distributed database here?
There was a problem hiding this comment.
The intent was to mention distributed (all nodes equal) and operational (Primary RW and secondary RO) nodes. I will remove it to avoud confusion
| ## Getting the Ansible playbooks | ||
|
|
||
| > **Note:** If you prefer to manage VMs yourself with another hypervisor, you can skip this step and instead create the VMs manually with the specs shown above. Along with VM creation, you need to perform a few more steps like downloading the [wire-server-deploy artifact](planning.md#artifact-bundle-and-offline-deployment) and [setup network configuration](#network-traffic-configuration) including the firewall rules. | ||
|
|
There was a problem hiding this comment.
after downloading the artifact, the user can run offline-vm-setup.sh too.
Why we would suggest a user to clone the repo when we have delivered the artifacts and capable of running the deployment.
Its not a contribution guidelines usually where it as asked to clone/fork etc.
There was a problem hiding this comment.
Clone or fork are not necessary, we are sharing the guide to download the ansible playbooks via wget (https://github.com/wireapp/wire-docs/pull/101/changes#diff-ffa83634d14fb8bd04fd337b1199e4d77d12e05ead894298c030d349987a6edbR92) to whole repository.
There are 2 ways of installation possible here:
- A user choose to use our Ansible playbooks to setup VMs (and required packages before hand) and also download the artifact, then create an inventory based on the VMs created above.
- A user creates their own VMs using their own hypervisor, they can manually download the artifact, manually edit the inventory file and then continue with the next steps.
The first step requires user to download the ansible playbooks before hand.
A user can run the script https://github.com/wireapp/wire-server-deploy/blob/master/bin/offline-vm-setup.sh directly but the user would still be required to install all the required deb packages on the machine to enable the VM creation. Then user would be required to edit the inventory manually. At the end user would be required to setup the firewall (nftables) rules manually if not using the ansible playbook.
2 participants
Change type
Basic information
Testing
Tracking