Bug 1253628 - external ceph patches break tuskar based deploys
external ceph patches break tuskar based deploys
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tuskar (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
high Severity unspecified
: y1
: 7.0 (Kilo)
Assigned To: Marios Andreou
Luigi Toscano
: Reopened, ZStream
: 1258631 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-08-14 06:22 EDT by Marios Andreou
Modified: 2016-01-24 21:31 EST (History)
12 users (show)

See Also:
Fixed In Version: openstack-tuskar-0.4.18-4.el7ost
Doc Type: Bug Fix
Doc Text:
Support for using a pre-existing external Ceph Storage cluster with Overcloud deployments caused all deployments using a Tuskar plan to fail. This included deployments through the web UI and CLI when --plan is used instead of --templates. This was irrespective of whether any Ceph Storage nodes were deployed (external or otherwise). Failed deployments resulted in the following error: ERROR: openstack ERROR: Property error : CephClusterConfig: ceph_storage_count The Parameter (Ceph-Storage-1::CephStorageCount) was not provided. This fix modifies Tuskar so that it can work with nested references to the top level Heat templates scaling parameters (like CephStorageCount in this case). Deployments using Tuskar now function without encountering the CephStorageCount error.
Story Points: ---
Clone Of:
Last Closed: 2015-10-08 08:16:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 213179 None None None Never

  None (edit)
Description Marios Andreou 2015-08-14 06:22:21 EDT
Description of problem:
After https://review.openstack.org/#/c/197734/ lands into tht tuskar based deploys will fail like

ERROR: openstack ERROR: Property error : CephClusterConfig: ceph_storage_count The Parameter (Ceph-Storage-1::CephStorageCount) was not provided.

This is because the scaling param CephStorageCount which is used to signal 'enable_ceph' in that patch is namespaced as Ceph-Storage-1::CephStorageCount

I think this may be due to special handling for the count params, am still investigating.

To be clear, once that lands, all --tuskar deploys will fail.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use tripleo heat templates that include https://review.openstack.org/#/c/197734
2. openstack overcloud deploy plan --overcloud --compute-scale 1 --control-scale 1
3. ERROR: openstack ERROR: Property error : CephClusterConfig: ceph_storage_count The Parameter (Ceph-Storage-1::CephStorageCount) was not provided.

Actual results:
ERROR: openstack ERROR: Property error : CephClusterConfig: ceph_storage_count The Parameter (Ceph-Storage-1::CephStorageCount) was not provided.

Expected results:
No explosions.

Additional info:
Comment 3 Marios Andreou 2015-08-14 07:55:09 EDT
So it is indeed a clash with the special handling we do for the count params. Basically, what is CephStorageCount, becomes CephStorage-1::count and the original param is no more. The external ceph patch tries to reference this like  get_param: Ceph-Storage-1::CephStorageCount (tuskar also namespaces it).

Long-story short, using any other param name here would work fine. Am trying 'LeParam' for example:

in overcloud-without-mergepy.yaml

1181   CephClusterConfig:
1182     type: OS::TripleO::CephClusterConfig::SoftwareConfig
1183     properties:
1184       ceph_storage_count: {get_param: LeParam} # instead of CephStorageCount
1185       ceph_fsid: {get_param: CephClusterFSID}

 624   CephStorageCount:
 625     type: number
 626     default: 0
 627   LeParam:
 628     type: number
 629     default: 0

Using this the deploy with tuskar is OK. Am trying to come up with a happy compromise in the templates.
Comment 4 Marios Andreou 2015-08-14 10:46:27 EDT
propsed fixup @  https://review.openstack.org/#/c/213179/ (still needs more testing but fyi)
Comment 5 chris alfonso 2015-08-18 14:48:38 EDT
With us removing tuskar, we can probably not fix this.
Comment 6 Mike Burns 2015-08-31 22:00:54 EDT
*** Bug 1258631 has been marked as a duplicate of this bug. ***
Comment 7 Mike Burns 2015-08-31 22:04:50 EDT
It turns out that this breaks all deployments with tuskar which currently includes the UI.  Unless we plan on the UI not being an option even for POC, we need to at least make it work.  

One possible hackish solution would be to hard code the UI to pass the right value as 0 in all cases and document that you can't do any ceph deployment with the UI.
Comment 8 chris alfonso 2015-09-01 12:08:43 EDT
Ana, would you please sync up with marios on perhaps setting this in the UI, he can give you some guidance on where it could possibly be done.
Comment 9 Ana Krivokapic 2015-09-02 08:20:25 EDT
We decided to go with the tuskar fix rather than disable all Ceph deployments in the GUI.
Comment 11 nlevinki 2015-09-16 05:29:14 EDT
Since Tusker deprecated I think we should close this ticket ?
Comment 12 Marios Andreou 2015-09-16 05:31:26 EDT
I think the fix was still needed because of the UI like comment 7
Comment 13 Luigi Toscano 2015-10-01 13:07:36 EDT
Deployed two configurations from the web UI:
a) 1 controller + 1 compute + 1 Ceph storage
b) 1 controller + 1 compute

Each type of node had a specific flavor, which was associated (if defined) to the matching deployment role. The remaining roles were assigned to baremetal flavor.

Verified on a RHEL7.1 environment, relevant packages:

Comment 15 errata-xmlrpc 2015-10-08 08:16:47 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.