This page clarifies definitions of components.
Cluster: A collection of machines. Type: Control plane of workload nodes.
Control plane (main node): They are machines that run K8S of the master type. Users do not have access to these machines.
Workload nodes (worker node): It is the place where applications created by users or managed services are run.
Account: Represents a user in the system.
Organizations: Person or group of people focused on one or more objectives.
Project: Set of activities to deploy an Application.
Profile information: User’s personal information and preference settings within Cuemby Cloud Platform.
Email verification: If you forgot your password, a verification code will be sent to thee mail address that is registered with Cuemby Cloud Platform to reset the password.
Two-Factor Authentication: Security measure that adds a second layer of protection to the initial password.
Re-invite user: When a User exceeds the time to accept or decline the invitation to collaborate in a Project or Organization, you have to re-invite the user again.
Reassign user to another role: Assign another Role to a User when you want to delete the role that they are currently assigned.
Invitation expired: Invitation to a user expires if they do not accept or decline the invitation to collaborate in a Project or Organization in 30 days.
Role: Roles and Permissions are predefined (developer and stakeholder) when a project is created, but the Organization’s designated administrator can create the ones they consider.
Permission: Basic access control unit given to a Role or group of Users to perform certain actions or access in the platform. Each user can be given permissions on the organizational level as well as a project level.
Organization Permissions: Permissions on the organizational level that can be given regardless of the assigned Role. Organization level permissions include access to Projects, Integrations, Payment Methods, Billing, Roles, Users, Blockchain and Audits.
Project Permissions: Permissions specific to a particular Project.
Project Permission Includes Metrics and Logs under Performance, Nodes, Agents and Storage under Provisioning, Applications, Environments, Workflows and Runtime under Pipelines, and API Tokens.
Manage devices: information of the Devices that you used to sign in on Cuemby Cloud Platform
Environment: A space to deploy aplications and it is associated with a team. In Kubernetes terms, it is a namespace<accountId_teamId_name>. An Environment has an associated Resource.
Performance: Identification of resource use of each Environment or Runtime.
Resource: A combination of CPU and RAM, which will be assigned to a Runtime.
Metrics: Collection of data on the historical consumption of Application resources of a Runtime or Environment over a specific period of time.
CPU: Processing capacity, measured in Milicores.
RAM Memory: Memory capacity, measured in Megabits.
Disk usage: Persistent storage space allocated to an Application.
Network: The internal and external traffic of the Runtime that are tabulated in specific time intervals, measure in Megabytes.
Logs: They are the console outputs of the Runtime that are running inside a Runtime or Environment. Logs are records that provide a chronological account of activities such as action and error messages from Applications deployed by Environment or Runtime.
Pipelines: Connection and automated sequence of actions and processes to build, test and deploy an Application. In Cuemby Cloud Platform, users are able to add custom tasks to Pipelines while creating a Runtime.
Application: A manifest file that is extracted from a repository of the Application defines how the Application should run, including resource requirements, networking, the number of replicas etc.
Environment Variables: Application configuration variables that can be accessed by the Application during Runtime. They consist of a Key and a Value. In Cuemby Cloud Platform, users can choose to encrypt sensitive Environment Variables
Key: The name of a Variable.
Value: The value of a Variable.
Encrypt: It is a Variable property that indicates if the data is sensitive. In Cuemby Cloud Platform, Users can choose sensitive variables to be encrypted.
Port: Port through which the Application is going to be exposed.
Repository: Git Repository where the source code of the Application is stored and managed.
Traffic: Type of connection that an Application has. There are three types of Traffic that users can specify using Cuemby Cloud Platform. Internal Traffic is a traffic from the namespace and allows no access to and from the outside. External Traffic allows ingress and egress.
Cool Down Period: How many seconds to wait before scaling down when you no longer need to have as many replicas. Default to 30 seconds.
Polling interval: The interval in seconds the platform should be checking if the Application is complied with the scaling strategy the users have specified. Default to 30 seconds.
Min Replica: Minimum number of replicas to run when the Application is running below the CPU and the Memory Rules and does not need to scale. Default to 1 unit.
Max Replica: Maximum number of replicas to run when the Application is running above the CPU and the Memory Rules and needs to scale. Default to 2 unit.
Instance Type: Capacity of resources assigned to the execution of an Application where you have a CPU and RAM allocation.
Runtime: An environment where an Application is designed to run within.
Branch: A Branch used to download the code to create the Runtime.
Buildpack: Cuemby Cloud Platform asks if a Docker is present so that the platform can use the Buildpack image to build the Application or use the Dockerfile from the Repository.
Healthy application: Status of the running service and how it is receiving requests. Users need to select from HTTP, GRPC, TCP and Command.
Cloud Provider: Provider that offers scalable computing resources that can be accessed on demand over a Network.
Node: Number of machines that will be created in the selected Cloud Provider.
Pending integration (in create Runtime): When a user removes an Integration with a Git Provider, the main Runtime screen indicates this status “Pending integration.” A status indicated in an Application when an Integration was previously removed.
Rebuild: Rebuild a Runtime using the same configurations that Users have created. It is used when some changes were made to the Git Repository, and you want to incorporate those new changes to the Runtime.
URI or URL: The endpoint to access the Application.
Status: The Application status.
Run Application (view): A Complete flow to deploy a Runtime. Steps include Application configuration, Environment set up and Runtime deployment.
Pipeline: Collection of Tasksthat are executed inside a Runtime for the deployment of the pplication.
Task: Collection of steps with the purpose of creating the resources for the execution of the deployments.
Step: Steps that are followed to complete a Task (eg. Docker runtime that runs a command).
Custom Pipeline: Additional Tasks in the pipeline execution for Runtime deployment.
Before Deployment: Tasks to be executed prior to the default tasks for Runtime deployment.
After Deployment: Tasks to be executed after the default tasks for Runtime deployment are finished.
Audit: Overview of activity, status and security of a Project.
Vulnerabilities: Risks or security breaches detected automatically when compiling an Application.
Most Active: Active services of the Application show in order.
Repository: Git Repository where the source code of the Application is stored and managed.
Integration: Currently, an Integration is to establish a connection between Cuemby Cloud Platform and a Git Provider for deployment automation.
Workspace: A Personal or Organization repository. If nothing is specified, Cuemby Cloud Platform creates a personal Workspace by default.
Provider: A Git Provider that Cuemby Cloud Platform currently supports (GitHub, GitLab, Bitbucket).
Payment, Billing and Subscription
Payment Method: A method to pay for the platform usage of the Organization. Users can add multiple Payment Methods and apply a different one to each Project. Currently, credit cards are the acceptable Payment Method on the platform.
Billing Report: A historical platform usage data of an Organization displayed by Projects.
Reference Number: An optional reference number for a Billing Report that shows the Organization’s usage of a specific month and a year by Project. The Reference Number can be a Tax ID.
Subscription: A subscription plan in which users can set a budget for each Project. Available Subscription types are Pay As You Go or Bring Your Own).
Pay As You Go (PAYGO): A subscription plan that allows users to pay for the Workload they consume each month. It is charged per Workload per hour. No long-term commitment.
Bring Your Own (BYO): A subscription plan charged by the Number of Nodes that the platform manages. Users bring their own Cloud resources. It is charged by the Number of Nodes per month.
Notifications and Alerts
Notification: A push message that is displayed on the platform according to what is configured by the User.
Alert: A notification or warning to inform users about specific events or issues that require attention.
Report a bug: Detailed reporting of an error found in the platform.
FAQ: A list of Frequently Asked Questions.
Tutorials: Short instructions and explanations of a particular topic.
API Token: Used to authenticate within the Application to make requests.
Expiration date in API Token: Default expiration of 30 days, however the duration can be modified.
Enable in API Token: Users can select to activate or deactivate the Token for more security
Regenerate API Token: Regenerate a new API token with the same Permissions and Roles.
End-user license agreement: Legal contract between Cuemby (a software provider) and a customer or end user.
Blockchain: Distributed digital ledger technology.
Technology: A framework or Blockchain technology on which you want to build the infrastructure.
Type: Type of blockchain network that users would like to build; currently, only private network is permitted to build on the platform.
Domain: A name or domain of the Corporation that will be part of the Hyperledger Fabric network that is being.
Admin User: A username of the administrator of the Corporation within the Hyperledger Fabric network.
Admin Password: Password of the administrator of the Corporation within the Hyperledger Fabric network.
Chaincode: Code that defines business logics and transaction rules.
Corporations: In Hyperledger Fabric, they are "Organization Memberships" that contribute resources and assets to the network. They are different from Organizations defined in Cuemby Cloud Platform.
Channel: In Hyperledger Fabric, a "channel" is a private and secure communication channel between selected members of the network, where they can exchange transactions confidentially without being visible to all participants.
MSP: MSP stands for "Membership Service Provider" in Hyperledger Fabric. It is responsible for managing the identity and cryptographic certificates of the members of a Corporation to enable their participation in the Blockchain Network.
CA: Certification Authority in Hyperledger Fabric, which issues, manages and revokes cryptographic certificates for network members.
Peers: Nodes in the Hyperledger Fabric network, which maintain a copy of the ledger and execute Chaincodes.
Orderers: Nodes responsible for accepting and ordering transactions before adding them to blocks in Hyperledger Fabric.
Docker Image: It is a Docker image containing the Chaincode's code, its dependencies, and the Runtime Environment, allowing it to be deployed and executed in containers.
Image: A Docker image used to execute the Chaincode in an isolated and portable Environment, ensuring consistency across different nodes in the Hyperledger Fabric network.
Name (Invite user): Name of the user to invite to the Hyperledger Fabric network.
Email (Invite user): Email of the user to invite to the Hyperledger Fabric network.
Name (Create HLF Channel): Name of the channel to create within the Hyperledger Fabric network.
Corporations (Create HLF Channel): Corporations that will make up the channel to be created within the network.
Domain: The domain where the API of the The Power’s nodes will be exposed. By default it will point to the chains.cuemby.io domain at this moment.
Number of Nodes: Number of Nodes that the shard will have.
Crosschain Externals: They are optional and used to connect to Nodes of different shards of the Power through their Host and Port.
Host (Crosschain The Power): Host of The Power’s external shard node to connect. (ex: c1n1.alpha.cuemby.net).
Port (Crosschain The Power): Port of the External Shard Node to which it is going to connect (eg: 4243).
Nodes (Crosschain The Power): Nodes of the Shard to create, in which you want to establish a connection with the External Chain specified in Host and Port.
Type: Shards, which are, in theory, fragments of a Blockchain.
Tpic Port: Node interconnection protocol. It describes the way the Nodes search for each other and connect to each other. For the first connection you need at least one Node.
Api Port: the external interactions protocol.
Apis port: Secured external interactions protocol. SSL-certificate is required to use Apis.
RPC port: "RPC Port" refers to the Port Number used for Remote Procedure Call (RPC) communication. RPC is a protocol that allows a program on one computer to execute code on a remote system over a network.
Chain type: Type of Blockchain Network; Public (permissionless) and Private (permissioned).
Nodes: Active participants in the network that validate transactions and maintain the integrity of the Blockchain.
Number of Nodes: These may vary depending on the configuration and goals of the network. A Network with more nodes can process more transactions and be less vulnerable to malicious attacks, but each node adds additional resource cost.
Node name: The name assigned to a Node in the Substrate network.
Port: Network port used to connect to a Substrate node through the Internet.
WS Port: An External port that allows connection via WebSocket API (eg: 9933).
RPC Port: A Network port used to connect to a Substrate node through a Remote Procedure Call (RPC) API.
Node Role: Assign a role to the node. Currently, Full, Light and Validator are available.
Node Role – Full: Full Nodes maintain a copy of the transaction history and current state. They also validate transactions, execute smart contracts an store all the data necessary to maintain the network.
Node role - Light: Light Nodes consume less storage an dbandwidthe compared to full Nodes by relying on other Nodes to provide them with specific data when needed. Suitable for resource constrained Applications.
Node Role – Validator: Validator Nodes validate transactions and add them to the Blockchain to maintain the network's security and integrity.