This commit is part of a series to retire the Packaging Deb
project. Step 2 is to remove all content from the project
repos, replacing it with a README notification where to find
ongoing work, and how to recover the repo if needed at some
future point (as in
https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project).
Change-Id: I0a72f3bba5b5529fcc670df34aaaae76fcb2016c
Currently it's not convienent to debug about the
relationship between two nodetemplates, this patch
add more debug information when exception happends.
Change-Id: I91a6ed0cb6c9675d76f620c742c8546c457b239b
Signed-off-by: shangxdy <shang.xiaodong@zte.com.cn>
When import list yaml in top service template, and the nested templates
also import list yaml, the final type definition is not imported complete.
Change-Id: I8931d2ee4bcb9e3d4c82ac36ef3e6844ca78c165
Signed-off-by: shangxdy <shang.xiaodong@zte.com.cn>
Currently monitoring policy in Tacker is not fully validated in tosca-parser.
This made monitoring feature beoken in Tacker.
Change-Id: Iebe961eb38e36ac55a212482596c2a30fd75f1c8
The node template "app" (that is the one instantiating
"example.SomeApp" in the topology) is connected to the node "websrv",
which is of type "tosca.nodes.WebServer", which is not a valid target
for the requirement "host".
We fixed the definition of the type "example.SomeApp" to derive "example.SomeApp" from "tosca.nodes.WebApplication", whose "host"
requirement has to be satisfied by a "tosca.nodes.WebServer".
Change-Id: I16e697bcd9f1728df1d0b18595fdb4a703f41d26
Closes-bug: #1663681
Since pbr already landed and the old version of hacking seems not
work very well with pbr>=2, we should update it to match global
requirement.
Partial-Bug: #1668848
Change-Id: Id7c7d58c845335b8defb4fbb33ae4a0da848d00f
This patch will focus on:
1. Defining a monitoring node as an EXPERIMENTAL feature
2. Enhancing trigger to further support monitoring policy
3. Validating trigger policy
Change-Id: Idd5268b7ff0a19b57ea927f23c76db24220c462d
Fix validation for invalid type when found along with an imports section
in a TOSCA template.
Change-Id: I6b0c6299c1ef96b037527db68f9f86a5a81dded5
Closes-Bug: #1656994
Test template to provide an example of how to overrride TOSCA normative
type properties in custom type.
Change-Id: I91d1a9170d47f8313c24b194ad264898830a87c4
Adding constraints support to libraries is slightly more complex than
services as the libraries themselves are listed in upper-constraints.txt
which leads to errors that you can't install a specific version and a
constrained version.
This change adds constraints support by also adding a helper script to
edit the constraints to remove tosca-parser.
Change-Id: Ia9d0bee95a0541eb308d1fb273319209187ce64b
1. Validate that the attributes of the substitution mappings node type can be
accessed in the service template by substituted node.
2.Validate that an attempt to access any attributes not belong to a specific
node type or substitution mappings results into an expected error.
This patch is related to bp: https://review.openstack.org/#/c/345492/
Co-Authored-By: Sahdev Zala <spzala@us.ibm.com>
Change-Id: I5f6cdcf7eb66f20ba9e524b73edd249d2c7b1e31
Add input validation in class of substitution_mapping according to
specification of
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/
TOSCA-Simple-Profile-YAML-v1.0.html:
1) The properties of substituted node template which be mapped must be
in the inputs of nested service template which defines substutition
mappings;
2) The inputs of nested service template which are not in properties of
the substituted node template must have default values.
3) If the properties of node_type is required and no default value,
must provide inputs for them;
4) Property names and the input names must be the same.
This patch is related to bp:https://review.openstack.org/#/c/345492/
Change-Id: Ib928434ec67661e689ac80cca1749b53d17e4ba8
Signed-off-by: shangxdy <shang.xiaodong@zte.com.cn>
Following OpenStack Style Guidelines[1]:
[H203] Unit test assertions tend to give better messages for more
specific assertions. As a result, assertIsNone(...) is preferred
over assertEqual(None, ...) and assertIs(None, ...)
[1] http://docs.openstack.org/developer/hacking/#unit-tests-and-assertraises
Change-Id: I14f54cbb7dce27e70fed4ef1cb85748474f54fc5
Tony Breeds