Now, when we started to use oslo.serialization it is safe
to replace all the usages of anyjson with jsonutils from
oslo library.
oslo.serialization uses anyjson under the hood, so there
shouldn't be any performance changes.
Change-Id: I8d6fbfbf88e657f5586c7361de849683c064d2e2
Removed #noqa from gettextutils and added them to import_exceptions.
I think it is better to specify option in one place (tox.ini) than
every time take care that you do not forget to specify this tag.
Also removed a few unused imports that were revealed in the process.
Change-Id: Ic4ca9cf374870075a36b88269ff8aea5a8e24a90
Instead of using user's auth token (which can expire) for interactions with
other services engine creates Keystone trust that impersonate user and
create new tokens on demand.
Heat stack is created on deployment start using token rather than trust so that
Heat could establish trust of its own (trusts cannot be chained).
New behavior is disabled by default and can be enabled using [engine]/use_trusts = True in murano.conf.
With trusts enabled engine will not work with Heat prior to Juno.
For Heat stacks with deferred actions or long deployment time to work it is also required to turn on trusts in Heat itself.
This can be done via [DEFAULT]/deferred_auth_method=trusts in heat.conf and ensuring that current user
has heat_stack_owner role (or any other that is in [DEFAULT]/trusts_delegated_roles=trusts in heat.conf)
Change-Id: Ic9f3f956ddb6ff2a300a08056ee841cf3c0db870
Implements: blueprint auth-for-long-running-requests
Now environment deletion is done as a regular deployment that can fail.
Environments that are deleted, but deletion process has failed remain in database
and shown in dashboard with status 'delete failure'. Environments that are being deleted
has status 'deleting' and do not disappear before they really got deleted on engine side
Also improved status reporting for environments. Now it also reports status of last deployment -
'deploy failure', 'delete failure'
P.S. Functional tests were slightly refactored and fixed to reflect changes
in deletion logic
Change-Id: I05625dd71f7ca9559bb88319b26b122214f15019
Closes-Bug: #1325101
Python frames in mixed stack traces were missing file name and pointed to a line
below correct position
Change-Id: I335292f40b3b6ea3dbca80b84f1d8dbed9a6581d
Fixes: bug #1331113
With this change MuranoPL can find correct base class method
where old implementation would throw AmbiguousMethodName.
Also removes possibility to have several methods with the same name
but different signature. This feature didn't worked in most cases,
never used anc could cause unexpected program behavior
Implements: blueprint muranopl-multiple-inheritance-method-resolution
Change-Id: I0a3149b993b1b8a9e9166fce13999e7dd7bf48a5
Methods in MuranoPL now can be marked with Usage attribute
to specify whether particular method available for remote
call or not. By default usage is Runtime (not available for
remote call).
Workflow:
migrateVm:
Usage: Action
Arguments:
- killExisting:
Contract: $.bool()
Default: True
Change-Id: If3da3c6bf67aa79d522d82abbf3b5378f72e87ae
Partially-Implements: blueprint application-actions
Adds support for packages consisting of single HOT template.
Most of HOT features are supported with exception of
environments, attachments and JSON parameter type.
Implements: blueprint hot-packages
Change-Id: I927af0e96f1613e8843ac47844e9c19fa00fdaa6