Bug 1235472
Summary: | SoftwareDeployment resource attributes are null | ||
---|---|---|---|
Product: | [Community] RDO | Reporter: | Graeme Gillies <ggillies> |
Component: | openstack-heat | Assignee: | Steve Baker <sbaker> |
Status: | CLOSED EOL | QA Contact: | Amit Ugol <augol> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | Kilo | CC: | jpeeler, shardy, srevivo |
Target Milestone: | --- | ||
Target Release: | Kilo | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-19 15:50:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Graeme Gillies
2015-06-24 22:56:53 UTC
Ok, I've reproduced this on upstream TripleO, and I can see that the deploy_* attributes are not accessible via the resource-show output. The information *is* however accessible via the deployment-show interface (IMO this is actually a preferable interface, because you only need the deployment ID and not the stack ID combined with the resource name): [shardy@localhost tripleo]$ heat resource-list -n5 overcloud | grep ControllerServicesBase | ControllerServicesBaseDeployment_Step2 | 5425c155-d688-4259-92f5-e9d6e8c542a8 | OS::Heat::StructuredDeployments | CREATE_COMPLETE | 2015-06-22T11:50:07Z | ControllerNodesPostDeployment | | 0 | ec9fdb45-6c62-4ff6-9923-2dda51cb75f1 | OS::Heat::StructuredDeployment | CREATE_COMPLETE | 2015-06-22T11:50:51Z | ControllerServicesBaseDeployment_Step2 | [shardy@localhost tripleo]$ heat resource-show 5425c155-d688-4259-92f5-e9d6e8c542a8 0 | grep deploy_stdout | | "deploy_stdout": null, | [shardy@localhost tripleo]$ heat deployment-show ec9fdb45-6c62-4ff6-9923-2dda51cb75f1 | grep deploy_stdout "deploy_stdout": "\u001b[mNotice: Compiled catalog for overcloud-controller-0.localdomain in environment production in 3.41 seconds\u001b[0m\n\u001b[mNotice: /Stage[main]/Staging/File[/opt/staging]/ensure: created\u001b[0m\n\u001b[mNotice: /Stage[main]/Rabbitmq/Rabbitmq_plugin[rabbitmq_management]/ensure: created\u001b[0m\n\u001b[mNotice <snip> I'll look into why the attributes are being output as null by heat, but for now I'd suggest using deployment-show as a workaround using the physical_resource_id of the OS::Heat::StructuredDeployment resource. Note that for configs with group os-apply-config (e.g many of those applying hieradata rather than the manifests), the deploy_* values will be null via either interface until the fix for bz #1231970 lands. Reassigning to heat as I'm pretty sure it's not an os-collect-config issue (pending confirmation from Graeme that deployment-show works for him) I can confirm that heat deployment-output-show is giving me the information, so just heat resource-show is the only one not working I generally run the following to view the deployment log: heat deployment-output-show --format raw <deployment-uuid> deploy_stdout heat deployment-output-show --format raw <deployment-uuid> deploy_stderr Once I've reproduced the lack of attributes in resource-show I'll raise a bug upstream. This is also a problem if you want to use the OS::Heat::SoftwareDeployments resource to gather data from a cluster-wide config via the deploy_stdouts attribute, which stays null even when stdout has been returned to the deployment. Relatedly, the SoftwareDeployments (plural) resource doesn't support path based attributes, so it's impossible to access any output other than stdouts/stderrs/status_codes (even though they are all null), that probably warrants another bug tho. Actually disregard the deploy_stdouts part of comment#5 - on further investigation it is just the same issue as reported, and the get_attr part is working OK, it's just not visible via resource-show which makes the template debugging somewhat harder. This bug is against a Version which has reached End of Life. If it's still present in supported release (http://releases.openstack.org), please update Version and reopen. |