CloudBolt Software CloudBolt 7.0 Release Notes Ordering 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. Conguration Managers Ansible Ansible conguration management is now supported as a Connector in CloudBolt. Each instance of an Ansible connector can be congured 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. Puppet Enterprise It is no longer required to have your Puppet Master server managed by CloudBolt in order to have a functional Conguration Manager for Puppet Enterprise 2015+. Load Balancers - F5 and Netscaler CB admins can now dene connection information for these load balancers in the Admin UI, so that blueprint managers only need to select from pre-dened 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. Resource Technologies Azure ARM New parameter “Azure ARM Resource Group” allows provisioning into an existing resource group. New parameter “Skip Security Group Creation” allows NIC-level security groups to be skipped in favor of subnet-level security groups. New add_extension method makes it easy to create actions that install extensions. See the CloudBolt Forge for an example of how to use the new method. Installed extensions will be shown on the server details page. The Azure ARM resource handler now has a method for deploying ARM templates. Refer to action_examples/deploy_azure_arm_template.py for more details on how to use this method. Google Compute Engine 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. Amazon Web Services 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 specied by the selected AMI. Blueprints 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 congured 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 specic 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 specied by the requestor when ordering a blueprint. The Applications eld will automatically appear on the order form when the specied environment has applications available, unless the blueprint item has already predened applications for that server item. Applications can be specied 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. Actions 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 ltered 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 ow. 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 dene 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 congured with a particular dialog message to show and label for the submit button, as could already be done for Service Actions. Recurring Jobs 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. General Improvements 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-specic 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 nding servers by label. In the table search box, users simply type “label:” followed by any part of a label name to nd 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 nd objects across your cloud at the speed of thought. Multiple precongurations can now have the same label, but different names. The names will be shown to the CB admin only to distinguish between precongurations with the same label. This can be useful for providing different sets of parameters and options in different environments, using a preconguration that looks the same to the end user. API Improvements GET /api/v2/settings/ allows you to view CloudBolt’s Miscellaneous Settings. Upgrade Notes Version Compatibility We have tested and veried 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 rst, then 7.0.