Note de release pour Mitaka¶

6.0.0¶

Added new functionality for showing and listing stack outputs without resolving all outputs during stack initialisation.

Added new API calls for showing and listing stack outputs /stack/outputs and /stack/outputs/output_key.

Added using of new API in python-heatclient for output_show and output_list. Now, if version of Heat API is 1.19 or above, Heat client will use API calls output_show and output_list instead of parsing of stack get response. If version of Heat API is lower than 1.19, outputs resolve in Heat client as well as before.

Add new OS::Barbican::GenericContainer resource for storing arbitrary barbican secrets.

Add new OS::Barbican::RSAContainer resource for storing RSA public keys, private keys, and private key pass phrases.

A new OS::Barbican::CertificateContainer resource for storing the secrets that are relevant to certificates.

OS::Nova::HostAggregate resource plugin is added to support host aggregate, which is provided by nova aggregates API extension.

nova.host constraint is added to support to validate host attribute which is provided by nova host API extension.

OS::Neutron::QoSPolicy resource plugin is added to support QoS policy, which is provided by neutron qos API extension.

OS::Neutron::QoSBandwidthLimitRule resource plugin is added to support neutron QoS bandwidth limit rule, which is provided by neutron qos API extension.

Resources OS::Neutron::Port and OS::Neutron::Net now support qos_policy optional property, that will associate with QoS policy to offer different service levels based on the policy rules.

OS::Neutron::RBACPolicy resource plugin is added to support RBAC policy, which is used to manage RBAC policy in Neutron. This resource creates and manages Neutron RBAC policy, which allows to share Neutron networks to subsets of tenants.

Added a new event-sinks element to the environment which allows specifying a target where events from the stack are sent. It supports the zaqar-queue element for now.

Adds a new « immutable » boolean field to the parameters section in a HOT template. This gives template authors the ability to mark template parameters as immutable to restrict updating parameters which have destructive effects on the application. A value of True results in the engine rejecting stack-updates that include changes to that parameter. When not specified in the template, « immutable » defaults to False to ensure backwards compatibility with old templates.

A new OS::Keystone::Region resource that helps in managing the lifecycle of keystone region.

A new OS::Neutron:AddressScope resource that helps in managing the lifecycle of neutron address scope. Availability of this resource depends on availability of neutron address-scope API extension. This resource can be associated with multiple subnet pools in a one-to-many relationship. The subnet pools under an address scope must not overlap.

New resources for Neutron Load Balancer version 2. These are unique for version 2 and do not support or mix with existing version 1 resources.

New resource OS::Neutron::LBaaS::LoadBalancer is added to create and manage Load Balancers which allow traffic to be directed between servers.

New resource OS::Neutron::LBaaS::Listener is added to create and manage Listeners which represent a listening endpoint for the Load Balancer.

New resource OS::Neutron::LBaaS::Pool is added to create and manage Pools which represent a group of nodes. Pools define the subnet where nodes reside, the balancing algorithm, and the nodes themselves.

New resource OS::Neutron::LBaaS::PoolMember is added to create and manage Pool members which represent a single backend node.

New resource OS::Neutron::LBaaS::HealthMonitor is added to create and manage Health Monitors which watch status of the Load Balanced servers.

A stack can be searched for resources based on their name, status, type, action, id and physcial_resource_id. And this feature is enabled both in REST API and CLI. For more details, please refer orchestration API document and heat CLI user guide.

Adds a new feature to restrict update or replace of a resource when a stack is being updated. Template authors can set restricted_actions in the resources section of resource_registry in an environment file to restrict update or replace.

New resource OS::Senlin::Cluster is added to create a cluster in senlin. A cluster is a group of homogeneous nodes.

New resource OS::Senlin::Node is added to create a node in senlin. Node represents a physical object exposed by other OpenStack services.

New resource OS::Senlin::Receiver is added to create a receiver in senlin. Receiver can be used to hook the engine to some external event/alarm sources.

New resource OS::Senlin::Profile is added to create a profile in senlin. Profile is a module used for creating nodes, it’s the definition of a node.

New resource OS::Senlin::Policy is added to create a policy in senlin. Policy is a set of rules that can be checked and/or enforced when an Action is performed on a Cluster.

The OS::Nova::Server now supports a new property user_data_update_policy, which may be set to either “REPLACE” (default) or “IGNORE” if you wish to allow user_data updates to be ignored on stack update. This is useful when managing a group of servers where changed user_data should apply to new servers without replacing existing servers.

Multiple environment files may be passed to the server in the files dictionary along with an ordered list of the environment file names. The server will generate the stack’s environment from the provided files rather than requiring the client to merge the environments together. This is optional; the existing interface to pass in the already resolved environment is still present.

A new OS::Neutron:SubnetPool resource that helps in managing the lifecycle of neutron subnet pool. Availability of this resource depends on availability of neutron subnet_allocation API extension.

Resource OS::neutron::Subnet now supports subnetpool optional property, that will automate the allocation of CIDR for the subnet from the specified subnet pool.

Template validation is improved to ignore the given set of error codes. For example, heat will report template as invalid one, if it does not find any required OpenStack services in the cloud deployment and while authoring the template, user might wants to avoid such scenarios, so that (s)he could create valid template without bothering about run-time environments. Please refer the API documentation of validate template for more details.

If upgrading with pre-icehouse stacks which contain resources that create users (such as OS::Nova::Server, OS::Heat::SoftwareDeployment, and OS::Heat::WaitConditionHandle), it is possible that the users will not be removed upon stack deletion due to the removal of a legacy fallback code path. In such a situation, these users will require manual removal.