The deprecation date is typically 12 months from the General Availability date.
Upgrades from a deprecated version to the latest version will stop being tested on the deprecation date. Upgrades are still supported, but may take multiple steps.
Release |
GA Date
|
Deprecation Date
|
End of Support
|
---|---|---|---|
9.4.4 | February 2nd, 2021 | February 2nd, 2022 | May 2nd, 2022 |
9.4.3 | November 17th, 2020 | November 17th, 2021 | February 17th, 2022 |
9.4.1
|
August 25th, 2020 | August 25th, 2021 | November 25th, 2021 |
9.4
|
July 15th. 2020
|
July 15th, 2021
|
October 15th, 2021
|
9.3.2
|
August 24th, 2020
|
August 24th, 2021
|
November 24th, 2021
|
9.3.1 | June 8th, 2020 | June 8th, 2021 | September 8th, 2021 |
9.3 | May 11th, 2020 | May 11th, 2021 | August 11th, 2021 |
9.2.1 | February 7th, 2020 | February 7th, 2021 | May 7th, 2021 |
9.2 | January 27th, 2020 | January 27th, 2021 | April 27th, 2021 |
9.1 | November 25th, 2019 | November 25th, 2020 | February 25th, 2021 |
9.0 | September 30th, 2019 | September 30th, 2020 | December 30th, 2020 |
8.8 | July 26th, 2019 | July 26th, 2020 | October 26th, 2020 |
8.7.1 | July 2nd, 2019 | July 2nd, 2020 | October 2nd, 2020 |
8.7 | May 29th, 2019 | May 29th, 2020 | August 29th, 2020 |
8.6 | March 6th, 2019 | March 6th, 2020 | June 6th, 2020 |
8.5 | January 4th, 2019 | January 4th, 2020 | April 4th, 2020 |
8.4.1 | December 5th, 2018 | December 5th, 2019 | March 5th, 2020 |
8.4.0.1 | November 19th, 2018 | November 19th, 2019 | February 19th, 2020 |
8.3 | September 18th, 2018 | September 18th, 2019 | December 18th, 2019 |
![]() |
Remote Source Blueprint Configuration: If you have Remote Source Blueprints configured that contain secrets, you will need to reconfigure them. Follow the Secrets Stored in Remote Source Blueprints documentation to set up a password that encrypts and decrypts secrets when exporting and importing Blueprints. Without following these steps, any secrets in your Remote Source Blueprint will become blank on its next refresh post-9.2. |
![]() |
CloudBolt is upgrading Django to version 2.2 in CloudBolt version 9.3. If you have written Plugins or UI Extensions for CloudBolt, you may need to update them to ensure they continue to work in versions 9.3+. Check Django’s list of backwards incompatible changes for more details. |
CloudBolt now supports deploying Kubernetes to multiple nodes. The Content Library contains a Kubernetes Cluster Blueprint available to import. This allows a Blueprint Admin to deploy a multi-node Kubernetes cluster. The Kubernetes Cluster Blueprint can be deployed to any Resource Handler. The Kubernetes Cluster Blueprint can also be used as a Sub-Blueprint to deploy Containerized Objects to dedicated Kubernetes clusters.
There are two main use cases for the Kubernetes Cluster Blueprint:
- Use it on its own to deploy a Kubernetes cluster. This is useful for IT Admins who want to provide multiple standalone clusters into which different apps can be deployed.
- Use it as a sub-Blueprint along with apps to be deployed into the new cluster.
See Container Orchestrators for set up and deployment. DEV-12361
The Create Blueprint Parameters (blueprint.create_parameters) permission allows non-Admin CloudBolt users to only create parameters for Blueprints they can access. See Blueprint-level Parameters for set up and use. DEV-13848
Added the ability to browse the Catalog by Blueprint Category in addition to the existing viewing options. Admin users can set the default viewing mode from Miscellaneous Settings. See Catalog Viewing Mode for more information. DEV-13612
A new third-party plugin allows Terraform users to make requests of CloudBolt and perform tasks such as server provisioning from Terraform. A new, open-source code base is accessible from the GitHub repository. Instructions to download and run the plugin can be found in the repository. DEV-12938
Previously, global parameter default values would only apply to servers. You can now configure global parameter default values to be set on Resources, by selecting from the new ‘Global Target’ field when creating or editing a global parameter default value. See Order Form Customization for more information. DEV-11808
The first time a user logs in to their account, they will be asked to choose a password reset challenge question from a dropdown list and provide an answer for that question. The answer to this question will be used when a password reset is initiated, and is not case sensitive. See Security.
The CloudBolt API has begun the transition to a new way to access objects called Global IDs. Global IDs will be consistent across different, similarly-configured CloudBolt instances. This makes it easier to reuse the same API calls, rather than modifying them to match the object IDs in each instance. The first objects to transition to this new Global ID are those referenced by a URL when ordering a Blueprint through the API: Blueprints, Environments, Groups, OS Builds, and Applications. The intent of this feature is to gradually replace the object IDs that are currently used. The old IDs will continue to be supported for all objects.
A new third-party plugin allows Terraform users to make requests of CloudBolt and perform tasks such as server provisioning from Terraform. A new, open-source code base is accessible from the GitHub repository. Instructions to download and run the plugin can be found in the repository.
We’ve added the ability to add Preconfigurations on Blueprint-level parameters. Like other parameters on Blueprints, Preconfigurations can be given a destination to be set on the deployed Resource, the build items, or both.
When set on the build items, Blueprint-level parameters will take precedence over any overlap set on the Environment of the Server Tier build items. If you define the same Preconfiguration on the Environment for a server, the Blueprint-level Preconfiguration and its options will override the Environment Preconfiguration. The same precedence will apply if you set Custom Fields on an Environment in a Server Tier that are defined in a Blueprint-level Preconfiguration.
CloudBolt 8.8 and earlier run on CentOS 6.6, but CloudBolt 9.0 runs on CentOS 7.6. This gives CloudBolt users access to all of the software supported by CentOS 7 that is not available on CentOS 6. Unfortunately, it is not possible to upgrade from CentOS 6 to CentOS 7 in place. We have prepared command line tools to make migrating your CloudBolt instance from CentOS 6 to CentOS 7 as painless as possible, but it is not completely automated. Please see Upgrading to 9.0 for details on how to upgrade.
We’ve made a number of improvements to the Terraform Integration that was introduced in 8.8
.tfstate
files for two-stage plan
then apply
Terraform run. DEV-12553
Centralized ServiceNow Management Page
CloudBolt now supports integration with one SIEM provider, Splunk, allowing users to configure their data forwarder from a new Admin page.
We’ve restored the ability to browse the Blueprints Catalog in table mode. You will now be able to switch between viewing your Blueprints as a table or in tiles. This mode can be toggled with the button at the top right of the Catalog page.
We’ve also added the ability to skip to the first or last page in either viewing mode, and the ability to sort results by resource type.
In addition, there is a new Miscellaneous Setting under the Admin page where you can select a Catalog Viewing Mode as the default for all users.
We’ve extended CloudBolt’s ability to import and view billing data to GCP. Now, you can set up GCP Projects in CloudBolt to import billing information, and then view graphs summarizing the data on the GCP projects’ and resource handlers’ Billing tabs.
Detailed instructions to set up importing GCP billing data into CloudBolt can be found under the Google Cloud Platform section of the docs.
We’ve added the ability for CloudBolt users to access the consoles of servers under Nutanix Acropolis Resource Handlers CONTNT-234
Note that the Nutanix Hypervisor must be running the v3 API in order for the console to work.
The new Multi-Channel Alerts feature allows CB Admins to decide how to send notifications about different kinds of alerts from the product. They can now be sent to Slack and Email. Out-of-the-box alerts include security and administration events, and you can also send alerts from custom code such as an action or Recurring Job. See Multi-Channel Alerts.
Prior to 9.0, a unified view to import from the content library did not exist. Users had to know what kind of collection to look for, and go to each list view within the product for the type of collection they wanted to import (e.g. Blueprints, Orchestration Actions, etc).
Super Users can access importable content hosted by CloudBolt directly from the main menu. Browse, learn about and ultimately download Blueprints, Resource Actions, Server Actions, Orchestration Actions, Recurring Jobs, UI Extensions and Rules from a single page.
CloudBolt now integrates with Infoblox in a more robust, customizable way. We’ve given CloudBolt admins detailed control over which Networks use which IPAMs and how those IPAMs are used during the provisioning process. We have also added support for phpIPAM.
When you establish a new connection to an IPAM, you’ll see two new tabs: Networks, and Orchestration. Import the networks (expressed in CIDR notation) directly from your IPAM instance under the Networks tab.
In order to use the features in the Orchestration tab, you’ll need to import at least one. Once you’ve imported your IPAM Networks, you can view them in the data-table and click the pencil icon to assign them to one or more CloudBolt Network. In the Orchestration tab, enable or disable orchestration entirely. This is where you’ll find base-line Python code that allocates and deallocates IP addresses from your IPAMs during Server provisioning and decommissioning. CloudBolt administrators can modify this code to suit their needs, or revert to the basic version CloudBolt provides.
With this configuration complete, CloudBolt will execute Orchestration code to provide IP addresses to user-provisioned Servers that are associated with an IPAM whose Orchestration tab is enabled.
CloudBolt 9.0 includes important changes to the way we support Kubernetes. CloudBolt Admins can now associate a given Kubernetes Container Orchestrator with a CloudBolt Environment, and even have the option of making multiple Environments that support multiple Kubernetes clusters. This allows CloudBolt Admins to leverage CloudBolt’s existing role-based permissions: users that can deploy to a given Environment can deploy containerized objects to Container Orchestrators (Kubernetes Clusters) in that environment. Users without the permission cannot.
To set the association, Admins can: * Edit the Environment, selecting all relevant Container Orchestrators. * Edit the Container Orchestrator, selecting all relevant Environments.
CloudBolt displays associations in the List Views for Environments and for Container Orchestrators. Admins will need to edit Blueprints that deploy Containerized Objects to set their Environments.
More information about your Kubernetes clusters now shows: * Pod Details: Which Pods are running, their Images, Nodes and Statuses. * Node Details: Nodes that are members of the cluster, their statuses, and how heavily they are loaded.
False
and Integer 0
were not being passed to Actions. DEV-12868
git
repositories. DEV-12798
8.8 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
The next phase of this feature includes the following changes for improved user experience and support for more Blueprint features:
We’ve added a new action type that allows one to apply Terraform Plans in CloudBolt Blueprints. This action enables you to deploy CloudBolt resources containing Terraform-provided resources.
When a Blueprint containing Terraform Plan Actions is ordered, CloudBolt will discover servers provisioned by Terraform and add them to the resulting CloudBolt resource. These servers are later discovered by their associated Resource Handler and can be managed managed through the CloudBolt UI.
Read more about the Terraform integration under the Terraform Plan Action docs.
Job Engine worker processes are now started and managed via Supervisord, instead of by cron. You can check the status of worker processes on the status page at
, or on the command line with supervisorctl status.The following improvements have been made to order form validation:
Templates from any configured VMware content libraries are now available to be used within CloudBolt. VM Templates from local and subscribed content libraries can be imported into your VMware vCenter Resource Handlers and subsequently configured for any Environments. CloudBolt environments must have at least one Resource Pool configured to deploy Content Library Templates.
Cloudbolt’s IPAM page serves as something of a preview of what’s to come. You’ll find a new tab to allow you to import the networks you have configured in Infoblox. You’ll find a new, but disabled, Recurring Job which will, when you edit it, allow you to assign one or more IPAM networks to any or all of your CloudBolt networks and you’ll find a new Orchestration Action under the Pre-Create Resource hookpoint called, “IPAM Associations 01 - Allocate IP From Associated IPAM.” If you enable that Orchestration Action and associate an IPAM network with a CloudBolt network, it will allocate an IP address from your IPAM and use it as a static IP for that NIC.
See CloudBolt Plug-ins for more info.
Server and Resource Actions now give CloudBolt Admins the option to require approval before being run. When require_approval is set, the action will be added to an existing or new order.
Changes to the way CloudBolt models orders and groups allow users to write complex order approval Orchestration Actions that override the standard approval workflow.
collect_xui_apps
management command to index all UI Extensions on the users’ filesystem and add them to the database. DEV-12157
8.7 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
We’ve restructured our AWS restricted Resource Handlers to support multiple regions with the same account and handler. If you need help consolidating your environments into one Resource Handler, please consult CloudBolt Support.
CloudBolt can now resize VMs in Azure. Click, “Resize VM,” under Server Actions on the Server Details page. Note that the available sizes will be constrained by what Azure supports for that machine and by what sizes your CloudBolt admins have configured for the Environment.
CloudBolt will now limit the choices available for VM node size based on the choice made for disk type. If a user or Blueprint designer selects Premium_LRS disks, only those VM node sizes that support those disks will be available.
CloudBolt now recommends reserved instances to save money by switching from On Demand costs to the discounted Reserved Instance rates on your ec2 instances. You can view these recommendations from an AWS Resource Handler’s Billing tab.
When synchronizing virtual machines to Servers from VMware VSphere to CloudBolt, we will now take note of IPv6 addresses in addition to IPv4 addresses. We have also added a new option under Miscellaneous Settings to tell CloudBolt which address to use for actions such as running remote scripts. Options are:
Virtual machines that are members of Azure Scale Sets will now be synchronized to CloudBolt
We’ve added the ability to set automated spelling corrections for tag values. CloudBolt Admins can specify mappings between misspelled values and the correct spelling. Then, whenever CloudBolt updates any tagged servers for that resource handler, then the spelling will be corrected based on what the admin has set to change. For example, an admin can specify that the misspelled value ‘poduction’ should be corrected to ‘production’. Then, if CloudBolt discovers a VM with that tag value, it will correct the value to ‘production’. This is supported on AWS, Azure, and VMWare resource handlers.
We’ve also added the ability for admins to enable bidirectional syncing on group and owner tags. The behavior will remain the same out of the box, but admins can enable bidirectional sync from the resource handler’s Tags tab. This will allow for tag values imported into CloudBolt to override the group and/or owner of the server.
CloudBolt now ships with improved Google Cloud support. The primary difference starting with this release is the support for multiple GCP Projects within one resource handler. Additional documentation on setting up the new and improved GCP handler can be found here.
CloudBolt can now take snapshot of an OpenStack instance and can revert back to a snapshot created by CB. To take a snapshot of an OpenStack server, click on ‘Create Snapshot’ server action available on the server details page. To revert the server back to a snapshot, click on ‘Revert To Snapshot’ server action on the server details page.
CloudBolt now offers the ability to have Blueprints populated from a definition stored in a remote source location, such as github, gitlab, or a filesystem. This is a beta feature that supports many of the core pieces of functionality, with some limitations. Please see the Catalog docs for more details. Feedback? Email the team: beta@cloudbolt.io.
Deleting
state are now marked Historical
. 165104806
8.6 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
Resource handlers used filesystem locks to ensure only one Sync VMs process executed at a time. However, that relied on filesystem syncing to copy lock files between CloudBolt instances in a High Availability configuration. Those locks have now been moved to the database, making the locks more reliable as Job Engine processes scale horizontally.
We’ve added the ability to import and view data from AWS monthly invoices. With an s3 bucket with billing report exports configured on your AWS Account, CloudBolt will import billing files at the end of each month with the new recurring job Import Public Cloud Billing Data. The data will be available to view on AWS servers’, AWS resource handlers’, and groups’ Billing tabs.
Due to security concerns with the older boto libraries, we’ve updated our standard communications with AWS to utilize the boto3 library. If you have existing CloudBolt plug-ins using the boto library, they will still operate. We suggest you do update these to use boto3 as well. If you would like an example, please look at the AWS S3 Bucket Blueprint available in the content library. Please reach out to Support if you have any additional concerns.
A new setting, Original Password Verification in Admin > System > Miscellaneous Settings, allows disabling the requirement for knowing a user’s original password when setting a new password. This setting defaults to True. If the setting is disabled, no user will see the Original password field when editing any user profile. 163232620
8.5 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
As part of exposing CB’s catalog and request functions within other interfaces, there is now a new mode that can be made available. This “Catalog-Only” mode allows users to request resources using Blueprint, but does not allow them to access other parts of the application. The mode works well inside an iframe as an additional method of integrating with other IT products. 162432469
We’ve added multiple improvements in the support of Azure Images in CloudBolt.
A number of security-related features and settings have been updated.
If you have any questions about specific security topics, please contact support to learn more.
An issue with accessing Blueprint-level parameters destined for the resource from the resource name template after they were entered on the order form has been resolved. As part of that process, refactored how those parameters are added to the context to better match expected uses, including the addition of support for provided values and better constraining to only Blueprint-level parameters that have a destination that includes the resource. Also corrected and improved related documentation.
8.4 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
There is now a new way to create and update Resources in CloudBolt, by way of a Discovery Plug-in associated with a Blueprint that provides logic to discover and sync Resources of the type described by that Blueprint. This is an extension of CloudBolt’s “X as a Service” functionality, which now supports bringing brownfield environments of arbitrary types of resources under management and updating their state in CloudBolt as it changes in the external systems that host them.
After seeing a variety of issues with the Celery-based job engine introduced in CloudBolt 7.7, we are moving back to a CloudBolt-engineered Job Engine, which should be more stable, scalable, and sustainable. This newer engine was introduced as an option in CloudBolt 8.2.0.7. However, it is now the default engine, and the Celery-based engine will be removed altogether in a future release. The new engine includes a large set of enhancements, including support for High Availability in active-active configurations.
More information is available on our blog: API Documentation
Assignment of an IP address from an IP pool will skip addresses that are found to be already pingable, even if the address is not assigned to a server managed by CloudBolt. That remains true, however that validation has been moved to run as an out-of-the-box orchestration action at the “Validate IP Address” hook point and can now be disabled.
Now that the discovery of a pingable IP counts as a normal validation failure, the number of IP addresses that will be attempted before the assignment gives up has been increased from 5 to 50. That can be customized via the MAX_IP_RETRIES setting.
We’ve added support for multiple-choice parameters in regenerated parameter options dependencies. Now, you can set ‘allow_multiple’ to True on the controlling field and accept the new ‘control_values’ kwarg in the ‘get_options_list’ function in your generated parameter options plugin and generated options for the dependent field based on a list of selected control values.
CloudBolt now supports managing single-level snapshots on Nutanix servers. Two actions are provided: creating a new snapshot and reverting to a previous snapshot. Both actions are now available in the Actions panel on the server details page for Nutanix servers.
The health of various services within CloudBolt can now be viewed at Admin > Support Tools > System Status.
This release features some improvements to Azure (Resource Manager). * We’ve upgraded our Azure python SDK packages to the latest version, 4.0.0. You can read more about this version and it’s dependencies on PyPI: https://pypi.org/project/azure/ 159402657 * Fixes a bug where auto-creating availability sets was not compatible with non-managed disks. So, you can now auto-create availability sets in CloudBolt at provisioning time with a custom storage account. 160913381 * Added the ability to provision a VM with multiple managed disks. To take advantage of this feature, you can add data disks at provisioning time by adding the ‘Size for disk #’ parameters to your Azure environment, and the disks will be creating at provisioning time with the same storage type as the os disk. 160566671
In addition to being able to integrate with v2 of the Nutanix API, CloudBolt now integrates with v3 of the Nutanix API. Admins can dictate which version of the Nutanix API they want to connect with from the Overview tab of their Acropolis Resource Handler.
8.3 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
The Catalog page for Blueprints has been redesigned to support pagination. It also inclues new sorting options, like ‘Frequently ordered’ and ‘Recently Added’. If the catalog is full enough to require pagination, filters are presented in a sidebar to improve discoverability of Blueprint categorization.
This release features a number of improvements for our OpenStack support.
CloudBolt now supports managing VMware tags on your servers by linking them to CloudBolt server attributes. When the value of the CloudBolt attribute changes on the server, so will the value of the tag in VMware. Likewise, when a tag is modified via VMware, that attribute will be updated in CloudBolt the next time that server is synced.
Adding disks to a server in any resource technology that supports this, now can also be accomplished via the API. For specific instructions and examples please see the API documentation.
There is now an additional Global Role called a Global Viewer. Users given this role will have permission to view, but only view, everything in the UI, except for the exceptions listed in the documentation. This can be helpful for users who want high-level visibility to CB, perhaps to view reports, but should not have any edit capabilities.
CloudBolt has been upgraded to MySQL 5.7.22 and Apache 2.4.33. If you have any custom configuration for these services, please make sure that it is compatible with the new versions.
We’ve fixed a bug where a Blueprint order placed through the API would exclude any sub-blueprint build items. Now, ordering Blueprints with sub-blueprints through the API will include the sub-blueprint and all of its build items in the order.
We’ve added the ability to assign static IP addresses to Xen VMs. To use this feature, provision a new VM with a static network in CloudBolt, assigning an IP address. IPs can be set through the order form, an IP pool, or an IPAM. Note that in order to configure a static IP, the VM must have XenServer tools installed, which can be done by provisioning with an image that already has the tools installed. Additionally, we’ve added the ‘refresh info’ server action to Xen, which will get and update basic info on your VM like power status, CPUs, memory, disk, and IP address.
Each CloudBolt major & minor version starting with 8.3 will be named after a noteworthy power user of CloudBolt. These CloudBolt champions are nominated by CloudBolt employees then randomly selected amongst the pool of consenting champions. This code name, and a brief description of the champion is displayed in CloudBolt’s About dialog (but this can be disabled by adding ENABLE_CHAMPION = False to your customer_settings.py).
8.3 is named for Steve Paige, who has been a CloudBolt power user and admin at InterContinental Hotels Group since 2015. One of his favorite CB features (which he has also helped to shape through his feedback) is power scheduling of servers & resources.
CloudBolt now supports the CredSSP authentication mechanism when running remote scripts on Windows machines. CredSSP allows an application to delegate the user’s credentials from the client to the target server for remote authentication, and solves the ‘second hop’ problem that some users experience when running remote scripts from CloudBolt. Enable the new ‘Support CredSSP’ Parameter for any Servers that should use CredSSP when authenticating. Consult the Microsoft documentation on CredSSP for more info: https://docs.microsoft.com/en-us/windows/desktop/secauthn/credential-security-support-provider.
The version of Font Awesome used by CloudBolt has been upgraded from version 4 to version 5.3.1. This includes thousands of new icons, as well as varying styles like solid, regular, and light. Note, the names of some fonts have changed, and the ‘fa’ prefix has been replaced by several prefixes to specify the style. Font classes that you have associated with actions and resource types should automatically update, but we recommend you review your current usage. Check out https://fontawesome.com/icons for more information.
CloudBolt now ships with the current GA version of Chef DK, version 3.x. If you are using Chef with CloudBolt, please consult the Chef DK docs to make sure your Blueprints are using a compatible OS Build: https://docs.chef.io/platforms.html#chef-dk
8.2 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
Admins can now control the sequence in which Server Actions are shown to users, namely for the buttons on a Server’s details page and the dropdown when running Server Actions in bulk.
Admins can provide more complex logic for deciding when a Server Action should display. This is done by associating a Display Condition Plug-in that returns True or False to indicate whether or not the Server Action should appear in the given situation. For example, you can now configure your custom Server Actions so they only show when a Server is on.
Version 8.2 adds extra flexibility for tests, it is now possible to assign to individual tests their own timeout (in seconds).
We’ve made a number of improvements for specifying a type for AWS volumes. Previously, you could specify a volume type when provisioning a new instance by adding the ‘EBS Volume Type’ parameter to your AWS environments. We’ve made that parameter out of the box for all new and existing environments with the 5 EBS volume types as provided options. We’ve also added an out of the box dependent field for IOPS, which is required when creating ‘io1’ volumes. You’ll also be able to specify disk type and IOPS when adding disks to existing servers.
We’ve added the ability to define the display sequence of parameter options for orders. You can change the default display sequence by going to a parameter’s detail page and clicking on the edit icon under ‘Parameter Options’. Additionally, AWS instance types will be sorted by size by default, rather than alphabetically.
Dependent parameters will now be included in Blueprints being exported and imported. Any dependencies set on Blueprint-level parameters and on the action inputs for Blueprint actions will be automatically created if they don’t already exist.
With version 8.2, CloudBolt now supports the fetching and reporting of utilization data for AWS servers. Provided metrics are CPU, Disk I/O and Network Throughput. A Stats tab now appears on the server detail page for AWS servers, and the ‘Refresh all server utilization’ Recurring Job now refreshes usage statistics for AWS servers in addition to VMware servers. Additionally, AWS servers are now included in the CPU Utilization reports.
The two CPU usage reports have been updated to include additional server utilization metrics. In addition to CPU usage, the bar graph and the table reports display memory, disk and network utilization. These reports were previously named ‘Server CPU % Last 30 Days’ and ‘Server CPU % Table’. These reports are now referred to as ‘Server Utilization Graph’ and ‘Server Utilization Table’, respectively.
The database encoding has been updated to support UTF-8 characters, so your data can now include non-Latin alphabets and emoji. 😀
This release features a number of improvements for Azure Resource Manager support:
The Red Hat Enterprise Virtualization resource handler is no longer supported. Please contact us if you have questions or would like to have support in a future version of CloudBolt.
Users can now choose to provision servers using a custom storage account for disks, or let Azure manage disks automatically. Your environments and order forms are set up to use managed disks by default.
As before, if users want to use a custom storage account for some reason, they also have the choice of auto-creating a new one based on the hostname or selecting an existing one. To remove this choice completely, set a global Option of False for the ‘Use custom storage account’ parameter predefine a value (any value - as long as ‘Use custom storage account’ is False it is ignored) for the ‘Azure Storage Account’ parameter on your Blueprint build items.
Environments have a new parameter “Storage Type” to configure storage performance now: Standard (HDD) or Premium (SSD). Both managed disks and custom storage accounts support this choice. Consult the Microsoft Azure documentation for High-performance Premium Storage. Standard will be used by default.
This release also features a number of smaller improvements for Azure:
The Nutanix Acropolis resource handler now supports clusters. For each cluster brought under CloudBolt management, a new environment is created. Management of disks has been improved to allow adding disks at provision time, adding and removing disks on existing VMs, and extending the root disk of an existing server. Server CPU and Memory can be modified. Subnets are now associated with NICs on CloudBolt servers.
We’ve added a feature that allows you to map LDAP attributes to users in CloudBolt. From the new ‘Attribute Mapping’ tab on an LDAP Utility’s detail page, you can add attributes from LDAP and map them to existing parameters in CloudBolt. You may then click ‘sync mappings’ and add the mappings to a user. You’ll then be able to view a user’s attributes from the user’s detail page if the parameter has ‘Show on Objects’ set to True.
You can now see history events for resource handlers. You’ll be able to see when a resource handler was created and when a network has been added or deleted from the resource handler. History can be viewed from the new ‘History’ tab on a resource handler’s detail page, or from the admin/history list.
You can now see history events for orders. You’ll be able to see when an order was created and the modifications, approval and other order life cycle events. History can be viewed from the order’s detail page, or from the admin/history list.
If you would like your subgroups to automatically have the same permissions as their parent group, it is now possible to enable the inheritance of Users and their Roles. This will impact both internal and external users, and will keep subgroup permissions in sync with parent group permissions while enabled.
On forms, options for a parameter can be supplied through actions a the “Generated Parameter Options” trigger point. But if the set of options is large (more than a few hundred values) this approach may take too long to render. Now there is a way to provide a form field that renders immediately and then auto-suggests matching options as the user types. This asynchronous loading of options makes for a lightweight, responsive user experience.
To enable this, go to Admin > Orchestration Actions and click the download-cloud icon in the top right to view actions available on the CloudBolt Content Library. Search for “Sample async param options plugin” and import it to get started.
In addition to the expected masking and security concerns around password fields, CloudBolt also tries to determine if a password input should be presented with or without a confirmation field. The dual treatment of password fields was not aways intuitive. In version 8.1 users have the ability to switch to a more modern user experience with a single input element for all password fields that allow users to temporarily showing what is being typed. You can turn the new behavior on for all password fields by enabling Password Toggle in Admin > System > Miscellaneous Settings.
When remote scripts are written to a target *nix VM, the default directory it uses is /tmp/. For Windows VMs running remote scripts via VMware Tools, the directory is C:\Windows\Temp\. Both of those defaults can now be modified in Admin > Miscellaneous Settings.
The Stats tab for vCenter servers now includes charts for Disk I/O and Network throughput. Overall performance for this tab has been improved. In addition, stats for an individual server can now be manually refreshed from this tab.
It is now possible for users with the appropriate permission to select a recipient for an order on the order form before submitting it. The recipient will own the Server(s) and/or Resource(s) created by the order, rather than the requester (who would own them by default). This feature is also available in the API, where it can be used to replace the existing approach of setting the order owner to someone other than the API user, or in addition to it.
8.0 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
8.0 UPGRADE NOTES - XaaS Changes for your Custom Code
A variety of models, methods, and attributes have been updated to better align with the new structure of Resources in general, rather than Services in particular. If you reference any of the altered items in custom code such as actions or UI extensions, you will need to update your code accordingly.
If you have not written any custom code, you will not need to make any of these changes.
8.0 UPGRADE NOTES - XaaS API Changes
A variety of API endpoints, serialization keys, and sample scripts have been updated to better align with the new structure of Resources in general, rather than Services in particular. You’ll likely want to re-download the sample scripts here, and may need to update any of your own scripts and processes for interacting with the API.
If you do not use the API or import/ export Blueprints or Actions, you will not need to make any of these changes.
8.0 UPGRADE NOTES - Other XaaS Changes
In addition to the custom code and API-impacting changes described above, XaaS also introduced some other changes to URLs, settings, and the UI that you may need to be aware of.
8.0 UPGRADE NOTES - Hiding of the CloudBolt Admin global role
Most CloudBolt customers do not need the distinction between the Super Admin and the CloudBolt Admin global roles. To reduce confusion, the CloudBolt Admin role is now hidden by default and any user granted the Super Admin global role will automatically be granted CB Admin. When upgrading CloudBolt to 8.0, all users who have either CB Admin or Super Admin will be granted both. If you need to keep these two roles separate, you can edit customer_settings.py and add this line: CB_ADMIN_ENABLED=True.
CloudBolt has upgraded its Python version to 3.6.4.
Note
Any custom Plug-ins and UI Extensions must also be updated before upgrading to this version. Our out-of-the-box Actions have been updated to be compatible, and a guide is available to help in the transition. https://support.cloudbolt.io/hc/en-us/articles/115003824766
CloudBolt 8.0 includes an exciting paradigm shift in what can be deployed by a Blueprint. Namely, Administrators can now extend CB by defining custom Resource Types, and Blueprint managers can then choose which of those types their Blueprint should deploy, if any. If a Blueprint has a Resource Type selected, the high-level result of deploying that Blueprint (beyond what’s defined on the Build tab) will be a Resource of that type. The existing Service objects that used to be created by some Blueprint deployments are now an out-of-the-box Resource Type. While this new approach opens up many new opportunities, it does involve a shift in the way many features are conceptualized and function, so please review the Upgrade Notes for details on any changes you may need to make.
The job engine workers are now being managed by Supervisor, which can automatically restart a crashed process. The worker process libraries have also been updated, and a number of default configuration settings have been improved.
CloudBolt Admins may now remove access to the API for specific users by visiting that user’s profile and unselecting the “API Access” permission. When upgrading, all users will obtain this permission automatically. When creating new users (either manually or through a third-party authentication platform like LDAP), those users will obtain the permission as well.
In addition, CloudBolt now reports a generic error message during failed API authentication attempts to prevent malicious users from brute-forcing a list of valid usernames on the CloudBolt system.
Previously, servers were the only object for which CloudBolt tracked a rate, and while rates could be reported on groups, environments, etc., these were always aggregations of server rates. 8.0 introduces the ability to model the rate of items in Blueprints other than server tiers. For example, a Blueprint could be created with a CloudBolt Plug-in that provisions a storage bucket in a public cloud, and a rate could be associated with this item in the Blueprint. Anytime users order that Blueprint, they will create a resource that has that rate associated with it.
Admins can now define a set of labels for categorizing Blueprints in Admin > Catalog Management. Blueprint managers can then tag their Blueprints with one or more labels. This enables end users to filter their Catalog view by label in addition to group, environment, and OS build. There is a new search field to find Blueprints by name or description. The catalog can be sorted by sequence (default) or name.
Groups will now inherit parameters, along with their options and constraints, from parent groups. These parameters will influence order form customization such that inherited parameters will override any parameters previously set on sub-groups.
You can now view recent costs from AWS and Azure Resource Manager. From any AWS resource handler’s detail page, you can see last month’s total cost displayed in the Overview tab. For Azure ARM resource handlers on the public cloud, you can view a pdf of your latest invoice from the Overview tab.
This release features a number of improvements for Azure support:
We’ve provided a new tech-specific parameter ‘Auto-delete EBS Volumes on Termination’ which will be automatically added to existing AWS environments. When set to True on a server, all attached root and non-root EBS volumes will be automatically deleted on termination of the instance. This parameter will be set on servers provisioned after this upgrade. Any existing servers won’t be affected. If you don’t want this behavior, remove the parameter from AWS environments.
This release features a number of improvements to Kubernetes support:
You can now set power schedules on any resource containing servers from the resource’s ‘Power Schedule’ tab. This allows you to schedule collections of servers to be powered on or off as a group in a specific sequence. The new ‘Auto-Power Control Resources’ recurring job will use the deploy sequence from the server tiers on the Blueprint the resource was deployed from to power the servers on in order. When powering servers off, it’s done in the reverse order.
Prior to version 7.7.2, generating options for parameters using an action required a deep understanding of the CloudBolt architecture. It required, for instance, understanding all the places the action might get called from and the OOTB (out-of-the-box) behavior for parameter options. Starting in version 7.7.2, it’s possible to affect the options for a parameter on select contexts and default to the OOTB behavior in other contexts. It is also possible to bypass the OOTB filtering of generated options by constraints defined elsewhere in the product.
Support for Azure’s on-premise cloud platform has been added. Functionality should match that of Azure’s public Resource Manager. For more information, refer to https://azure.microsoft.com/en-us/overview/azure-stack/.
Past versions of CloudBolt relied on the static EC2 regions included with the botocore library to display lists of available regions to users. CloudBolt now attempts to lookup regions from the AWS web service to fetch the latest list of regions. New regions will now appear as soon as they’re available to EC2 users. If CloudBolt cannot reach AWS to fetch these regions, or the request takes too long, it falls back to the botocore static list of EC2 regions. 154526566
After fetching source code from an external system, CloudBolt will keep a cached copy. If connection to the system later fails and the source code can’t be accessed, CloudBolt will fall back to the cached version. This applies to plug-ins, remote scripts, and Kubernetes config files.
7.7 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
The job engine has been refactored to use a more robust queue and worker architecture. Default CloudBolt installations should upgrade automatically. However, high-availability environments will need to disable the the job engine on their secondary instances. For more information, see the docs on The CloudBolt Job Engine.
Remote Scripts now have a boolean field to decide if the temporary file on the target VM should be deleted after the script runs. By default, the boolean is True, and the scripts will get cleaned up. However, leaving them on the target VM can be useful for debugging purposes, so the option is provided.
7.5 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
To access context about the overall Blueprint in an action (e.g., a parameter value on one of the tiers), actions need to use Blueprint_context rather than service_context (e.g., {{ service_context.tier_name.param_name }} becomes {{ Blueprint_context.tier_name.param_name }}). You may need to update existing actions to accomodate this change to the key.
- The API sample script that CloudBolt provides to explain how to order a Blueprint through the API has been renamed from order_service.py to order_blueprint.py. You’ll likely want to re-download the sample scripts here.
- The endpoint that is used to add Blueprint deployment items to an order has changed from service-items to deploy-items. Check out the order_blueprint sample script to see how this is used.
- The structure and key names for serialization of Blueprint deployment orders has been changed. Review a Blueprint deployment order in the API browser to see how it looks now.
The Admin -> Email Settings page now has a list of Email Templates available to edit. Several templates are available out-of-the-box, and additional templates can be created as needed.
Consequently, the methods for sending emails in CloudBolt have been refactored. Before, your plug-ins were responsible for rendering an email body and sending that to the methods available in utilities.mail: email_cbadmin() for sending mail to the address set in Email Settings, and utilities.mail.send_mail() method for a particular recipient. Those two methods have been deprecated in favor of email() and email_admin(), both of which accept a ‘slug’ that is used to find the appropriate Email Template to use. For more information on how to use these methods, please refer to the Email in CloudBolt section of the docs.
The ‘Email Output Directory’ miscellaneous setting has been deprecated. If your legacy CloudBolt instances are using that setting, contact support for an alternative before upgrading.
Blueprints that do not create services can now include action Blueprint items, in addition to the servers that were already possible. Other restrictions remain. Note that the resulting orders will look a bit different than non-service deployments did previously, and more like orders that deploy a service.
This patch release fixes the following issues:
7.4 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
shell_plus
tool (Interacting with CloudBolt’s Models) in your browser.
Associate Servers
out-of-the-box Service Action. 150857994
7.3 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
The Django web-app framework that powers CloudBolt has been upgraded to Django 1.11.3.
The Servers list view and Servers tables on group, environment, service detail views have been optimized. They now generate far less load on the database and should load much faster than before (up to 5 times faster in one lab test).Some content on the server details view is now updated automatically in the background.
Security around CloudBolt plug-ins has been tightened, namely with regards to Blueprint managers who are not CloudBolt Admins. Such users will no longer be able to create new plug-ins in a Blueprint (but can still use existing plug-ins), edit the details or code of a plug-in, or import a Blueprint that contains any plug-ins.Removing parameters from a preconfiguration will now also remove those parameters from the preconfiguration’s options.
7.2.2 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
Upgraded several JavaScript libraries to the latest versions, including lodash 2.3.0, DataTables 1.10.15, and jQuery 3.2.1.
Auto-power control for servers can now be scheduled in a way that takes into account the day of the week. For existing servers, it’s also been moved to a new UI in a separate tab on the server’s details page, rather than using the Parameters tab. For setting a schedule at order time, there is a new Power Schedule parameter that can be used, with a nicer interface than before. The old Power Off Hours parameter will no longer exist, but existing server schedules should be automatically migrated to the new approach on upgrade. See the Upgrade Notes below if you have changed the action that does the checking for power changes or were using options with the old parameter.
More content samples have been added to the CloudBolt Content Library, including several service Blueprints. View these by browsing to your Catalog and toggle the ‘cloud-download’ button at the top right of the page.
Minor fixes to action and Blueprint import/export features. Service Name Template is honored if the Blueprint export specifies one. Exports for actions that have code hosted outside of CloudBolt, specified via Source Code URL, now include the actual source code in “sanitized” export format; otherwise, the URL is preserved for private exports (“include instance-specific info”).
Sync VMs jobs will now display the resource handler they are associated with.
Fixed a few bugs around LDAP and RADIUS login.
All Resource Handlers where CB gets a list of SSH keys from the handler, including Oracle, will now use the same parameter for storing those options. It has the label ‘Key pair name’ and name ‘key_name’. Everything should work as before, but you may notice a different label now when using Oracle.
Blueprint-level Parameters will now be hidden if they are considered provided by the Blueprint, meaning there is only 1 option defined for it on the Blueprint (and it’s Required, because otherwise there’s the empty option). This matches the previously-existing behavior (since 7.0) for Parameters on other items on the order form.
Ordering Blueprints that have no build items will no longer be treated as an error condition. In this situation, no inputs or buttons will be shown, but the Blueprint’s image and description will be shown. This is useful for cases where admins want to use CloudBolt as the definitive catalog to find anything to order, even if some of those things are not built by CloudBolt directly, and instead link the user to another system. See the Catalog > Informational Blueprints section of the doc for more information.
Fixed a bug where users did not have access to Blueprints they imported.
CloudBolt automatically scans action code to determine if additional input is required for the action to be executed. This process is covered in more detail in [the docs](http://docs.cloudbolt.io/advanced/orchestration-actions/remote-scripts.html#remote-scripts-parameterization). CloudBolt will handle prompting users for those inputs, and then render them in the action before executing it. Action inputs will be escaped so they can’t execute arbitrary code while still rendering as expected. However, this depends on the parameters being quoted properly in the action code. Ensure that any string inputs also include surrounding quote marks so the value is properly assigned to its variable in Python. An example: hostname = “{{server.hostname}}”.
The SDK now supports a ConnectionInfo.run_script() method that supports WinRM-based scripts today. It differs slightly from ConnectionInfo.execute_script(): * run_script() will not raise an exception if your remote script returns a non-zero exit code * run_script() will instead return an object (CommandResult) instead of a string which will provide you direct access to stdout, stderr, and exit code * run_script() will raise exceptions normally if there is a problem in the underlying remote script transport, e.g. WinRM, that prevents your script from even running on the target host
This new method is documented in CloudBolt’s model documentation, available at https://[cb_server]/alladmin/doc/models/utilities.models/ and you can use shell_plus to introspect its help, for example:
In [1]: ci = ConnectionInfo.objects.get(id=12345)<ENTER> In [2]: ci.execute_script?<ENTER> (help text)
In the future, we will expand ConnectionInfo.run_script() to provide support for SSH and will implement Server.run_script() which will provide support for SSH, WinRM, and VMware Tools. These two methods will become the only supported methods of running remote scripts from your plugins. Once we reach that milestone, we will first deprecate the execute_script() methods and the common.methods.run_script* functions they rely on by adding warnings to your logs when these older methods are used, and then we will remove them entirely in 8.0 (in 2018). We’ll be sure to give you a heads up (in future release notes) when these two milestones occur.
The first positional argument, rh, has been removed from the method signature since we can get it from the Server. Plugins calling this method will need to be refactored, else they will begin failing with a TypeError Exception (credentials_for_script() got multiple values for keyword argument ‘runas_username’).
In the future, we will deprecate this method by prefixing it with an underscore, so please do not use it.
Resource Groups and Storage Accounts can now be managed directly from CloudBolt for Azure Resource Manager environments. Environment detail pages now have tabs dedicated to handling each resource type.
On each tab, you can sync existing resources from your Azure subscription. You can add new resources directly, although both resource types can also be automatically created when provisioning a server. Existing resources can be deleted, which will remove that resource from Azure. Existing resources can also be enabled or disabled, which determines if that resource is available as a parameter for provisioning servers within the given environment.
CloudBolt 7.2.1 addresses some shortcomings from previous versions, related to server cost reporting by:
- Storing the hourly rate value for a server at the point in time a rate impacting event happens on the server
- Respecting the Orchestration Actions Compute Server Rate in the report calculations
- Moving the hard-coded discounted hardware cost for CPUs and Memory when a Server is powered off to the database, ultimately giving CloudBolt Administrators more control over the discounted rates.
To take advantadge of the new modeling, after upgrading to CloudBolt 7.2.1, one should run the following management command (this command may take a while to complete depending on the number of records in the server history table):
/opt/cloudbolt/manage.py update_server_history_events
Because of the date formatting changes in the new reports it is also important to clear any old report caching by runnning:
rm -rf /var/opt/cloudbolt/proserv/cached_reports/*
7.2 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
- Bulk user creation using a CSV file is no longer supported.
- The PKI authentication backend does not support custom roles.
7.2 UPGRADE NOTES - CloudBolt plugins for user permissions
LDAP sync scripts and other CloudBolt plugins that grant permission will need to be updated to work with the new 7.2 roles. For example, the old call
group.requestors.add(profile)
will need to be updated to the following:from accounts.models import Role role = Role.objects.get(name='requestor') profile.add_role_for_group(role, group)See the new out-of-the-box LDAP orchestration action for more examples of how the new roles work.
7.2 UPGRADE NOTES - Rate hooks
- As part of improving the AWS Rate Hook for discovered servers, a new server argument is now passed to its compute_rate method. This has 2 impacts for customers:
- If you have modified the out-of-the-box AWS Rate Hook, you will want to look at the new out-of-the-box version after upgrade and incorporate the change we’ve made into your version of the code.
- If you have written any of your own custom rate hooks, you will need to ensure that their compute_rate method can accept a server keyword argument. The best way to do this is simply to have all your action methods accept
**kwargs
.
Server tiers on Blueprints now support a notion of “allowable OS families”. This restricts the set of OS Build choices available to users when they order the Blueprints and also when Blueprint admins set the OS Build on a server tier within the Blueprint. This facilitates import and setup of Blueprints from the content library.
CloudBolt now allows the creation of custom roles. Visit the Admin > Roles page to create a role and decide which permissions it should have, then assign it to users from either the Users page or the Users tab of a group.
CloudBolt’s out-of-the-box roles are now editable, too. You can add or remove permissions on them the way you would for custom roles. You can also restore these roles back to their default state from the Admin > Roles page at any time.
The “Powerful Requestors” and “Restrict job logs to admins” miscellaneous settings have been replaced with permissions. If you had these options enabled, CloudBolt will take them into account and add the appropriate permissions during the upgrade. However, they will not be taken into account if you later revert the roles back to their default state on the Roles page.
A new parameter, ‘Delete Empty ARM Resource Group’, is available for ARM environments and servers. When set to True on a server, the associated Resource Group will also be deleted if it becomes empty after deleting the server. Otherwise, the empty Resource Group will remain. For most users, this parameter can be set as a default for an entire environment. However, some use cases might have a need to set it differently on a specific Blueprint or server deployment.
The AWS resource handler now uses the custom SSL certificates available at Admin SSL Root Certificates. If activated, the default certificates used to connect to HTTPS endpoints via the Boto library will still be used. Additional certificates can be added to supplement the list by adding them to the SSL Root Certificates page. Alternatively, SSL Certificate validation can be deactivated via that same page.
The AWS rate hook now works on servers provisioned outside CloudBolt. It is also much faster than before, and no longer requires you to manually download the rate file before using it.
When importing content that has already been imported, admins now have the choice to replace existing content or not.
The email sent to approvers when a new order is created will now show the URL for the portal where the order was placed.
Several cross site scripting (XSS) vulnerabilities were fixed. Malicious payloads on some user-supplied fields are now prevented.
To prevent the database and job logs from growing too large, CloudBolt now ships with a recurring job to clean up job records older than one year. If you would like to keep jobs for a different amount of time, go to Admin Recurring jobs and edit the job to change the threshold or disable it entirely.
7.1 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
NIC fields on the order form will now show even if there is only one option. Past orders created with a hidden NIC may not duplicate correctly, and CIT tests based on these orders may need to be recreated.
The configuration variable for MIDDLEWARE_CLASSES has changed to just MIDDLEWARE. Any references to that variable in customer_settings.py must also be changed.
The get_thread_logger method that was used in some actions is being deprecated. The correct approach is to use ThreadLogger instead. If you use get_thread_logger in any of the actions you created, please change it to ThreadLogger. Use of get_thread_logger will log a deprecation warning. A set of out-of-the-box actions have been changed from get_thread_logger to ThreadLogger, so if you have edited the code of these actions you will need to incorporate the changes to the out-of-the-box version into your edited code: delete-servicenow-ci.py, create-servicenow-ci.py, puppet_ent_3.X_discover_groups.py, puppet_ent_3.X_clean_cert.py, puppet_ent_3.X_get_node_facts.py, puppet_ent_2015.3_discover_groups.py, puppet_ent_2015.3_clean_cert.py. The setting of a logger in an action should look like:
from utilities.logger import ThreadLogger logger = ThreadLogger(__name__)
and not:
from utilities.logger import get_thread_logger logger = get_thread_logger(__name__)
If you have a custom log-in template in /var/opt/cloudbolt/proserv/templates/registration/login.html, it may have an old piece of code that needs to be updated. Please ensure the form’s action attribute looks like this:
action="{% url 'login' %}"
and not:
action="{% url 'utilities.views.login' %}"
This is required by the upgrade to the latest Django framework and avoids an error on the log-in page.
There was an issue where existing Google Compute subnetworks were not being found when syncing networks, causing them to be replaced. That has been fixed, but existing networks will need to be re-synced after upgrading and their subnetworks will need to be re-added to the appropriate environments.
The Django web-app framework that powers CloudBolt has been upgraded to Django 1.10.6.
New OS Families have been added: SUSE Linux, macOS, Amazon Linux, and Solaris.
When viewing a server that has snapshots, there is a new delete icon next to each snapshot that allows the user to delete the snapshot.
HTTPS requests made by CloudBolt now support the Certifi library for validating SSL certificates. The default for SSL verification remains deactivated. However, it can be activated at Admin SSL Root Certificates. If activated, certificates being used to connect to any HTTPS endpoints must be trusted by this new library. More information is available at https://github.com/certifi/python-certifi. Additional certificates can be added to supplement the list provided by Certifi by adding them to the SSL Root Certificates page.
Some content from the CloudBolt Forge is now available for browsing and importing directly in the user interface. Initially, Server Actions, “base” actions, and UI extensions are supported. Simply browse to the admin pages for managing these objects and click on the “cloud-download” button in the top right to view and import remote content hosted on the Content Library.
Support for more content types such as Blueprints and Rules will be implemented in the future.
The CloudBolt Forge Git repository will be deprecated in favor of this more intuitive in-product presentation. But as always, contributions to this repository of sample content are welcome. Contact CloudBolt to share your own Blueprints, actions, or UI extensions with the CloudBolt community.
7.0 UPGRADE NOTES
When upgrading CloudBolt, please review all Upgrade Notes between the version of CloudBolt that you are presently running and the target version that you are upgrading to.
7.0 UPGRADE NOTES - Version Compatibility
We have tested and verified upgrades from versions as old as CB 5.3.1. If you are running an older version, we recommend upgrading in two steps - to 6.0 first, then 7.0.
7.0 UPGRADE NOTES - MySQL
MySQL, if present on the CloudBolt server, will be upgraded to 5.7 during CloudBolt upgrade. Considerations:
"init_command": ( # Create tables using the InnoDB engine as opposed to the MyISAM engine # Django will automatically create FK mappings and support # transactions when using InnoDB based tables # this option only affects the tables at schema creation time 'SET DEFAULT_STORAGE_ENGINE=INNODB; ' # Use READ COMMITTED instead of REPEATABLE READ 'SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED' ),
7.0 UPGRADE NOTES - Breaking API Changes
7.0 UPGRADE NOTES - Puppet Enterprise
7.0 UPGRADE NOTES - Services
7.0 UPGRADE NOTES - Global Preferences
7.0 UPGRADE NOTES - Actions
7.0 UPGRADE NOTES - Continuous Infrastructure Testing (CIT)
7.0 UPGRADE NOTES - Duplicating Orders
7.0 UPGRADE NOTES - Google Authentication
7.0 UPGRADE NOTES - Rate Calculation Hooks
To simplify the ordering process, CloudBolt’s two distinct order forms have been consolidated into one. The New Server order form has been removed, and all ordering now uses Blueprints.
The New Server link still exists, but it now points to a new out-of-the-box Blueprint called Custom Server. By default, the new Blueprint can be deployed by all requestors.
Parameters no longer have a concept of Hide Single Value. Instead, they will be hidden if they have only a single option. Note that parameters that have their Required attribute set to False will never have only a single option, because they include a blank/ none option.
Ansible configuration management is now supported as a Connector in CloudBolt. Each instance of an Ansible connector can be configured to connect to a management server running Ansible. Playbooks can be mapped with their paths on the management server, and groups can be created to coordinate with inventory as it is referenced within your existing playbooks.
Playbooks can be executed against a group, server, or list of servers. Ad-hoc commands can also be executed against the inventory. Playbooks can still be managed and version controlled on the management server, but inventory can be managed by CloudBolt and is pushed to the Ansible management server before executing any command or playbook.
CB admins can now define connection information for these load balancers in the Admin UI, so that Blueprint managers only need to select from pre-defined load balancer options, and do not need to enter connection information (including credentials) for these.
Also, resource pools named “IP Pool for F5BIGIP” and “IP Pool for Netscaler” are no longer required. You can delete these if you already have them, and create new IP pools from the load balancers’ detials pages.
More information is in the “Advanced Network Support” section of the documentation.
Google Compute subnetworks are now supported by CloudBolt. When a network is imported, its associated subnetworks will also be imported, and will be listed below the network on the resource handler’s Networks table. Adding that network to an environment will also connect any subnetworks that match the region of the environment. The network and any associated subnetworks will then be available when provisioning a server within that environment.
New instance types are available. To add them to existing environments, use the import button under the AWS Parameters tab. Environments created after the 7.0 upgrade will have the new instance types by default.
The “Disk Size” parameter is now supported in AWS-backed environments. This gives you the ability to specify the size of the root storage device on new EC2 instances overriding the default size specified by the selected AMI.
The Blueprint order form will now show a preview of the hostname that will be used when ordering a server tier.
Blueprints can now be configured to not create a service when they are ordered. This only applies to Blueprints that consist entirely of server build items, and will result directly in server provisioning jobs.
The rate breakdown for each server tier in a Blueprint is now displayed as a chart.
Blueprint managers can choose to allow a Blueprint to be deployed by any group, rather than setting specific deploy permissions.
Renaming of menus, pages, and items related to Blueprints and the Catalog has been done for improved consistency and clarity.
Applications can be specified by the requestor when ordering a Blueprint. The Applications field will automatically appear on the order form when the specified environment has applications available, unless the Blueprint item has already predefined applications for that server item.
Applications can be specified when ordering a Blueprint via the API.
Blueprints now have a history tab that displays a list of events showing when it has been created, edited, duplicated, or exported.
Excellent news: edits that you have made to out-of-the-box action code will no longer be lost on upgrade! Even better, you can now see on whether an action is using the out-of-the-box code, has out-of-the-box code but is using your edited version, or was created by a user. For remote scripts and CB plug-ins that have out-of-the-box code that you have edited, when viewing the current code you can also choose to see the out-of-the-box code in order to compare the two.
CloudBolt plug-ins now support OS family restrictions, similarly to how remote scripts did previously. Setting OS families on plug-ins is optional, but if they are set and there are servers in the context where the action is being called then those servers will be filtered by OS family. Some contexts that have servers are Server Actions, Service Actions when the service has servers, Post-Provisioning Orchestration Actions starting with Pre-Create Resource, and Blueprint actions when the Blueprint has server tiers.
Actions can be given a value for max retries, which will cause the action to be re-run up to that number of times if it has an unsuccessful return status or raises an exception. Note that in the case of CloudBolt plug-ins this only applies to run methods.
Orchestration Actions can be set to continue on failure, somewhat similarly to Blueprint items. If that value is true, a failure of the Orchestration Action will not impact the rest of the job in which it runs. It will not cause the overall job to fail or change its flow. There are a few exceptions where this feature does not apply: Parameter Change, Generate Hostname Overwrite, Pre-Server Refresh, Generated Parameter Options, Order Form Validation, and Compute Server Rate.
It is now possible to define the options for a CB plugin’s action inputs using methods in the plugin itself, rather than relying on separate actions at the Generated Parameter Options trigger point.
Orchestration Actions admin view has been streamlined.
Server Actions can be configured with a particular dialog message to show and label for the submit button, as could already be done for Service Actions.
Admins can now set up automatic powering off of groups of servers based on the time of the day. For more information, look for the Recurring Job named “Auto-Power Control Servers in Admin > Recurring Jobs.
Add Actions as Recurring Jobs without an existing Job ID. Choose an existing or new Action that will be run on a recurring schedule. Action Inputs are also now supported on Recurring Jobs of this type. Existing out-of-the-box Recurring Jobs of type “Orchestration Action” will be converted to the new type (“Action”) on upgrade.
ConnectionInfo objects can now include the selection of a global SSH key.
Tests in Continuous Infrastructure Testing have a new “max retries” attribute that can be used to automatically retry the test when it fails.
CloudBolt links in emails will use HTTPS instead of HTTP.
Job logs, previously only viewable by CB admins, are now visible to all users who can view the job details. You can revert to the previous behavior by enabling “Restrict Job Logs To Admins” in Miscellaneous Settings.
Environments can now be imported and exported. Much like actions and Catalog Blueprints, exporting can be performed with or without instance-specific information.
Deletion of servers will create a new order that is submitted automatically, rather than adding to your cart and requiring user input to submit it. Also, if bulk server deletion includes servers in different groups, one order will be made for each group, allowing you to delete them all in one step.
The Django web-app framework that powers CloudBolt has been upgraded to Django 1.9.12.
Server lists now support finding servers by label. In the table search box, users simply type “label:” followed by any part of a label name to find all matching records they have permission to view.
The global search feature, found in the top nav bar, is much more responsive. Searching and navigating results can be done entirely by keyboard, making it possible to find objects across your cloud at the speed of thought.
Multiple preconfigurations can now have the same label, but different names. The names will be shown to the CB admin only to distinguish between preconfigurations with the same label. This can be useful for providing different sets of parameters and options in different environments, using a preconfiguration that looks the same to the end user.
You are awesome. Thanks for reading our release notes. It’s users like you who make the product better, and we appreciate each and every one of you for providing us feedback. Keep it coming, because it’s your requests and ideas of how we can make CloudBolt more valuable for you that drive what we work on next.
Sincerely, The CloudBolt Team