- CloudStack-UI
- Documentation
- Project Sponsors
CloudStack-UI is a project whose purpose is to develop an easy-to-use, light, and user friendly frontend interface for the Apache CloudStack virtualization management system. Apache CloudStack itself is a great product which is used very widely, but its frontend is developed for administrators (from our point of view), not for end cloud users. Some of the interactions are not straightforward and unnatural to an average user and require quite a long time to adapt. Other reasons to develop are connected with a lack of functions like virtual machine statistics & charting, sophisticated resource accounting, and application management. These are in our long-term TODO list.
Join CloudStack-UI LinkedIn Group
At Bitworks Software, we run an ACS public cloud for 3 years (actually we still run CS 4.3 cloud in production) and we found that average users who are familiar with Digital Ocean, Amazon AWS, and other VPS management systems feel uncomfortable with original CloudStack UI and make a lot of operational mistakes. That’s why we decided to implement a convenient and neat end-user facing UI covering regular activities, which are important for day-to-day VM management.
The project is developed by Bitworks Software Frontend Division within the educational marathon, which has the purpose to incorporate our new team members and show them our standard frontend development instrument.
- Designed compatible with Apache CloudStack 4.9 and hasn't tested for the previous versions of CS
- Powered by Angular and Material 2.
- Tested and works fine in next modern browsers
- Google Chrome 60.0.3112.78
- Chromium 60.0.3169.0
- Mozilla Firefox 54.0.1
- Safari 5.1.7
- Internet Explorer 11.483.150630
Actual Changelog can be found in GitHub's wiki.
Since we designed the product from the perspective of well-known use cases, which are common to our public cloud deployment, we implemented only ones which are 100% required and cover most of use cases. Other deployments may imply other requirements, which is why it’s an open source product.
So, what is supported:
- Basic CloudStack zones with virtual router
- Security groups
- KVM Hypervisor
- Security group templates
- Multiple zones
- CloudStackAccount Domains
- Virtual machine standard operations supported by Apache CloudStack
- Root and Data disks management
- Ad-hoc snapshots for disks
- Affinity groups management
- VM groups
- Localization support
- Frontend Themes, Custom VM colors
- Custom and Fixed service and disk offerings
- Password management
- SSH keys management
- API keys management
- A lot of small improvements which affect user experience greatly
- Pulse Plugin - supports visualization of VM runtime stats (CPU, RAM, IO, network traffic) with charts;
- WebShell Plugin - supports clientless SSH access to VMs.
We intensively use features like projects in our own CloudStackcloud to manage resources dedicated to project groups, etc. but generic users don’t need them, so we don’t support the following features yet:
- Advanced Zones
- Hypervisors other than KVM have not been tested
- Responsive interface for smart devices
- Plugins
- Resource utilization stats, traffic, IO stats, CS entities stats a.k.a. Accounting
- Self registration for public cloud
- RDP/VNC (guacamole)
- Plugins
- Applications a.k.a. Roller (Docker swarm or Ansible, tbd)
Just a simple login screen. Nothing really new. But it has a nice preloader which can be used to brand it for specific company. By default it shows Apache CloudStack banner.
This screen was rethought greatly. First of all, we implemented the “one step” approach everywhere, and we also made it work without moving from view to view, like ACS native interface does. Thus, all actions on VM instances are managed from the same screen. Also, the interface allows to view several zones immediately, group virtual machines by zones, by logical groups (e.g. Databases, WWW), and by colors. We added a feature to brush a virtual machine with a specific color to make it look unique and meaningful to users from a certain perspective. Also we moved most of VM information to the sidebar, which now has two tabs - the first one is for the general view and virtual-machine related activities (like security groups, additional ips) and the second one is for virtual machine storage management (disks, snapshots, and ISO). From the system behavior standpoint, we have changed it sometimes, e.g. when the user wants to change service offering for running VM, the interface says that VM will be stopped and started, and it doesn’t make the user do it separately. So we replaced disconnected action sequences with connected ones.
We changed the new virtual machine screen a lot. Now it’s one-step and it allows to select everything from one screen without additional steps and so on. We believe it’s much better for a regular user than the one which is used in the native UI. It also generates meaningful VM names from usernames like vm-<username>-<counter>. Another important thing is that the form immediately checks that the user has the required amount of resources to create the virtual machine, and thus it doesn’t allow them to launch creation of impossible things which will fail for sure.
We also decided to place resource usage bar on the same virtual machine view screen. It can be collapsed or displayed. You also can see that the interface is in chocolate and blue colors. It’s because we enabled instant theme changing in the settings area. Material Design allows doing it natively, default theme colors can be specified in configuration json file.
We changed the templates and ISOs view to make it more obvious and neat to use. Also, the user can choose the required OS family to filter out unnecessary images. Also the same concept of single view without moving between screens is applied here. Additional things are displayed in the sidebar.
So, here is somewhat of a controversial thing here. Actually, we don’t think the security group concept is quite clear for an average user. There is a reason. The user can not change the security group for a virtual machine, but he or she can change the rules inside of the security group; as a result those changes affect all the virtual machines which share the same group. From our experience it’s not what an average user expects. We tried to change it to make it work in a better way, so we created the “Firewall rules template” concept, which is a preset that can be system default or developed by the user, and those presets (many of them) can be used to specify for a newly created virtual machine. Upon creation the system creates a new security group for every virtual machine which is initially filled with all the rules from specified presets. Next, when the user changes the rules for a certain virtual machine, they don’t affect other machines. So, basically the interface disables sharing one security group between several virtual machines. Every virtual machine always gets a unique security group which is built from presets specified when the virtual machine was created. Also, system administrators can specify default presets during the interface deployment in json configuration file; now we have “TCP Permit All”, “UDP Permit All”, “ICMP Permit All” presets which just pass all the traffic because we would like the user who doesn’t read manuals and doesn’t mention the details to still make his virtual machines accessible.
This panel displays only the drives which are detached from virtual machines. Original ACS UI has the “Storage” zone where the user can see all the drives, but we don’t think an average user needs such a function. Current ACS releases allow root volumes resizing, so fewer and fewer users require more than one drive. But, some deployments can have different storage offerings, so it’s still important to let the user work with additional drives, but in the native ACS UI we found that users often forget about additional drives and they assume they will be removed when the virtual machine is removed, so in 99% of the cases they don’t expect that they can be reused. So we made it work that way. All drives can be automatically removed on when a virtual machine is removed. The attached drives are not displayed in the “Spare drives” list, the drives that are detached are displayed there. Also, we don’t allow the user to create additional disks on a virtual machine creation because it leads to confusion when the virtual machine is created from a template – the user doesn’t realize that they add an “additional” drive and it’s not a root one.
It’s a simplified view for account activities. It lets you choose the date and levels and see all of them. It’s close to the same screen in the ACS native UI, but we believe that the user is interested in the events of specific date and scrolling a huge event log back to find something is not productive. Sometimes the HelpDesk service just wants to show the user that something had happened on a specific date, and thus the interface allows you to find information easier.
To run docker container use:
docker run -d -p 80:80 --name cloudstack-ui \
-e CLIENT_ENDPOINT=http://cloudstack/client \
-e BASE_HREF=base_href \
-v /path/to/config.json:/static/config/config.json \
bwsw/cloudstack-ui:1.0.7
http://cloudstack/client - URL of CloudStack client endpoint (e.g. http://host:8080/client)
base_href - custom base URL (optional, defaults to "/")
/path/to/config.json - path to a custom configuration file named config.json (optional)
Additionally, you can change favicon and Cloudstack logo on login screen and in sidebar:
-v /path/to/favicon.ico:/static/img/favicon.ico \
-v /path/to/cloudstack_logo.png:/static/img/cloudstack_logo.png \
-v /path/to/cloudstack_logo_light.png:/static/img/cloudstack_logo_light.png \
-v /path/to/cloudstack_logo_dark.png:/static/img/cloudstack_logo_dark.png
where the favicon.ico is the favicon, cloudstack_logo.png is the logo displayed on login screen and cloudstack_logo_light.png and cloudstack_logo_dark.png are Cloudstack logos displayed in sidebar with dark and light theme respectively.
Some operations implemented in the UI require "delayed" activities, so we use additional cleaner container that cleans objects marked for the removal.
Download and start bwsw/cloudstack-ui-cleaner container.
You can customize the application by providing your own configuration file (config.json).
Domain URL used to fill the 'Domain' field in the login form
"defaultDomain": "domain"
Predefined templates for security groups. You can define your own security groups that will be available for all users by default. Format:
"securityGroupTemplates": [
{
"id": "templateTCP",
"name": "TCP Permit All",
"description": "Permits all TPC traffic",
"preselected": true,
"ingressRules": [
{
"ruleId": "9552c7e9-9421-4a16-8a09-00a6bab4aa5a",
"protocol": "tcp",
"startPort": 1,
"endPort": 65535,
"CIDR": "0.0.0.0/0"
}
],
"egressRules": [
{
"ruleId": "dcaeefe0-0014-4431-b21d-db2e66f9162d",
"protocol": "tcp",
"startPort": 1,
"endPort": 65535,
"CIDR": "0.0.0.0/0"
}
]
},
{...}
]
Parameters:
- id: a unique identifier
- name
- description
- preselected (true or false) - specifies whether network rules from this template will be automatically applied for newly created virtual machines
- ingress and egress rules:
- ruleId: a unique identifier
- protocol: either 'tcp', 'udp' or 'icmp'
- CIDR: subnet mask (e.g. 0.0.0.0/0)
- For TCP and UDP: startPort and endPort
- For ICMP: icmpCode and icmpType
The set of colors for virtual machines in hexadecimal format. You can specify any colors you like.
Preferred color theme for the app. Available themes are:
"blue-red"
"indigo-pink"
Is not specified, blue-red one is used.
In this section you can specify which offerings will be available for which zones. Format:
offeringAvailability: {
"filterOfferings": true,
"zoneId": {
"diskOfferings": ["offeringId1", "offeringId2"],
"serviceOfferings": ["offeringId3", "offeringId4"]
}
}
If filterOfferings is set to false, all offerings will be available for all zones.
In this sections you can specify limits for custom offerings in the following format:
"customOfferingRestrictions": {
"offeringId1": {
"cpuNumber": {
"min": number,
"max": number
},
"cpuSpeed": {
"min": speed_in_mhz,
"max": speed_in_mhz
},
"memory": {
"min": memory_in_mb,
"max": memory_in_mb
}
}
}
Any of these parameters may be left unspecified, in which case 0 will be used for min and infinity will be used for max.
Number of minutes a user's session should stay active. After this time passes the user is logged out.
Defaults to 30 (minutes).
You can set it to 0 to turn this off, although in this case the session is likely to expire on the server side.
A boolean value which allows or forbids a user to reorder links in the main sidebar
Please check Wiki for extension configuration options.
The project is currently supported by Bitworks Software.
You can contribute to the project development in various ways:
- Share the information about the project with other people, try to install the UI and share your opinion with us and your colleagues.
- Propose useful features. Ideas are always welcome.
- Deploy it somewhere and inform us about your success story and we will share it in the adopters section.
- Fix bugs and send us the PR.
- Implement a feature from the Roadmap or simply make something new.
- Support and promote the development of specific functions which are important to you and may be shared.
- Provide testing environment for other deployment schemes. Now we interested in testing the app with
- KVM with RBD
- Xen with NFS, Local, RBD
- Oher browsers and operating systems
- Hire us for frontend or backend development of custom software development projects. Take a look at our website to know where we can be useful. Take a look at our presentation to learn more about us.
To contribute, just contact us via e-mail: info@bw-sw.com
It’s released under the Apache 2.0 license.