From ee96a5220c4837350efcf261cf2f882f4836c067 Mon Sep 17 00:00:00 2001 From: Lajos Nagy Date: Fri, 12 Jan 2024 10:23:03 +0000 Subject: [PATCH 1/5] Add contact sales link to BYOC ```2. Obtain an API key to pull Quix Platform containers In this step you will be receiving a username / API token and docker registry URL. These will be provided to you by Quix before you start the installation process. Contact sales``` Looks something like this. --- docs/byoc/installation.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/byoc/installation.md b/docs/byoc/installation.md index 8151fdb0..776fe42f 100644 --- a/docs/byoc/installation.md +++ b/docs/byoc/installation.md @@ -25,6 +25,8 @@ Quix recommends a production ready Kubernetes cluster, with HA control plane and In this step you will be receiving a username / API token and docker registry URL. These will be provided to you by Quix before you start the installation process. +    [Contact sales](https://share.hsforms.com/1iW0TmZzKQMChk0lxd_tGiw4yjw2) + ## 3. Obtain a copy of the Quix Platform BYOC installer (Ansible Recipe + Docker Image) With the provided API key you can download the installer from our private Container Registry. The installer is a Docker image that contains an Ansible recipe and all the required dependencies to run it. This way you don't need to install Ansible (and its particular Python version dependencies), Helm and all the other programs and libraries required to run the installer. We have packaged it all to offer a turn-key, convenient experience. From 92c458cd6710a1667011c6af45463b547646fa26 Mon Sep 17 00:00:00 2001 From: Lajos Nagy Date: Fri, 12 Jan 2024 10:36:22 +0000 Subject: [PATCH 2/5] Specified that Kubernetes needs to run on AMD64 - Specified that Kubernetes needs to run on AMD64 - uppercase ARM64 and AMD64 everywhere for consistency. aarch64 is usually stylized lowercase. --- docs/byoc/requirements.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/byoc/requirements.md b/docs/byoc/requirements.md index 41e21334..786b60e7 100644 --- a/docs/byoc/requirements.md +++ b/docs/byoc/requirements.md @@ -8,9 +8,9 @@ The requirements are designed to ensure that the platform will run effectively a To ensure the success of the installation process, the following essential requirements must be fulfilled: -- For running the installer: A computer capable of running Linux containers. It may be either a physical or a virtual machine. This computer should run Linux, MacOS, or Windows (using Docker Desktop or WSL), and it may have either an aarch64 (arm64, Apple Silicon in most cases) or amd64 architecture. This will only be used to run the installation scripts. +- For running the installer: A computer capable of running Linux containers. It may be either a physical or a virtual machine. This computer should run Linux, MacOS, or Windows (using Docker Desktop or WSL), and it may have either an aarch64 (ARM64, Apple Silicon in most cases) or AMD64 architecture. This will only be used to run the installation scripts. - For running the installer: A kubectl client that has already been configured to communicate with this cluster. This client must be able to communicate with the cluster from the computer running the installation scripts. -- To run the platform: A Kubernetes cluster that has already been set up. +- To run the platform: An AMD64 Kubernetes cluster that has already been set up. - Sufficient permissions to create a service account, manage limited tokens, and create new namespaces and other resources. ## Kubernetes cluster minimum requirements From 1acf195e34062757e85f634853b7b89f942875bb Mon Sep 17 00:00:00 2001 From: luisquix <120378585+luisquix@users.noreply.github.com> Date: Mon, 15 Jan 2024 14:33:18 +0100 Subject: [PATCH 3/5] Update cli.md --- docs/get-started/cli.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/docs/get-started/cli.md b/docs/get-started/cli.md index 3142e7b6..c492ba16 100644 --- a/docs/get-started/cli.md +++ b/docs/get-started/cli.md @@ -55,7 +55,7 @@ There are two ways to obtain this: Run the following command: ``` - quix workspaces get + quix workspaces list ``` This lists all workspaces in the organization, and displays the workspace ID, along with the following: @@ -112,7 +112,7 @@ quix command [subcommand] [options] To list all your deployments you would use: ``` -quix deployments get --workspaceId your-workspace-id +quix deployments list your-workspace-id ``` The information returned includes: @@ -130,7 +130,7 @@ The information returned includes: To list all your applications (in your environment): ``` -quix applications get your-workspace-id +quix applications list your-workspace-id ``` ## Obtaining output in JSON format @@ -138,7 +138,7 @@ quix applications get your-workspace-id You can return your results as JSON, rather than in tabular form. For example, to return a list of topics in an environment in JSON format: ``` -quix topic get your-workspace-id --output json +quix topics list your-workspace-id --output json ``` With some practice, you will find the usage follows a similar pattern for most commands. @@ -168,7 +168,7 @@ quix contexts use byoc To list your available contexts, use the following: ``` -quix contexts get +quix contexts list ``` ## Managing permissions @@ -190,6 +190,7 @@ Scope is hierarchical. For example, if you assign a user a role at the `Organisa Role can be one of: * Admin - complete control +* Manager - complete control except editing users, billing and organisation * Editor - sync, permissions, logs, start/stop deployments * Viewer - view only @@ -216,13 +217,13 @@ This returns your: To obtain a complete list of users in an organization, use the following command: ``` -quix users get +quix users list ``` To narrow down the returned list: ``` -quix users get | grep tony +quix users list | grep tony ``` This returns: @@ -240,13 +241,13 @@ You can also use the CLI to explore permissions. To get a complete list of users and their permissions: ``` -quix permissions get +quix permissions list ``` You can reduce the list using: ``` -quix permissions get | grep tony +quix permissions list | grep tony ``` This returns: @@ -324,7 +325,7 @@ This sets the following permissions for the specified repository and workspace: !!! tip - Repository IDs can be found by typing `quix repositories get`. + Repository IDs can be found by typing `quix repositories list`. From 11ebfa83229e18c0dc196785eaeee056117794eb Mon Sep 17 00:00:00 2001 From: luisquix <120378585+luisquix@users.noreply.github.com> Date: Mon, 15 Jan 2024 16:31:25 +0100 Subject: [PATCH 4/5] More detailed role explanation --- docs/get-started/cli.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/get-started/cli.md b/docs/get-started/cli.md index c492ba16..42adfcd3 100644 --- a/docs/get-started/cli.md +++ b/docs/get-started/cli.md @@ -189,10 +189,10 @@ Scope is hierarchical. For example, if you assign a user a role at the `Organisa Role can be one of: -* Admin - complete control -* Manager - complete control except editing users, billing and organisation -* Editor - sync, permissions, logs, start/stop deployments -* Viewer - view only +* Admin - Total control over all organizational aspects, user management, and system settings. +* Manager - Moderate administrative capabilities, with access to manage profiles, workspaces, and content. +* Editor - Limited editing rights, able to update workspaces and content, with restricted management access. +* Viewer - Basic viewing permissions for profiles, content, and workspace information, without editing rights. Roles are assigned to specific users. From 06cb4910e7b0a5f9232aafb523bf7648caf34013 Mon Sep 17 00:00:00 2001 From: luisquix <120378585+luisquix@users.noreply.github.com> Date: Mon, 15 Jan 2024 18:41:37 +0100 Subject: [PATCH 5/5] Shorten role descriptions --- docs/get-started/cli.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/get-started/cli.md b/docs/get-started/cli.md index 42adfcd3..95a932a0 100644 --- a/docs/get-started/cli.md +++ b/docs/get-started/cli.md @@ -189,11 +189,11 @@ Scope is hierarchical. For example, if you assign a user a role at the `Organisa Role can be one of: -* Admin - Total control over all organizational aspects, user management, and system settings. -* Manager - Moderate administrative capabilities, with access to manage profiles, workspaces, and content. -* Editor - Limited editing rights, able to update workspaces and content, with restricted management access. -* Viewer - Basic viewing permissions for profiles, content, and workspace information, without editing rights. - +* `Admin` - complete control +* `Manager` - complete control except editing users, billing and organisation +* `Editor` - same as `Manager` without permissions of create or delete Repositories and Workspaces +* `Viewer` - read only permissions + Roles are assigned to specific users. ### Users