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

  1. Prepare OpenStack Keystone and gather access info
  2. 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!

  3. Prepare Mysql or MariaDB database on your database server.
  4. # mysql
    CREATE DATABASE uniview;
    CREATE USER 'uniview'@'%' IDENTIFIED BY 'your_pass';
    GRANT ALL PRIVILEGES ON uniview.* TO 'uniview'@'%';
    exit
    
  5. Edit your docker-compose file with minimal information and use Uniview public accessible image
  6. 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
  7. Run and Access
  8. 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

  1. Git clone the install artifact at a console or the host where the Uniview Docker service runs.
  2. git clone https://github.com/ComputingStack/Uniview-OpenStack-Portal.git
  3. Prepare OpenStack Keystone and gather access info
  4. 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!

  5. Prepare Mysql or MariaDB database. Full details jump here
  6. Prepare necessary user, project and role etc. Here is the details
  7. Access your docker images
  8. 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
  9. Install as your choice, by Ansible, by Dockerfile or over Kubernetes
  10. Optional to customize such as logo, business title, email engine and others
  11. 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.

  12. Optional to configurre your monitoring when needed

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:

  • Infrastructure Alerts if they are configured
  • OpenStack core services such as Neutron, Nova and Cinder
  • Capacity managements of CPU, Memory, Disk per both utilization and capping onfo
  • Ceph Cluster Status Overview
  • Hosting Server Key metrics and overview
  • Controller Database and its metric view
  • Rabbitmq and its metric view
  • Example of OpenStack Vendor Dashboards:


    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.

  • CPU utilization over time
  • Load Average by 1m, 5m and 15 m. When multiple host selected, the graphic will show only 5 m average of all selected nodes
  • Avaialble memory and their breakdown into available, free and total
  • Disk Read IOPS
  • Disk Write IOPS
  • Outgoing Network Transit Bytes Data
  • Incoming Network Transit Bytes Data
  • Example of OpenStack Controller Hosting server Monitoring:


    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.

  • Number of Queues
  • Consumer number
  • Active connection number
  • Channel of messages
  • Incoming message per second
  • outgoing message per second
  • Ready message
  • Queue over time
  • Memory used by RabbitMq vs the residency memory
  • Messages break down of incoming, redelivered, outgoing, acknowledged and unacknowledged etc
  • Example of OpenStack Controller RabbitMq service Monitoring:


    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.

  • Uptime
  • Connection
  • InnoDB Buffer Pool size
  • Connection Error
  • Slow Query
  • Connection and the max connection number limit
  • Operation read of Read, Inserted, Updated, Deleted
  • Slow query over time
  • Open Cache over time
  • Open files number and its limit over the time
  • Example of OpenStack Controller Database Monitoring:


    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.

  • Outgoing Email
  • DNS Setting
  • Self-Service
  • Portal Branding and Logo
  • Primary Color
  • Theme
  • Example of portal properties of theme:

    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:

  • User gets himself enrolled by filling form on login pages by click on REGISTER
  • Uniview does sanity checkes such as whether a email being used, or existing customer with same identify provided earlier. For qualified registration, system will send out email to verify email address
  • User is required to receive a request to confirm the registration
  • User confirms the registration through the note received in his email which he provides at registration
  • With user confirmation, Unview will create a new project, and the user login name by applican't email has the roles projectadmin. Initial roles assigned to the user including projectadmin, user, _member_, heat_owner
  • Config 1: For default setting, the project is created with status active, so that user can access cloud resource. This case works for example when administrator has a strategy by allocating certain credit to enable user to start right way, or there is other methods to validate a user.
  • Config 2: For extra validation setting, Uniview administrator can configure Uniview to create an inactive project. With extra condition, such as pay method by valid credit card input by customer, the project will be activiated
  • User can re-sign in to Uniview to start scloud services for default settings. This is a more conventional approach that valid pay method is the key to unlock a user
  • When Config 2: If project is initially configured to be inactive, user will be promted to create a valid pay method
  • When Config 2: With validation Uniview of users' credit card or other payment, the project will become "enabled" to be active mode
  • User have full access his cloud resources
  • 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:

  • User registers himself successful at Keycloak
  • User clicks sign in by user/password, or user will be automatically signed in with prior sign in cached by other apps.
  • User is redirected to Uniview Landing portal
  • At landing portal, user can browse the projects he may be assigned to access, or create a valid pay method
  • User chooses to create a pay themod by providing credit card info. Uniview validates the genuity and saves the info at Uniview databases.
  • User requests to create his/her first project at Landing Portal. Without valid credit card at last step, the request will be declined.
  • The project can be promptly created with pre-defined roles assigned to the user. By default member is the only role that is attached to the user to access a new project.
  • User proceeds to scoped project level management console.
  • 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.


    1. Know Uniview dependencies on CloudKitty
    2. 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.

    3. Where/How to configure plan and rating
    4. 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.

    5. Cloudkitty module choice
    6. 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.

    7. Billing dashboard and Pricing and Display on Uniview
    8. 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!
    9. Discount and Promotion
    10. 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.

    1. Clone Into a new price plan draft
    2. Insert item by item with console guides for common billing items such as Instance, Volume and Floating IP

    3. 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.

    4. Activate the draft to be the active plan
    5. 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
    Below values are expected from portal_properties table in your database to compose a proper invoice:
    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:


    FAQ

    A FAQ is a list of frequently asked questions (FAQs) and answers on a particular topic.

    Simply load balancing will work to scale up. Uniview is designed to handle big number of parallel requests. When deployment is over a generic Linux box with Docker engine, it is highly recommended to have two Docker daemons running in different hosts, and a load balancer is sitting in front of the Docker hosts. When deployment is over Kubernetes cluster, users can adjust the replicSet number to two or above to achieve scalability demand. In whichever cases, “/getVersion” is in place to serve as a health check for the readiness of Docker itself.
    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).
    It's recommanded to have Horizon handy for some administrator purposes, and for all the activities of the end users other than administrating, Uniview should be the only place in daily operations. For some administration activities, especially one time activities such as pricing and rating by administrator, Uniview doesn't re-write those from Open Source upstream. Horizon can serve as a complementary tool.
    Uniview support of WHMCS will be on demand. For most popular credit card based cloud service consumption, Uniview is a self contained billing and there is no need of a 3rd party component. Uniview relies on upstream cloudkitty for rated data to be ready in openstack backend, then aggregate those into a bill at Uniview, then accept payment from a pre-defined payment gateway such as Stripe and Paypal through Uniview.
    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!
    Uniview supports post-paid out of box, and prepaid based will be supported on demand!
    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!
    It's fully expected! Even though sign in and most of basic functions are guranteed working, but many features requires OpenStack backend configurations and certain permissions setting(policy.yaml) to be fully functional!
    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.