murano - en to en_GB translation catalogue (36 entries)

en: A configuration file setting `[engine]/agent_source` was added. The value is then used for the `pip install` command to install the murano-agent. Since pip accepts http and git URLs, this can be used to install agent from the custom git repo or install version other than the latest.
en_GB: A configuration file setting `[engine]/agent_source` was added. The value is then used for the `pip install` command to install the murano-agent. Since pip accepts HTTP and git URLs, this can be used to install agent from the custom git repo or install version other than the latest.

en: Added :command:`murano-test-tunner` command to run murano package tests.
en_GB: Added :command:`murano-test-tunner` command to run Murano package tests.

en: Added a new yaql function 'decryptData' which pairs with 'encryptData' on the dashboard side. Application authors can use these functions to secure sensitive input to their Murano applications such as passwords.
en_GB: Added a new YAQL function 'decryptData' which pairs with 'encryptData' on the dashboard side. Application authors can use these functions to secure sensitive input to their Murano applications such as passwords.

en: Added magnum plugin to murano, that allows creating/deleting of magnum baymodels and bays from MuranoPL
en_GB: Added Magnum plugin to Murano, that allows creating/deleting of Magnum baymodels and bays from MuranoPL

en: Added public field to environment templates. GET method for api now displays public templates from other projects(tenants).
en_GB: Added public field to environment templates. GET method for API now displays public templates from other projects(tenants).

en: Added public filter to environment templates api.
en_GB: Added public filter to environment templates API.

en: Added the ``api_workers`` option to ``murano`` config group. It controls the number of API workers launched by murano. If not set, it would default to the number of CPUs available.
en_GB: Added the ``api_workers`` option to ``murano`` config group. It controls the number of API workers launched by Murano. If not set, it would default to the number of CPUs available.

en: Added the ``driver`` configuration option to the ``networking`` group. It allows to explicitly select the networking driver. It supports 'neutron' and 'nova' options. If set to ``None`` (default), murano attempts to use 'neutron' if available, 'nova' otherwise. The change is backward compatible.
en_GB: Added the ``driver`` configuration option to the ``networking`` group. It allows to explicitly select the networking driver. It supports 'neutron' and 'nova' options. If set to ``None`` (default), Murano attempts to use 'neutron' if available, 'nova' otherwise. The change is backward compatible.

en: Due to refactoring, contracts work a little bit faster because there is no more need to generate yaql function definition for each contract method on each call.
en_GB: Due to refactoring, contracts work a little bit faster because there is no more need to generate a YAQL function definition for each contract method on each call.

en: Fixed a bug when the UI dialog was not displayed in Murano Dashboard for applications which don't have UI definitions bundled in the package but generate them based on the package contents instead. This usually affected HOT-based packages and other non-muranopl-based applications.
en_GB: Fixed a bug when the UI dialogue was not displayed in Murano Dashboard for applications which don't have UI definitions bundled in the package but generate them based on the package contents instead. This usually affected HOT-based packages and other non-muranopl-based applications.

en: Fixed incorrect murano behaviour if deployed on devstack with keystone v3 by default.
en_GB: Fixed incorrect Murano behaviour if deployed on devstack with keystone v3 by default.

en: Heat stacks created by murano during environment deployment now have 'murano' tag by default. This is controlled by ``stack_tags`` config parameter.
en_GB: Heat stacks created by Murano during environment deployment now have 'murano' tag by default. This is controlled by ``stack_tags`` config parameter.

en: Implemented a new framework for MuranoPL contracts. Now, instead of several independent implementations of the same yaql methods (string(), class() etc.) all implementations of the same method are combined into single class. Therefore, we now have a class per contract method. This also simplifies development of new contracts. Each such class can provide methods for data transformation (default contract usage), validation that is used to decide if the method can be considered an extension method for the value, and json schema generation method that was moved from the schema generator script.
en_GB: Implemented a new framework for MuranoPL contracts. Now, instead of several independent implementations of the same YAQL methods (string(), class() etc.) all implementations of the same method are combined into single class. Therefore, we now have a class per contract method. This also simplifies development of new contracts. Each such class can provide methods for data transformation (default contract usage), validation that is used to decide if the method can be considered an extension method for the value, and JSON schema generation method that was moved from the schema generator script.

en: Internally, both pre-deployment garbage collection (that was done by comparision of ``Objects`` and ``ObjectsCopy``) and post-deployment orphan object collection are now done through the new GC.
en_GB: Internally, both pre-deployment garbage collection (that was done by comparison of ``Objects`` and ``ObjectsCopy``) and post-deployment orphan object collection are now done through the new GC.

en: Introduced a new MuranoPL class ``io.murano.system.GC`` Now MuranoPL garbage collector can be used to set up destruction dependencies between murano objects. If object Foo is subscribed to object Bar's destruction, it will be notified through a specific handler. If both Foo and Bar are going to be destroyed during one execution session, Foo will be destroyed after Bar. You can omit the handler, in this case destruction order will also be preserved. Handler can be a static or a usual function.
en_GB: Introduced a new MuranoPL class ``io.murano.system.GC`` Now MuranoPL garbage collector can be used to set up destruction dependencies between Murano objects. If object Foo is subscribed to object Bar's destruction, it will be notified through a specific handler. If both Foo and Bar are going to be destroyed during one execution session, Foo will be destroyed after Bar. You can omit the handler, in this case destruction order will also be preserved. Handler can be a static or a usual function.

en: Murano engine no longer logs methods ``string()``, ``json()``, and ``yaml()`` of the 'io.murano.system.Resources' class. This is done to prevent UnicodeDecodeError's when transferring binary files to murano agent.
en_GB: Murano engine no longer logs methods ``string()``, ``json()``, and ``yaml()`` of the 'io.murano.system.Resources' class. This is done to prevent UnicodeDecodeError's when transferring binary files to Murano agent.

en: Murano is now able to assign correct floating IPs when using multiple external networks. It attempts to choose one that shares a router with internal network.
en_GB: Murano is now able to assign correct Floating IPs when using multiple external networks. It attempts to choose one that shares a router with internal network.

en: Murano is now able to work with keystone configured to use a templated catalog.
en_GB: Murano is now able to work with Keystone configured to use a templated catalogue.

en: Murano no longer specifies fixed-ip parameter for ports when creating VMs attached to networks owned and shared by other tenants. Specifying this parameter for non-owned networks could cause violation of neutron policies.
en_GB: Murano no longer specifies fixed-ip parameter for ports when creating VMs attached to networks owned and shared by other tenants. Specifying this parameter for non-owned networks could cause violation of Neutron policies.

en: Murano switched to using standard oslo middleware HTTPProxyToWSGI instead of custom implementation. This middleware parses the X-Forwarded-Proto HTTP header or the Proxy protocol in order to help murano respond with the correct URL refs when it's put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.
en_GB: Murano switched to using standard Oslo middleware HTTPProxyToWSGI instead of custom implementation. This middleware parses the X-Forwarded-Proto HTTP header or the Proxy protocol in order to help Murano respond with the correct URL refs when it's put behind a TLS proxy (such as HAProxy). This middleware is disabled by default, but can be enabled via a configuration option in the oslo_middleware group.

en: Murano was migrated to yaql 1.1
en_GB: Murano was migrated to YAQL 1.1

en: New format MuranoPL/1.3 can be specified in manifest files. MuranoPL/1.3 is identical to MuranoPL/1.2 but except for the fact that MuranoPL/1.3 packages cannot be imported to earlier Murano versions. Thus applications that use new features of yaql 1.1 should use this format version.
en_GB: New format MuranoPL/1.3 can be specified in manifest files. MuranoPL/1.3 is identical to MuranoPL/1.2 but except for the fact that MuranoPL/1.3 packages cannot be imported to earlier Murano versions. Thus applications that use new features of YAQL 1.1 should use this format version.

en: New on-request garbage collector for MuranoPL objects were implemented. Garbage collection is triggered by io.murano.system.GC.collect() static method. Garbage collector destroys all object that are not reachable anymore. GC can handle objects with cross-references and isolated object graphs. When portion of object model becomes not reachable it destroyed in predictable order such that child objects get destroyed before their parents and, when possible, before objects that are subscribed to their destruction notifications.
en_GB: New on-request garbage collector for MuranoPL objects were implemented. Garbage collection is triggered by io.murano.system.GC.collect() static method. Garbage collector destroys all object that are not reachable any more. GC can handle objects with cross-references and isolated object graphs. When portion of object model becomes not reachable it destroyed in predictable order such that child objects get destroyed before their parents and, when possible, before objects that are subscribed to their destruction notifications.

en: Previously murano assumed that the service user and service project are in the 'Default' domain. These values can now be set in ``keystone_authtoken`` config group.
en_GB: Previously Murano assumed that the service user and service project are in the 'Default' domain. These values can now be set in ``keystone_authtoken`` config group.

en: Previously, when a class overrode a property from its parent class the value was stored separately for both of them, transformed by each of the contracts. Thus each class saw the value of its contract. In absolute majority of the cases, the observed value was the same. However, if the contracts were compatible on the provided value (say int() and string() contracts on the value "123") they were different. This is considered to be a bad pattern. Now, the value is stored only once per object and transformed by the contract defined in the actual object type. All base contracts are used to validate the transformed object thus this pattern will not work anymore.
en_GB: Previously, when a class overrode a property from its parent class the value was stored separately for both of them, transformed by each of the contracts. Thus each class saw the value of its contract. In absolute majority of the cases, the observed value was the same. However, if the contracts were compatible on the provided value (say int() and string() contracts on the value "123") they were different. This is considered to be a bad pattern. Now, the value is stored only once per object and transformed by the contract defined in the actual object type. All base contracts are used to validate the transformed object thus this pattern will not work any more.

en: Previously, when pre-deployment garbage collection occurred it executed ``.destroy`` method for objects that were present in the ``ObjectsCopy`` section of the object model (which is the the snapshot of the model after last deployment) and not present in the current model anymore (because they were deleted through the API between deployments). If the destroyed objects were to access another object that was not deleted it was accessing its copy from the ``ObjectsCopy``. Thus any changes to the internal state made by that object were lost after the garbage collection finished (that is, before the ``.deploy`` method call) and could not affect the deployment. Now, if the object is present in both ``Objects`` and ``ObjectsCopy``, a single instance (the one from ``Objects``) is used for both garbage collection and deployment. As a consequence, instances (in their ``.destroy`` method) now may observe changes made to other objects they refer if they were not deleted, but modified through the API. In some rare cases, it may break existing applications.
en_GB: Previously, when pre-deployment garbage collection occurred it executed ``.destroy`` method for objects that were present in the ``ObjectsCopy`` section of the object model (which is the the snapshot of the model after last deployment) and not present in the current model any more (because they were deleted through the API between deployments). If the destroyed objects were to access another object that was not deleted it was accessing its copy from the ``ObjectsCopy``. Thus any changes to the internal state made by that object were lost after the garbage collection finished (that is, before the ``.deploy`` method call) and could not affect the deployment. Now, if the object is present in both ``Objects`` and ``ObjectsCopy``, a single instance (the one from ``Objects``) is used for both garbage collection and deployment. As a consequence, instances (in their ``.destroy`` method) now may observe changes made to other objects they refer if they were not deleted, but modified through the API. In some rare cases, it may break existing applications.

en: Removed `show_categories` endpoint from the application catalog API which has been deprecated since the Liberty cycle. Use `list_categories` instead.
en_GB: Removed `show_categories` endpoint from the application catalogue API which has been deprecated since the Liberty cycle. Use `list_categories` instead.

en: RequestContext now serialises it's roles. This should allow murano to work correctly (and allow rules like "role:xxx" in policy.json) when using oslo.context prior to 2.2.0 and oslo.policy
en_GB: RequestContext now serialises it's roles. This should allow Murano to work correctly (and allow rules like "role:xxx" in policy.json) when using oslo.context prior to 2.2.0 and oslo.policy

en: Separated murano service broker from murano-api into a murano-cfapi service. Created a separate database and ``paste.ini`` for service broker.
en_GB: Separated Murano service broker from murano-api into a murano-cfapi service. Created a separate database and ``paste.ini`` for service broker.

en: The ``string()`` contract no longer converts everything to string values. Now it only converts scalar values to strings. Previous behavior allowed ``string()`` property to accept lists and convert them to their Python string representation which is clearly not what developers expected.
en_GB: The ``string()`` contract no longer converts everything to string values. Now it only converts scalar values to strings. Previous behaviour allowed ``string()`` property to accept lists and convert them to their Python string representation which is clearly not what developers expected.

en: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backward compatible way.
en_GB: The default value of ``[oslo_policy] policy_file`` config option has been changed from ``policy.json`` to ``policy.yaml``. Operators who are utilising customised or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the `oslopolicy-convert-json-to-yaml <https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html>`_ tool to convert a JSON to YAML formatted policy file in backward compatible way.

en: The value that is stored in the object's properties is obtained by executing special "finalize" contract implementation which by default returns the input value unmodified. Because validation happens on the transformed value before it gets finalized it is possible for transformation to return a value that will pass the validation though the final value won't. This is used to relax the template() contract limitation that prevented child class from excluding additional properties from the template.
en_GB: The value that is stored in the object's properties is obtained by executing special "finalise" contract implementation which by default returns the input value unmodified. Because validation happens on the transformed value before it gets finalized it is possible for transformation to return a value that will pass the validation though the final value won't. This is used to relax the template() contract limitation that prevented child class from excluding additional properties from the template.

en: Use of JSON policy files was deprecated by the ``oslo.policy`` library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by ``oslo.policy``. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on migration of any custom policy files.
en_GB: Use of JSON policy files was deprecated by the ``oslo.policy`` library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by ``oslo.policy``. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on the migration of any custom policy files.

en: When updating to Mitaka, the operator should update service name and type for endpoint in keystone from "application_catalog" to "application-catalog" if SQL is used for catalog back-end driver.
en_GB: When updating to Mitaka, the operator should update service name and type for endpoint in Keystone from "application_catalog" to "application-catalog" if SQL is used for catalogue back-end driver.

en: Whenever murano-engine accesses script files, text script files are opened in 'rU' mode which recognizes all types of newlines, and binary files are opened in 'rb' mode to prevent their corruption.
en_GB: Whenever murano-engine accesses script files, text script files are opened in 'rU' mode which recognises all types of newlines, and binary files are opened in 'rb' mode to prevent their corruption.

en: cve-2016-4972 has been addressed. In ceveral places Murano used loaders inherited directly from yaml.Loader when parsing MuranoPL and UI files from packages. This is unsafe, because this loader is capable of creating custom python objects from specifically constructed yaml files. With this change all yaml loading operations are done using safe loaders instead.
en_GB: cve-2016-4972 has been addressed. In several places Murano used loaders inherited directly from yaml.Loader when parsing MuranoPL and UI files from packages. This is unsafe, because this loader is capable of creating custom Python objects from specifically constructed YAML files. With this change all YAML loading operations are done using safe loaders instead.
