Make a few cleanups:
- Remove obsolete sections from setup.cfg
- Use sphinx-build for building, fix problems found
- Cleanup tox.ini
- Use newer openstackdocstheme option, remove obsolete config
Change-Id: I7a3788858af70d4349d21dcf04907b42365985c1
Ability to cryptographically sign messages sent from
murano-engine to the agents in order to reject messages
that are coming from malicious users
Change-Id: I03b6e5835aa3534b29d7e281c5c90eb320b97e22
Define and register default policy operations in code similar to
how config options currently are.
Specifies blueprint policy-in-code
Change-Id: I5e135302e7bcd64aed6276c97a2a87e861c21ae1
The spec proposes mechanism for users to edit any details of an
existing environment, for example edit its regions, set home
region, change the networks or any other possible input field.
APIImpact
Targets-bp: environment-edit
Change-Id: I81d6799828deec9c8ba4345e5da157e47628e600
Cloud users and operators may need to assign some arbitrary key-value
pairs to environments and applications deployed by murano to associate
some meta information with them. If applicable this metadata
attributes should be propagated to OpenStack resources provisioned by
Murano.
Targets-blueprint: metadata-assignment-and-propagation
Change-Id: I57607e59b9c10f37e5140c07da4346b2fe5c2778
The spec proposes mechanism that cloud operators can use to impose
constraints on applications and alter application behavior without
making modifications to the source code of the apps.
APIImpact
Change-Id: Ib967242a624182c072b02a1a9bbda7746a527747
Co-Authored-By: slagun <slagun@mirantis.com>
Co-Authored-By: vakovalchuk <vakovalchuk@mirantis.com>
Murano components may allocate various kinds of resources: virtual
machines, networks, volumes etc. When these components get removed
from the deployment appropriate resources have to be deallocated.
Current implementation of this process has some significant
limitations and flaws.
This specification aims to address these issues and provide a design
for the better resource deallocation / garbage collection system for
MuranoPL.
Spec-for-blueprint: dependency-driven-resource-deallocation
Change-Id: I0499fa6e4d80798a88d8124622ccfbb1c2099357
Murano doesn't have validation mechanisms for MuranoPL language and
application packages.
This spec proposes a validation toolkit that improves workflow
by making error detection possible at the early stages of application
development lifecycle.
Change-Id: Iae057c87f014cc7151a38217c42f0e7e75f8037f
Implements: blueprint murano-app-validation
Build a library of MuranoPL classes to define basic building blocks
for the applications utilizing standard patterns for scaling, load
balancing, healing etc, allow the apps to be deployed on various
clouds (supporting both multiple regions of OpenStack and other cloud
types as well).
Change-Id: I84d4f3dfec861f282602e57f076b16d3dc4c7556
Spec that defines new json-schema based form definition
that is going to replace current UI definition files. The
schema is generated per class from MuranoPL code
including contracts and meta-data. The spec also
describes how clients should interact with new forms
without loosing backward compatibility and how to make
object model generation be MuranoPL driven without
filling all the property values.
APIImpact
Change-Id: Ic32bb3101f907107c2c0e083d3b29f055df9f0eb
One of the foundations for NFV enabled clouds is to have Networking
Service Function Chaining which provides an ability to define an ordered
list of network services which to form a “chain” of services.
This could be used by f.e. Telcos to simplify management of their
infrastructure.
Implements blueprint: plugin-networking-sfc
Change-Id: I2fff8f01949a708e0251ad860fbd0a238c9e92fc
Current naming scheme for classes defined in MuranoPL extension
plugins is not consistent with the naming scheme for regular MuranoPL
classes and packages.
This spec addresses this by changing the scheme and proposing a
fallback logic which will provide a backward compatibility for the
existing MuranoPL applications targeting old plugins.
Change-Id: I05da65257b0002a2ecafe2b680d9ee6495b06474
The main differences with original spec:
1) Inherited keyword was introduced. The restriction for meta not
to be inherited was removed.
2) The requirement for metadata to be immutable was removed.
3) For Applies keyword: "Class" was changed to "Type"
4) For meta-classes the usage is "Meta" rather than "MetaAttribute"
5) Meta-classes are represented by "MuranoMetaClass" class
rather than "MetaAttribute"
Change-Id: I0d31afbbacbc75f87495fa4d314c9003ae0c5954
This specification defines the design of Murano Service API SDK - a
high level client library allowing cloud applications (both
murano-deployed and external) to access applications's Service API in
consistent, convenient and secure way.
Change-Id: I6f1ba7b9079fc6ad5ef4ead491460506169d7d39
Describes how 3rd party systems that are not OpenStack aware
can call Murano application actions using pre-authenticated URIs.
Targets blueprint: actions-authentication-and-visibility
Change-Id: I7c9e2bddb9c6a0b1fe9aef1ec92307aba1a68a14