Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1233201 - OSC plugin should have one way to scale a deployment
OSC plugin should have one way to scale a deployment
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin (Show other bugs)
Director
Unspecified Unspecified
high Severity high
: ga
: Director
Assigned To: Dougal Matthews
Ola Pavlenko
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-18 08:23 EDT by Dougal Matthews
Modified: 2015-08-05 09:54 EDT (History)
9 users (show)

See Also:
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 09:54:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 13:49:10 EDT

  None (edit)
Description Dougal Matthews 2015-06-18 08:23:59 EDT
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
Comment 2 Jan Provaznik 2015-06-19 06:39:52 EDT
+1 for removing option 1 (as there is now working more general way)
Comment 3 Dougal Matthews 2015-06-19 07:05:56 EDT
Change to remove option 1: https://review.gerrithub.io/#/c/237070/
Comment 6 Udi 2015-06-29 13:34:14 EDT
Verified in python-rdomanager-oscplugin-0.0.8-13.el7ost.noarch
Comment 8 errata-xmlrpc 2015-08-05 09:54:42 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.

https://access.redhat.com/errata/RHEA-2015:1549

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