Jump to: navigation, search

Murano/ReleaseNotes v0.2

< Murano
Revision as of 12:21, 5 September 2013 by Timur Sufiev (talk | contribs) (REST API Changes)

Murano v0.2 is a second stable release of Murano. Check out "What’s New", "Improvements", "Bugs Fixed" and "Known Issues" for this version of Murano below. If interested, please see the complete list of changes in this release.

What's new

Workflow diagnostics in Murano Conductor

New tags were added to XML workflow definition language to provide more precise control over workflow execution, report various error conditions and warnings, make rules applicable only once etc. Workflow rules has got description, excessive logging have been added to provide detailed execution plan of any workflow.

Dynamic UI

Dynamic UI means moving form definitions, data processing logic and texts from Python code and Django templates into separate service definitions in human-readable YAML format. Service definitions separated from Python code provide much greater flexibility in adding, modifying and removing services. The format simplicity allows non-programmers to use it: even if there are some errors in service definition, it simply won't be shown in services list (and won't crash the whole dashboard). Dynamic UI employs YAML for forms markup and YAQL (Yet Another Query Language, developed specially for Murano Workflows) for form validation and initialization logic.

Support for SSL both in REST API and RabbitMQ communications

To improve security in Murano we have added support for SSL on all communication levels between our components. All components communicate with each other by RabbitMQ and this interaction can be encrypted now with SSL. How to configure SSL encryption can be found in our developers guide.

Additionally we have added ability to secure all communications with our API by adding support for SSL endpoint in our REST API service. API HTTPS configuration can also be found in our developers guide.

Ability to select Windows image, Availability Zone and instance flavor

A new common dialog step has been added to "Create Service" UI, which allows to select Instance Flavor (hardware configuration), Windows Image (pre-create Glance image, marked with an appropriate metadata tag) and Availability Zone (one of those defined in OpenStack). Windows Image field is mandatory for selection, while others may be left unset, so conductor will use configurable default values instead

External Active Directory

External Active Directory is implemented as conductor's functionality extension: it is available after enabling ExternalAD.xml workflow template in the murano-conductor service. This feature allows to use most of the murano supported services with existing windows domain (should be configured before).

Additional Services

Murano v0.2 supports deployment of several new services: MS SQL Server single instance and MS SQL Server Always On Cluster.

MS SQL Server

This type of service provides deployment of the MS SQL Server 2012 in standalone mode per instance.

MS SQL Server AlwaysOn Cluster

This type of service is the most complex one of all supported services. It actually contains 2 services under the hood, namely "Active Directory" and "MS SQL Server Cluster".
At high-level the service structure features the following components:

  • Active Directory windows domain.
  • Windows Server Failover Cluster.
  • MS SQL Server stanalone install per instance.
  • MS SQL AlwaysOn Availability Group functionality.

Improvements

Detailed documentation for writing XML Workflows

Murano Workflow XML DSL specification created and published at github.io

This DSL should be used when writing new workflows and modifying existing ones.

Improved HA for Murano Conductor

All components of Murano are High-Available now. Murano-API is stateless, so it can be placed behind a load balancer. The state of the Workflow is idempotent, so in case of the conductor failure secondary conductors will repeat the actions of the unfinished deployments without any unwanted side effects.

REST API Changes

Several changes are introduced to API specification to support extensible and pluggable architecture:

  • Universal endpoint for services
  • Tree traversing and set syntax

Major change is universal endpoint for all services. Previously we had endpoints like: “/environment/<env_id>/activeDirectories/*” for each service, and now single endpoint for all services is introduced, like: “/environment/<env_id>/services/*”.

In order to make our API more user-friendly and reduce amount of calls and data sent we also introducing two complementing features: tree traversing and set syntax.

More details about this feature can be found in the blueprint.

Bugs Fixed

A complete list of bugs fixed in Murano v0.2 can be found here.

Known Issues

Actual bug state can be found in Murano Launchpad page

  • Due to current Heat limitation services that involve load-balancer creation (farms) can be deployed only by tenant administrators.
  • When Heat creates different clients for Nova, Cinder and others it doesn't pass SSL-related options to clients' constructor. If Nova is configured to have SSL endpoints and self-signed certificates Heat will fail to create instances because there is no way to disable server certificate validation as there is no "insecure" flag passed etc.
  • Murano-Conductor doesn't work with python-heatclient>0.2.1.
  • Farm services can't be deployed without KeyPair. If KeyPair is not set load balancer won't be created (link on bug description). Deploy will hang up and these messages will show up in logs:
2013-08-06 09:10:07 - Unable to deploy instance ipkrmhk0vzq4b6 (asp-farm_instance_0) due to Unexpected state
2013-08-06 09:10:07 - Unable to create a Server Farm load balancer on unit ipkrmhk0vzq4b6 (asp-farm_instance_0) due to Unexpected state
  • User can select incorrect parameters for service, like incompatible flavor and VM image. In this case user will see the following error in the log:
Unable to deploy instance demo (demo.com_instance_0) due to Unexpected stack state NOT_FOUND