Uniview
Total OpenStack Frontend and Monetization Solutions
Univew is a comprehensive frontend solution providing out of box support for use cases of OpenStack based public clouds or premium enterprise private clouds. Uniview is visioned to enrich open source ecosystem that tackles the needs of last mile engineering of Open Infra Foundation i.e. OpenStack from technology ready to be business ready and viable.
- Current Version: 2024-october
- Upstream compatible: OpenStack Caracal (2024.01)
- Created: 16 August, 2023
If you have any questions that are not clued in this current help file, please feel free to Email or online form Contact.
Quick Start
For quick start, you will need a linux server with Docker, docker-compose and Mysql Server installed.
The step by step process
- Prepare OpenStack Keystone and gather access info
- Prepare Mysql or MariaDB database on your database server.
- Edit your docker-compose file with minimal information and use Uniview public accessible image
- Run and Access
The minimal info of OpenStack:
"keystone_auth_url": "http://192.168.1.11:35359",
"os_interface_type": internal
"os_auth_user": "uniview",
"os_auth_pass": "pass",
"os_auth_project": "uniview",
Go to the detail for more guides of user and role creation!
# mysql
CREATE DATABASE uniview;
CREATE USER 'uniview'@'%' IDENTIFIED BY 'your_pass';
GRANT ALL PRIVILEGES ON uniview.* TO 'uniview'@'%';
exit
version: '3'
services:
uniview1:
image: computingstack/uniview-openstack-frontends:latest
ports:
- "3006:3006"
healthcheck:
test: curl --fail http://localhost:3006/getVersion || exit 1
interval: 60s
retries: 5
start_period: 20s
timeout: 10s
environment:
db_host: 192.168.1.1
db_user: uniview
db_password: your_pass
db_database: uniview
keystone_auth_url: "http://1.1.1.1:5000"
os_interface_type: public
os_auth_user: uniview
os_auth_pass: password
os_auth_project: uniview
deploy:
restart_policy:
condition: on-failure
delay: 5s
#max_attempts: 3
window: 120s
restart: always
docker-compose up -d
curl -v localhost:3006/getVersion
{"tag":"2024-january","build_info":"xxxx","edition":"public_cloud"}
As a quick start, Uniview may not be able to get started by 'docker run xxxx" due to cluster and threading technologies!
Installation
To install Uniview is as simple as a few steps! The easy way is to clone a prepared install artifact from https://github.com/ComputingStack/Uniview-OpenStack-Portal.git and provide basic necessary configuration, then start!
Prerequisite
The minimal requirement of Uniview is to have Keystone running, and the system can advance to high complex configuration in a progressive manner. Below is an overall view that you may encounter to have those along your development process.
- The OpenStack cloud backend is up and running. The minimal requirement of backend is to have keystone up.
- A MySQL or MariaDB database engine is up and running. When Openstack controller database is Mysql or MariaDB too, it is highly recommended to create your Uniview database on the same server.
- Option 1: Docker host with docker and dockerfile installed
- Option 2: Kubernetes cluster is ready to host the said docker, as the only form factor of Uniview Cloud Portal packaging is docker image.
- If Uniview monitoring is enabled, see chapter 3 “Uniview Monitoring Preparing”
- Optinoal OpenStack backend API policy may be adjusted to accommodate user self-enrollment, and other functions.
- Optional backend configurations may be needed to support feature such as Application Credential, MFA, SSO, dashboard and other functions. For details, please consult computingstack support team!
- Optional DNS for the portal to be ready, such as mycloud.computingstack.com
- Optional Payment Gateway API token is generated
- Optional KeyCloak and Keystone are configured to allow Uniview origins
- Optional Google reCAPTCHA v2 site key bound to the above DNS to protect from abuse use of User registration and Look back the password. see how it works at: https://developers.google.com/recaptcha/docs/display
- Optional csr certificate to support https of portal rendering, such as https://mycloud.computingstack.com
- A user is created
The step by step process
- Git clone the install artifact at a console or the host where the Uniview Docker service runs.
- Prepare OpenStack Keystone and gather access info
- Prepare Docker Host where the Uniview docker service will start
- Prepare Mysql or MariaDB database. Full details jump here
- Prepare necessary user, project and role etc. Here is the details
- Access your docker images
- Install as your choice, by Ansible, by Dockerfile or over Kubernetes
- Optional to customize such as logo, business title, email engine and others
- Optional to configurre your monitoring when needed
git clone https://github.com/ComputingStack/Uniview-OpenStack-Portal.git
The minimal info of OpenStack:
"keystone_auth_url": "http://192.168.1.11:3539",
"os_interface_type": internal
"os_auth_user": "uniview",
"os_auth_pass": "pass",
"os_auth_project": "uniview",
Go to the detail for more guides of user and role creation!
One or multiple standalone docker hosts need be prepared. One most important information is the timezone setting of those hosts which should be aligned with your database (i.e. Mysql) in below instances. Billing cycles and many time picks on Uniview will be by default superceded by the timezone of the host of docker engine and database. If they are not fully aligned, timezone, pricing policy and billing information may show up in a messed up way.
A major factor of Mysql as stated in above item, is its timezone that should be aligned with the docker hosts where Uniview runs
Uniview provides only a customer dedicated image. If you don't have yet, please contact to get your build and access info. Once you get the access, follow below instructions:
$ # when over centos/RHEL
$ sudo yum install awscli
$ # when over Ubuntu or other Debian OS
$ sudo apt install awscli
# Provide access key and access key id at prompt
$ aws configure
$ aws ecr get-login-password --region ca-central-1 | docker login --username AWS --password-stdin 801557913156.dkr.ecr.ca-central-1.amazonaws.com
# your credentials are stored in your home directory in .docker/config.json. The password is base64-encoded in this file.
$ docker pull account_id.dkr.ecr.ca-central-1.amazonaws.com/computingstack-uniview-xxxx:2023-july
Sign in Uniview with a user with "admin" role, then from the vendor console, those info can be easily configured through UI. Since the UI is intuitive, the document doesn't detail the process.
Prepare OpenStack Keystone
Keystone user, role and project shall be created beforehand for proper uniview boot up!
Depending on the use case, the minimal requirement is to have a user with admin role created that Uniview will use to detect the OpenStack capability, capacity etc. For advanced use case, a projectadmin role needs be created in case user inviting and other other functionalities are needed in your deploy!
Below scripts are one example
#create uniview service user
source openrc
openstack user create --domain default --password-prompt uniview
openstack role add --project service --user uniview admin
#add necessary role projectadmin
Openstack role create projectadmin
Openstack role create user
For user federation supported deployment, keystone needs be configured with:
trusted_dashboard=https://uniview-url/sso-login
Prepare Database
A database and database user for Uniview shall be created. Please check that there is good connectivity from the host where Uniview runs to the database host on the designated port
For Uniview install, you will need a Mysql server running. The current guides do not provide install process of my MySQL Server. Among many internet guides, here is one example
It is highly recommended to have high availability ready for this database engine for a production deploy at user’s diligence!
Uniview database size is expected to have moderate growing over time. Once database server is up, Uniview will require a database and a user granted to which. Below script will create database and user, and grant the least permission docker services require.
# mysql
CREATE DATABASE uniview;
CREATE USER 'uniview'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON uniview.* TO 'uniview'@'%';
exit
For the event created by Uniview, it is timezone sensitive when data are saved in the databse. To avoid time messed display on Uniview, the database should explicitly set with its timezone if it's not. Below scripts are example of checking and setting.
# mysql
SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;
+--------------------+---------------------+
| @@GLOBAL.time_zone | @@SESSION.time_zone |
+--------------------+---------------------+
| SYSTEM | -04:00 |
+--------------------+---------------------+
# if it shows none
mysql> set time_zone = '-4:00';
Query OK, 0 rows affected (0.00 sec)
Install by Ansible
Uniview can be installed by ansible, especially when Uniview is co-located in the Kolla Ansible host
It's recommanded to share the same HAProxy of you controller if Kolla Ansible deploy is your situation or any standalone load balancer will work too. Full detail can be found in install artifacts
Install by Docker-compose
Uniview can be installed in a standalone Linux with general docker daemon. However the high availability by load balancer will be fully on your administrator to create those LB and configure.
Full detail can be found in install artifacts
Install Over Kubernetes Cluster
As generic docker distribution form factor, Uniview can be seamlessly deployed in any a Kubernetes cluster.
Full detail can be found in install artifacts
Prepare Monitor Agent
Uniview will require agent to collect metric data from monitoring purpose. Depends on what to monitor, some monitor agents will be required, and there can be some other necessary access info that is rquired too.
Computingstack has chosen open source based agent solution, and provided Ansible script to have those agents installed and configured. For further details, see OpenStack Monitor Guides
Branding and Customization
Without code change, Uniview can support many customizations such as branding logo, business title, theme and primary color etc through configurations and database manipulations.
Cloud Console
Cloud console is the core OpenStack management console where Openstack users manage project level resource, such as instance, Kubernetes cluster, swift container etc.
For other application entry for major grouping:
App Entries(1) are grouped per the purpose at high level for the monitoring, general user daily entry, administrator and supports. The search bar (2) will detect sub-entries for lookup and will be limited by the app level entry however!
Cloudwatch
Cloud watch provides project level dashboard, metrics, alerts and other utilities
Compute
Cloud watch provides project level dashboard, metrics, alerts and other utilities
Kubernetes
Uniview comes along with full lifecycle management of Kubernetes Cluster that is backed by Magnum, and full Kubernetes dashboard for workloads.
Database
Cloud watch provides project level database as a service console
Storage
Cloud watch provides project level volume storage, and object store management
Venbor Zone (OpenStack Monitor and Uniview Settings)
Vendor Zone is often customized by the title of a cloud provider name, for example, when business is SuperCloud, the vendor zone will show up in the Uniview as "SuperCloud Zone". Vendor zone contains utilities for the service provides to monitor OpenStack healthy state and other necessary setting for Uniview itself.
Vendor Zone is limited to be accessible only to the users with "admin" role. For different layout of permission, please ask for customization on demand!
Vendor Dashboards
Entry: Application entries->Vendor zone->Vendor Dashboard.
Vendor Dashboard provides administrator a quick overview of the major OpenStack services from monitoring point of view! Vendor dashboard aggregates those state check and key metrics of:
Hosting Bare Metal Server Monitoring
Entry: Application entries->Vendor zone->Hosting Servers.
Check any a single hosting server, in the "select to display" window, more details will be provided, such as overall status, disk and storage information etc. There are 6 metrics boxes that display the metric change over the time. The detail matrics.
OpenStack Controller Rabbit Mq Monitor Console
Entry: Application entries->Vendor zone->OpenStack Controller Database.
Controller Rabbitmq metric provides selected metrics of below. And more metrics will be provided on demand.
OpenStack Controller Database Monitor Console
Entry: Application entries->Vendor zone->OpenStack Controller Database.
Controller database metric provides selected metrics of below. And more metrics will be provided on demand.
Customization by Configuring Portal Properties
Entry: Application entries->Vendor zone->Portal Properties.
Critical attributes of portal for the display or daily operations are part of portal properties. Most of them them can be controlled and configured at Vendor Zone with administrator access.
Change on any portal proproperties will require all Uniview docker daemson to restart to pick up new values!
Administrator
Administrator entry of Uniview combines various day to day operations that an OpenStack administrator is concerned with. Those features include such as User, Project and Role management, administrator capacity management etc.
Administrator Entry aggregates those functionalities of general OpenStack adminstrator activities from communities upstream, such as Hypervisor, Project, Role, Volumen Type, Volume Encrption etc. The targets of the administrating are those generic OpenStack backends. In compare with Vendor Zone, Vendor Zone implements enterprise processes that normally are not found from communities such as Horizon, such as monitoring, dashboard etc.
Public Cloud Guides
Uniview is designed to have considered its user as from a non-trusted 3rd party organization such as public cloud tenant. Hence the process, user segregation, billing and payment have been in place to serve pubic cloud use cases. Besides that Unview provides the utilities to support daily operation for a public cloud administrator. As far as Public Cloud is concerned, the major activities include bill aggregation and generation, collecting payment, invoice management, Payment Gateway management etc.
User Onboarding Process over Uniview
Unview provide full process of user recruiting for the public cloud use cases. The major utilities including a free online user registration user interface, password resetting, Email based notification and confirmation, payment method user editing etc. Entire process can be management free and all can be conducted through user self-service.
The Process of a User onboarding:
The way to configure Uniview to have second validation of pay method before enabling a user project is done through manipulating portal properties at database as below. Since this is one time activity, no console is provided.
# mysql
INSERT INTO portal_properties (property_key_name, property_key_value, property_key_type )
values ('user_register_project_initial_status', 'enabled', 'string');
# in case the property row exist:
UPDATE portal_properties set property_key_value='disabled' where property_key_name='user_register_project_initial_status';
User Onboarding Process is highly protected by security setup, such as HTTPS and Fraud Prevention. Hence administrators are required to setup following Security guides for the setup before a user can be registered!
User Onboarding Process through Keycloak
When user federation through KeyCloak is selected, the full process of user registration by KeyCloak will be the primary registration process. Over that Uniview complements Keycloak process by its landing portal to provide necessary payment filtering, permission grant and other utilities.
The Process of a User onboarding with Uniview+Keycloak:
For SSO and Uniview user federation, there might be some Uniview configurations required. For details, see Security Guides -> SSO User Federation
Keycloak as open-source solutions, has many references of customization for branding and registratin process, and the details will not be repeated here! Instead the official document provides a good guides on many of those
Metering by CloudKitty, Gnocchi and Ceilometer
When user has Ceilomter+Gnocchi+CloudKitty installed at backend, Uniview has a seamless support of data produced by those components for bill aggregation, payment and invoice!
Uniview generally works with generic installs. For the details of installing and administrating, see Open Infra official documentations!
By default Uniview is configured to support Metering/Rating of CloudKitty
Metering by Uniview-Collector
Uniview-Collector is an independnt docker service that collects events of instance/volume/floating IP lifecycles and scans the inventory periodically to form a billing database.
For those OpenStack deploys that Ceilomter/Gnocchi/Cloudkitty are not installed, Uniview collector can generate consumption data for billing purpose! Uniview collector works in the way of scanning the inventory, and listening to the message bus of RabbitMq for full lifecycle events of billable objects, e.g. Instance, Volume and Floating IPs. Other possible billing objects metering beyond those three can be extended on demand.
When OpenStack is multiple regions deploy, multiple Uniview-Collector needs be deployed per region and close to OpenStack region's Controller. All collectors will post data to a centralized Uniview database, and there is no need for regional database. From the docker host, it requirs connectivity to the Rabbit host on the designated port.
Uniview collector is optimized to produce moderate data, hence the storage space of Uniview DB is expected to grow moderately only. To compare Gnocchi or Prometheus based time serized database, only a small portion of corresponding data will be produced by Uniview-Collector. Once bill is generated, the raw data can be safely archived or deleted to free storage.
It's highly recommanded to have multiple docker replicas deployed to tolerate failure. Uniview-Collector runs as a pub/sub mode, so that there is no worry of data duplication at many replica cases. Events record loss, in case no collector service up at a time, the billing info can be incomplete that leads to billing incuracy of some resources.
To install Uniview collector, user would request access to the collector image. Install is fully automated with docker-compose or Ansible. The script is available at: git clone https://github.com/ComputingStack/Uniview-OpenStack-Portal.git
For administor bill aggregation, for it to consume data that Uniview-Collector produces instead of CloudKitty, a directive by portal attribute configuration is needed
insert into portal_properties (property_key_name, property_key_value, property_key_type) values( 'metering_db', "uniview-collector", "string" );
Payment Gateway
Uniview supports Stripe Payment Gateway and will support Paypal in near future. Other payment gateways can be supported on demand as part of customizations.
As a very admin accessible info, the direct database manipulation is needed to set the Stripe Payment Gateway info
Steps of setting Payment Gateway Info:
Step 1: Get the database access and start mysql Console
Step 2: insert into database table portal_properties
mysql>insert into portal_properties ( "property_key_name","property_key_value","property_key_type")
values ("stripe_server_keys", "your keys", "string");
exit;
$ #check result:
mysql> select * from portal_properties where property_key_name="stripe_server_keys";
+-----------------+--------------------+--------------------------------------------------------------------------+-------------------+--------+
| property_key_id | property_key_name | property_key_value | property_key_type | remark |
+-----------------+--------------------+--------------------------------------------------------------------------+-------------------+--------+
| NULL | stripe_server_keys | sk_test_51xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | string | NULL |
+-----------------+--------------------+--------------------------------------------------------------------------+-------------------+--------+
1 row in set (0.00 sec)
Step 3: Restart Uniview Services. All uniview services need be restarted to pick up the latest value!
Cloudkitty Conducts Pricing and Rating
Uniview supports OpenStack resource pricing and plan by user selectable options, i.e. using Uniview collector+Uniview Rating, or using OpenStack CloudKittyCloudkitty capability.
- Know Uniview dependencies on CloudKitty
- Where/How to configure plan and rating
- Cloudkitty module choice
- Billing dashboard and Pricing and Display on Uniview
- Discount and Promotion
Uniview integrates the latest solution of OpenStack Cloudkitty as the rating Engine! Once cloudkitty is configured properly (by clients), Uniview will be able to consume the data to produce bills per billing cycle with no other dependency! Cloudkitty has been considered mature and widely adopted by global cloud service providers. As it's open source generic, hence user has the advantange of esay development, cost-saving flexibility etc. Cloudkitty generates monetary unit of customer choice, and Uniview Bill Generation utility will aggregate into a bill per billing cycle
As it's generic and fully open source projects by upstream, OpenStack docs provide a full details of ratting and pricing.
Following OpenStack community guides would get Pricing and Plan defined. Modules of Hashmap and Pyscripts are both working with Uniview. For the pricing defined by Hashmap, Uniview currently can display when user browses the instance type (Flavors). When defined by PyScripts module, service providers may need other places such as Incorporate website to publish such instead. As Rating and pricing can be a one time activity for administrators, hence Uniview doesn't overwrite the functionality. Instead it's highly recommanded to have your backend scripts of CLI defining those rating or use Horizon console to do so.
Both hashmap and Pyscripts modules work, even though Pyscripts provide a better flexibilities, Hashmap can work out of box quickly for generating rating such as instance time based on flavor, Swift Storage, Volume etc.
Uniview provides users a billing dashboard showing up 'Month to date spend' 'last 24 hours spending' and prices display possibility for those defined at CloudKitty. The purpose is to increase transparency and keep customers well tuned. For both billing dashboard and billing, clients will need to access rated data info for exmaple from cloudkitty, and pricing info in general. In order to do so, cloudkitty (policy.yaml) needs be configured to open certain read only API permission to the world, so that Uniview can show up the desired info to compose user dashboard and pricing. Alternatively, cloud service provider can publish pricing info on other static website for user lookup!
Based the module selected, some customization may be needed for those other than hashmap!Discount and promotion over Uniview can be very flexibile and versatile though integration with OpenStack upstream solutions!. Cloudkitty provides various flexibilities of defining discount, and promotion per project and flavor etc to facilitating marketing compaign!
It's fully on Service Provider choice of using CloudKitty or Uniview Rating/Collector and Uniview can support both seamlessly.
Uniview-Rating Conducts Pricing and Rating
Uniview supports a concise and dependeable rating and pricing other than the approach by OpenStack Cloudkitty. The reason to have Uniview-Rating and Collector is more about the manageability and extensibility. Users may find Uniview Collector+Rating are more dependable that provide accurate and traceable billing data to avoid controvercies.
A single switch is implemented to enable Uniview Rating cron job, tune the user console and backend to use Uniview Collector and Unview Rating for billing subject. At default, they works with Cloudkitty. Uniview supports everyone two hours cron job to conduct rating to generate interim billing data and user can query at their billing dashboards.
To define a Price Plan, Uniview provides administrator a console for conviniently editing the rating plan.
- Clone Into a new price plan draft
- Insert item by item with console guides for common billing items such as Instance, Volume and Floating IP
- Activate the draft to be the active plan
For three major billing items the plan is defined to reflect the nature of the services. Each price item is defined its service, i.e. instance/volume/floatingip etc; rating type as flat/threshold, the region, value and cost. Unit name is informative and will not be used by rating module. The price item must be explicitly to the region. An item without region, Rating Module can't find its applicability.
Instance price is defined per flavor for an hour. The price item is tagged by its corresponding flavor id. When no price is explicitly defined, the price is taken as 0.
Volume has two types of price items: flat and threshold. Only one flat price is allowed. Flat is applied at all storage volume size. The threshold is a percentage on flat rate when volume size reachies the threshold. Multiple thresholds are allowed in Uniview, and the rating module will apply sequentially to find the applicability for rating a volume
Floating IP is a single flat price as cost for hour.
Activating the plan implies the plan will be applied to rating module immediately. Hence it's suggested to well plan the time when activation starts!
Bill Generation
From 2023-october, Uniview starts providing console based trigger for OpenStack administrator to aggregate billing data into project/billing cycle granular bill. The default billing cycle is per month. Other billing cycle such as bi-weekly can be provided too on customer's demand. Command based bill generation is still available too and will be decommissioned in future release!
Entry: Application entries->Vendor zone->Billing->Bill Generation.
There are two inputs to get bill generation started. One is the billing cycle of which the bill will be generated. The second is the mode of run. Run has two modes. Dry run which will print the result at the end of execution and prod run caculates and saves the bill into database. The user can browse the data that are generated in the dry run, then with confirmation, prod run can follow to generate the bill ready for billing cycle selected!
Example of Bill Generate Entry:
Collect Payment
Collect Payment can be through two approaches over Uniview. One is user initiated payment on the Unview console, and for pre-authroized pay users, Uniview provide utilities for OpenStack administrator to initiate batch payment at the end of billing cycle. Through administrator console(Vendor Zone), an admin can select the projects and a cycle to automate. Administrator console is an interactive process, so that the critical payment process is manageable and traceable! Administrator initiated payment process in Uniview provides auditability and traceability for offline or real time investagtion when there is error.
Example of Admin Pay Start: Example of Result and Investigation, and user has full record of execution for future investigation:Ticketing System
Uniview provides an integrated ticketing system for those public cloud providers so that a user can conviniently report various technical or billing issues. There is console for administrators to reply and resolve the reported issues too.
There are two entried provided. One is for general users where they can create, reply, close and re-open a ticket: Application entries->Support->cases. Another is for administrator to reply, answer, close and re-open a ticket. Administrator console shows up all the open tickets that requires attention, and user console shows up only tickets created associated with the user project!
Each reply allows one attachment to upload, and in case multiple are needed, user can choose reply to attach more than one!
An example of the ticket console as below:
The email notification is configurable on whether a outgoing email will be sent upon activities of "user reply", "administrator reply", "re-opened", "resolved". All invovled users and administrators will be included in the list of recipients!
Email Template Customization
Uniview adopts technology of EJS for all outgoing email templates, and clients can fully customize to your themes, messages and branding
An example of the ticket console as below:
The proces can be as easy as:
- Git clone the install scripts, and get the email template folder! Currently each outgoing correspondence has one ejs file that contains header, body and footer. Execpt the keys that are in bracket <%= %> which are not changeable and will be populated in real time by the system when emails are sent, all rest of text, theme, css definition can be edited to your needs.
- Get familiar with various outgoing email from the default install and based on which design yours!
- Edit the ejs file with organization specific messages, themes, logo etc by CSS
- Once the template is complete, clients need send to ComputingStack Support Team, who will do sanity check and replace those into your orgnization's dedicated image
- If the email subjects need be customized, please contact ComputingStack Support for the messages.yml editing and packacking. It's fully doable by clients with no code skill needed!
When there is need of logo, or other image to be part of an email, it's highly recommanded to use external link, such as img src="https://mycompany.com/images/logo.png", where the image is saved and publicly available!
Invoice Customize
Uniview provides a standard invoice format that is estimated to meet majority business needs
An example of an invoice generated by Uniview as below:
The minimal items to customize:
- 1. Business logo, which will be the master logo of your uniview cloud portal (top left logo)!
- 2. Business Name
- 3. Business Address
- 4. Business website
- 5. Busines note, you can put terms and consition or other notes that clients need be aware
- 6. The business bar code if there is any, that you want to provide to the public
mysql> select property_key_name, property_key_value from portal_properties where property_key_name like 'business_%';
+-------------------+---------------------------------------------------------------------------------------------+
| property_key_name | property_key_value |
+-------------------+---------------------------------------------------------------------------------------------+
| business_address | High Tech Center Kanata, Ottawa Ontario Canada K2V9P6 |
| business_email | admin@computingstack.com |
| business_name | ComputingStack Tech Inc. |
| business_phone | +1-613-400-4001 |
| business_qcode | https://raw.githubusercontent.com/edisonneza/jspdf-invoice-template/demo/images/qr_code.jpg |
| business_tax_rate | 0.13 |
| business_website | https://www.computingstack.com |
+-------------------+---------------------------------------------------------------------------------------------+
7 rows in set (0.00 sec)
When no value is found from portal properties, the invoice may show a clear space instead!
Client info on the invoice will be based on the user inputs when payment method is created, hence is not customizable!
OpenStack Monitor Guides
To support cloud monitor by Uniview, there are some configurations and agents that are needed depending on what you want to monitor.
Agents normally will be installed along with what to be monitored, such as physical hosts, or a light compute resource needed daemons that will query metrics and status from the targeted elements.
All Uniview monitoring agents are self-contained binary to run. That's being said it has no repository dependencies etc of debian APT or centos/Redhat Linux YUM, so that no conflict with underlying OS. That makes binary install safe to be installed on generic OS. However other way such as docker based install is available too
There is a private repository by ComputingStack team that a user can easily pull then run to install all the agents and daemons that are needed to monitor OpenStack resources. Either clients will be provided with this repo along the artifact package as it's very light-weight. Alternatively the repository (based on AWS codecommit) can be cloned by users themselves if user/password are provided.
git clone https://git-codecommit.ca-central-1.amazonaws.com/v1/repos/uniview-openstack-monitor
#edit env/monitor/inventory/hosts file for the necessary IP address and the access
#edit env/monitor/inventory/group_vars/all for the variables that define the monitor
#one command below is a wrapper that have all services agents installed!
cd uniview-openstack-monitor
ansible-playbook -i env/monitor/inventory/ uniview_monitor_install.yml
Baremetal Monitor Agent Install
Uniview supports baremetal monitoring out of box. The major metrics such as CPU, Ram, Network and Storage will be monitored and alerted on demand.
The baremetal node nature are one of those linux OS, such as Ubuntu, Centos or Redhat where the monitor agent will be installed.
OpenStack Service Monitor
Uniview has service detection on major OpenStack daemons such as Nova, Neutron, Cinder etc. Any any un-expected service stop will be easily reported at Uniview.
There isn't extra configuration needed for the OpenStack service monitoring, as long as a Keystone user with admin role and its password is provided to uniview booting configuration, service will be monitored by Uniview!
Ceph Cluster Monitor
Uniview out of box of Ceph Dashboard and Ceph monitoring.
RabbitMq Monitor Support
As one volunerable component of OpenStack, Uniview provide various monitoring of heathy state of Rabbit Mq.
RabbitMq monitoring support is straightforward! RabbitMq uses the prometheus plugin to collect metrics. For the OS install of RabbitMq, below command will get enabled. For other container based install with such as Kolla ansible, your container extra configuration to enable the plugin might be needed. More detailed instructions of RabbitMq monitoring are available in the install reposity!
sudo rabbitmq-plugins enable rabbitmq_prometheus
Enabling plugins on node rabbit@ubuntu07:
rabbitmq_prometheus
The following plugins have been configured:
rabbitmq_management_agent
rabbitmq_prometheus
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@ubuntu07...
The following plugins have been enabled:
rabbitmq_management_agent
rabbitmq_prometheus
rabbitmq_web_dispatch
started 3 plugins.
Database Monitor Agent Install and Configuration
Database is another volunberable component in OpenStack controller. A proper monitoring will help to identify and tackle issues before it has impact on business. In Uniview OpenStack monitoring, it provides state monitoring, and various metrics views and alerts.
Database monitor will require a daemon that collect the metric from the database. A user needs be created beforehand to talk with MySql server with permissions:
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'Password' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
When Mysql metric collector is installed on a different host from where Mysql is running:
CREATE USER 'exporter'@'%' IDENTIFIED BY 'Password' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'%';
Edit the IP of a linux machine where the daemon will be installed, then run:
ansible -i env/monitor/inventory/ install_mysql_exporter.yml
Capacity Monitor Guide
Capacity management is one of the most desireable features of OpenStack cludster. Uniview provides aggregated metrics across hypervisor, bare metal OS, OpenStack services and real time monitoring to produce a most comprehensive capacity view for cluster scaling and also cost-saving!
Alerting and Webhook
Uniview supports comprehensive alerting, alert browsing, and communications with operation team through webhook such as Email, Slack, Pagerduty etc.
If the slack is aimed as a webhook, when an alert is triggered or resolved, below variable need be present and defined as below example
For Pagerduty and email based webhook, similar variables need be defined!
# Edit env/monitor/inventory/group_vars/all, by adding blow variable of slack API URL
slack_api_url: https://hooks.slack.com/services/xxxx
Security Guides
Uniview provides a variety of security features, such as MFA, Encryption, HTTPS, reCAPTCHA, Organization Level Identify Management, Application Credential etc, so that enterprise users will have out of box tool kit to select for achieving infrastructure security without hassles.
SSO and User Federation
Uniview supports Single Sign on through integrating with Keystone and Keycloak technologies. To have best user experience, there are some configurations required!
Before Uniview is configured to support SSO, Keystone and the intended identify provider such as Keycloak should be configured. The reference of configuring such can be seen in OpenStack Docs Specifically for Uniview, Keystone needs be configured to allow:
[federation]
trusted_dashboard = http://horizon.ifneeded/auth/websso/
trusted_dashboard = http://uniview/sso-login/
Uniview user sign in pages provides two entries: entry for native Keystone user and entry for federated users. By default the entry to federated user is not enabled. To enable it, database access to insert a row of data:
INSERT INTO portal_properties (property_key_name, property_key_value, property_key_type) values("openid_federation", "1", "string");
In order to link user to edit its profile (through external identity providers other than Keystone), the identity provider profile is needed as below
INSERT INTO portal_properties (property_key_name, property_key_value, property_key_type) values("sso_default_idp", "your_idp_defined_at_keystone", "string");
INSERT INTO portal_properties (property_key_name, property_key_value, property_key_type) values("sso_default_idp_url", "http://your_keycloak_url/realms/yourrealm", "string");
MFA
Uniview provides full process for the MFA to individual project user and also the administrator.
MFA enabling is multiple steps configurations, instead of a single attribute. Those are such as when/how a user should enable, and once MFA enabled, there are considerations that the users should be able to continue OpenStack CLI etc the service providers can facilitate. For Keystone, it's recommended to have below authentication methods allowed:
methods = external,password,token,oauth1,totp,application_credential,openid,saml
MFA requires multiple permisions that policy.yaml of Keystone grants. One recommanded policy as below:
"identity:create_credential": "(rule:admin_required) or user_id:%(target.credential.user_id)s"
"identity:update_user": "(rule:admin_required) or user_id:%(user_id)s"
Encryption
Uniview provides utility for the administrator and user for the encyption across Compute and Storage.
Organization Management
Uniview provides project level user management, such as user inviting etc.
Application Credentials
Uniview provides full support for application credentials, so that password and application credential based authentication is seamless.
RECAPTCHA
Uniview provides most popular Google based fraudulence prevention utilities through configurations by users themselves. They can be applied to protect user recruitment process, or other such as user login process on customer demand.
Only HTTPS encrypted communciations accept reCaptcha fraud prevention, so that you will require to setup your frontend load balancer to listen at HTTPS before this is fully functional!
To be working with reCAPTCHA, tls(https) certificate, public domain name and reCAPTCHA v2 keys are required!
Tls certificate setup on your LB such as HaProxy or NGINX or other load balancers that sit in front of Uniview service is on clients' diligence.
Clients will be required to apply your own reCAPTCHA keys through Google Process!
Uniview provides a console for administrator to configure the website public URL, Google keys, from entry of: Vendor-Zone-> Operation Settings, collapse: Cloud Portal public DNS Settings
Once the variable is set on the console, Uniview services (local docker or Kubernetes Pods) need a resart to pick up the right value!
Entry of Portal public domain name and reCAPTCHA protection:
OpenStack Mutli-Domains Support
Uniview user console works with both multiple domains or single "Default" domain. By default, Keystone user signing in to Uniview will be assumed under the Default domain.
In majority of OpenStack install, the users and projects are created under the same domain of "Default". There are also some deploys such as by Canonical Juju Charms, the users are possibley created under a domain other than "Default".
For a public cloud, to ask customer to remember a domain other than user/password can be annoying, hence Uniview is designed to be working "Default" domain as the default. Uniview also can be conveniently configured to be working with multi domains too when security policy requires. When the users are created under domain other than "Default", sign-in process by Keystone will require the domain to be passed explicitly. To enable such users to sign in OpenStack over Uniview, a row of portal properties will be required.
insert into portal_properties (property_key_name, property_key_value) values('multi_domains_console_access', 'enabled' );
FAQ
A FAQ is a list of frequently asked questions (FAQs) and answers on a particular topic.
The minimal replica of Uniview service is 2, and tested upend of replica number is up to 10, and by theory it can go dozens of replica with proper database deployed (It's user responsibility for high scalable database install).
For those prepaid order made over WHMCS, Uniview has the option to accept credit quota fetched from WHMCS then grant client to access corresponding cloud services. Given the WHMCS is widely adopted in web hosting, Uniview can still see the value of integration of WHMCS in general. Hence Uniview will provide on demand on customer request basis!
As today's most public clouds are conducted, credit cards are used as the primary guarantee for the service consumption in Uniview! Uniview provides a full real time credit card validation for the authencity when user registers and activates his account by providing credit card number! For other billing model such as wiring transit, manual process (Administrators can manually set bill status upon other non-uniview controlled pay process), prepaid, please contact for futher details!
Examples of MFA, Application Credentials or Encryption, each requires Keystone user permission to edit himself attribute, and enabling certain API attribute of Keystone etc. We encourage users to read through the current docs for getting those, and alternatively, a quick workshop with us can resolve most depependencies.