[openstack-dev] [heat][infra] heat-templates dsvm gate

Manickam, Kanagaraj kanagaraj.manickam at hpe.com
Thu Dec 3 08:58:23 UTC 2015


From: Pavlo Shchelokovskyy [mailto:pshchelokovskyy at mirantis.com]
Sent: Thursday, December 03, 2015 1:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat][infra] heat-templates dsvm gate

Hi all,

I would like to discuss how to fix and improve $subject, which targets to validate the templates present in the repo. Current state is the following:

the gate does merely validate the "parseability" of YAML/JSON templates and very basic check on template structure. Any other real checks as would be actually performed in real deployment are not executed because:
- only Heat and Keystone are installed on this gate;
- for resources for any other service service-based resource exposure kicks in early, producing "Service {name} does not have required endpoint in service catalog for the resource type {resource}" errors,


[Manickam, Kanagaraj]  ‘Service not available’ error could be handled once the ignore_erros options for validate template blueprint [3] is completed. Below command line option would help for it

heat template-validate –ignore-errors 990002 –f  <template file>

This helps to ignore the given errors and continue the validation of templates.



- which are ignored by the script running the validation (to not block the gate, bug 1492942)


[Manickam, Kanagaraj]  once blueprint [3] is implemented, this tool could be updated as mentioned above, which gives more validation control over existing logic.


Thus for example the check that properties of the resources are confirming to the schema of a particular resource is not performed, and we might be having faulty templates (e.g. with typos) in the repo. I hoped to fix this with mapping all resources to OS::Heat::None, but it turned out this would not be really helpful, as the None-resource has any property and attribute.

[Manickam, Kanagaraj] For unsupported resource types (not part of global-requirments.txt), we are currently masking with None resource.  for other resource types which does not have keystone endpoint in the gate, I think we ignore it in the tool. [4]

So I propose that heat-templates repo can configure its environment itself by using the "post_test_hook" facilities provided and supported by gate setup. We need that to better control the environment the tests are being run in. In particular, I'd like to add some fake service endpoints to Keystone, so service-based exposure is out of the validation way.

Thereby I ask Heat and Infra team to take a look at these two patches:
- [0] in heat-templates and
- [1] in project-config (depends on [0]).

Though these are simply moving couple of bash lines from project-config to heat-templates, we want to be sure they work so that we do not break the gate. Unfortunately I can not prove my further patches [2] are working as it seems Depend-On does not work for referencing project-config changes.

[0] https://review.openstack.org/#/c/252515/
[1] https://review.openstack.org/#/c/252523/
[2] https://review.openstack.org/#/q/status:open+project:openstack/heat-templates+branch:master+topic:bug/1492942,n,z
[3]  https://blueprints.launchpad.net/heat/+spec/heat-template-validate-improvements
[4] https://github.com/openstack/heat-templates/blob/master/tools/validate-templates#L41

Best regards,
--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com<http://www.mirantis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151203/c568432c/attachment.html>


More information about the OpenStack-dev mailing list