Bug 1233201
| Summary: | OSC plugin should have one way to scale a deployment | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dougal Matthews <dmatthew> |
| Component: | python-rdomanager-oscplugin | Assignee: | Dougal Matthews <dmatthew> |
| Status: | CLOSED ERRATA | QA Contact: | Ola Pavlenko <opavlenk> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | Director | CC: | calfonso, dnavale, jprovazn, jslagle, lregebro, mburns, rhel-osp-director-maint, ukalifon |
| Target Milestone: | ga | Keywords: | Triaged |
| Target Release: | Director | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-rdomanager-oscplugin-0.0.8-6.el7ost | Doc Type: | Deprecated Functionality |
| Doc Text: |
With this release, a duplicated command for scaling a deployment has been removed in favor of scaling a deployment directly using Tuskar or using the deploy command.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-05 13:54:42 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: | |||
+1 for removing option 1 (as there is now working more general way) Change to remove option 1: https://review.gerrithub.io/#/c/237070/ Verified in python-rdomanager-oscplugin-0.0.8-13.el7ost.noarch 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. https://access.redhat.com/errata/RHEA-2015:1549 |
Description of problem: We currently have three different methods of scaling a Tuskar deployment. Option 1: This was added to the unified CLI before the deploy command was merged, so at the time there was no other way to do this. The command is long and confusing as it strictly follows the python-oscplugin guidelines. openstack overcloud scale stack overcloud overcloud -r Compute-1 -n 2 Option 2: This method updates the plan and then deploys the plan. openstack management plan set $PLAN_UUID -S Compute-1=2 openstack overcloud deploy --plan-uuid $PLAN_UUID Option 3: This method adds the Heat parameter to the Tuskar plan before sending it to Heat but doesn't actually send these parameters to the Tuskar API. So the changes are not saved and are not visible in the UI. This argument was added for when we deploy the TripleO Heat Templates, which can only be customised by passing parameters like this. Really these arguments don't make sense when deploying a plan, as it should have been planned before deploying. openstack overcloud deploy --plan-uuid $PLAN_UUID --compute-scale 2 Expected results: There should be one-- and preferably only one --obvious way to do it. I would suggest removing option 1. Documenting option 2 and possibly disallowing the arguments to deploy when deploying a plan. Thus, only making option 3 valid when the flag --use-tripleo-heat-templates is passed and Tuskar isn't then used. This applies to all the other flags on the deploy command which are currently: --control-scale CONTROL_SCALE --compute-scale COMPUTE_SCALE --ceph-storage-scale CEPH_STORAGE_SCALE --block-storage-scale BLOCK_STORAGE_SCALE --swift-storage-scale SWIFT_STORAGE_SCALE --control-flavor CONTROL_FLAVOR Nova flavor to use for control nodes. --compute-flavor COMPUTE_FLAVOR Nova flavor to use for compute nodes. --ceph-storage-flavor CEPH_STORAGE_FLAVOR Nova flavor to use for ceph storage nodes. --block-storage-flavor BLOCK_STORAGE_FLAVOR Nova flavor to use for cinder storage nodes. --swift-storage-flavor SWIFT_STORAGE_FLAVOR Nova flavor to use for swift storage nodes. --use-tripleo-heat-templates --neutron-flat-networks NEUTRON_FLAT_NETWORKS --neutron-physical-bridge NEUTRON_PHYSICAL_BRIDGE --neutron-bridge-mappings NEUTRON_BRIDGE_MAPPINGS --neutron-public-interface NEUTRON_PUBLIC_INTERFACE --hypervisor-neutron-public-interface HYPERVISOR_NEUTRON_PUBLIC_INTERFACE --neutron-network-type NEUTRON_NETWORK_TYPE --neutron-tunnel-types NEUTRON_TUNNEL_TYPES --libvirt-type LIBVIRT_TYPE --ntp-server NTP_SERVER --cinder-lvm --tripleo-root TRIPLEO_ROOT --nodes-json NODES_JSON --no-proxy NO_PROXY