Added an ability to retrieve information about the current user,
current project, environment owner (both user and project)
from keystone. Appropriate information (including
extra fields but excluding internal system data) is fetched from
Keystone using the same service credentials that are used to validate
tokens, create trusts etc.
- io.murano.User and io.murano.Project classes were added.
- Both classes have 2 static methods to get current and environment
owner object of appropriate class
- Object model now contains project_id/user_id of the user who
created the environment
- Deployment task contains project_id (renamed from tenant_id)
and user_id of the user who initiated the deployment
Change-Id: Ic7e24c1d2b669ed315851047bcdb27e075cfc56b
Added a python-backed class io.murano.system.MetadefBrowser providing
a read-only access to Glance Metadefinition Catalog. The class can
fetch namespaces mapped to a particular resource type and the contents
(objects) of a given namespace. Since the catalog is not updated
frequently the class provides caching capabilities for the fetched
data.
The MuranoPL part of the class provides a single method called
canBeAppliedTo which may be used to check whether some tag can be
applied to a particular type of resource.
Since Glance connectivity is required, a new configuration section is
added to provide capabilities to tune conection properties (url,
endpoint type, encryption etc).
Change-Id: I8ea70e314dbe701b462fb1620376965af717c10d
Targets-blueprint: meta-attribute-assignment-and-propagation
If the object was deleted through the API between deployments
the only way for those who used to subscribe to its destruction
to be notifyed upon next deployment is to persist destruction
dependencies to the object model.
This commit adds such serialization and deserialization.
Also move GC class from engine to dsl
Targets-blueprint: dependency-driven-resource-deallocation
Closes-Bug: #1619248
Change-Id: Icd2e882be5770244aa1ecafe265aff1439ebec9e
This is an initial commit for MuranoPL garbage collector implementation.
A first step of GC implementation is implementation of destruction
dependencies between applications. Destruction dependencies works as
described below.
Since murano still have a problem described in a spec, it was decided
to skip serialization/deserialization steps for destruction dependencies
for now at least.
If object Foo establishes such a dependency on the object Bar then:
* Foo will be notified when Bar is about to be destroyed.
* If both Foo and Bar are going to be destroyed in the same garbage
collection execution, Bar will be destroyed before Foo.
Change-Id: I33eb8e09773aebe0a08542b70171466a0b849885
Targets-blueprint: dependency-driven-resource-deallocation
- Use 401 error to determine work of Murano API in shell via curl
- Change tempest parameters in utils
- Rename mistralclient.py to workflowclient.py due names conflict in
path.
Closes-Bug: #1614602
Change-Id: I91bdda91da929b183393c4210af86bce619a53ec
With this change MuranoPackage becomes first-class DSL citizen.
Packages have version, runtime_version (that is specified
in Format attribute of the manifest file) and a list of classes.
Previously engine used to have package loader which had most
of "load" functionality and class loader that mostly acted as an
adapter from package loader to interface that DSL used to
get classes. Now class loader is gone and is replaced with
package loader at the DSL level. Package loader is responsible
for loading packages by either package or class name (as it was
before) plus semantic_version spec (for example ">=1.2,<2.0").
Package loader can now keep track of several versions of the same
package.
Also packages now have requirements with version specs.
All class names that are encountered in application code are
looked up within requirements only. As a consequence
packages that use other packages without referencing
them explicitly will become broken. An exception from this rule
is core library which is referenced automatically.
Partially implements: blueprint murano-versioning
Change-Id: I8789ba45b6210e71bf4977a766f82b66d2a2d270
Add new API calls that will provide logging and can be
consumed by MuranoPL workflows. It will improve debuggability.
Application author can use logs to improve application quality.
Implements: blueprint logging-api-for-muranopl
Change-Id: I747cf7f5fca20960f2304605e1c7241f465f5dc1
* Code migrated to yaql 1.0.0
* New MuranoPL object initialization
* Lots of refactoring
See referenced specs for more information
Implements: blueprint migrate-to-yaql-vnext
Implements: blueprint object-construction
Depends-on: I7f314634ab5f08a521e51082d5c84dffca4b0b5c
Closes-Bug: #1454264
Change-Id: I740a4f83c76d8b56a1da585a739d770ef823a524
New class is created that is responsible to run Mistral workflows.
The workflow that can be run hare is already uploaded workflow.
Partially Implements: blueprint murano-mistral-integration
Change-Id: I6b6251d06aa3ce9bf103a67fe354b8c49f52d193
io.murano.system.Resources class tried to access resource files
belonging to the instance's class rather than the class that owns
sys:Resources instance. So when derived class is located in different
package than its base class inherited methods become using resources
of derived class package.
Closes bug: #1328176
Change-Id: I85719c612ad0d62c82f83f9e584278fba0825688
Alexander Tivelkov