Skip to content
Merged

Dev #243

Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/byoc/installation.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 2 additions & 2 deletions docs/byoc/requirements.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
29 changes: 15 additions & 14 deletions docs/get-started/cli.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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:
Expand All @@ -130,15 +130,15 @@ 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

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.
Expand Down Expand Up @@ -168,7 +168,7 @@ quix contexts use byoc
To list your available contexts, use the following:

```
quix contexts get
quix contexts list
```

## Managing permissions
Expand All @@ -189,10 +189,11 @@ Scope is hierarchical. For example, if you assign a user a role at the `Organisa

Role can be one of:

* Admin - complete control
* Editor - sync, permissions, logs, start/stop deployments
* Viewer - view only

* `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
Expand All @@ -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:
Expand All @@ -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:
Expand Down Expand Up @@ -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`.



Expand Down