Bug 1233201 - OSC plugin should have one way to scale a deployment
Summary: OSC plugin should have one way to scale a deployment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin
Version: Director
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ga
: Director
Assignee: Dougal Matthews
QA Contact: Ola Pavlenko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-18 12:23 UTC by Dougal Matthews
Modified: 2015-08-05 13:54 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-08-05 13:54:42 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System 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 17:49:10 UTC

Description Dougal Matthews 2015-06-18 12:23:59 UTC
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 10:39:52 UTC
+1 for removing option 1 (as there is now working more general way)

Comment 3 Dougal Matthews 2015-06-19 11:05:56 UTC
Change to remove option 1: https://review.gerrithub.io/#/c/237070/

Comment 6 Udi 2015-06-29 17:34:14 UTC
Verified in python-rdomanager-oscplugin-0.0.8-13.el7ost.noarch

Comment 8 errata-xmlrpc 2015-08-05 13:54:42 UTC
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.