Swift & rados-gw should be an optional service

[Frank Miller]

Brief Description
-----------------
As part of commissioning StarlingX, the rados-gw and is enabled by default when controller-0 is first unlocked and the swift service is enabled by default when the stx-openstack application is applied. These should be optional and only started if specifically requested/required.

This is likely the expected set of changes required to address this issue:
• We don’t want rados-gw started by default.
• We will need a rados-gw service parm to enable it.
• This will require a helm override plugin change for the rados-gw chart to detect if it is enabled or not .
When the stx-openstack app is applied, the plugin will check if the service is enabled or not and only install the rados-gw chart if the service parm is enabled.
For the usecase where a user wants to enable swift after the stx-openstack app is already running:
o User would enable the rados-gw service parm
o This will configure SM to configure and start the rados-gw SM service
o The user would need to reapply the stx-openstack app which would install the rados-gw chart

Severity
--------
Major

Steps to Reproduce
------------------
system application-apply stx-openstack

Expected Behavior
------------------
The rados-gw and swift service should not start up by default

Actual Behavior
----------------
The rados-gw and swift service are currently started up by default

Reproducibility
---------------
Reproducible

System Configuration
--------------------
All configs where stx-openstack is applied

Branch/Pull Time/Commit
-----------------------
Master branch; ISO: 20190619T140326

Last Pass
---------
n/a

Timestamp/Logs
--------------
n/a

Test Activity
-------------
[Sanity, Feature Testing,

[Ghada Khalil (gkhalil)]

Marking as release gating. With all the openstack components running on All-in-one systems, the default resources are not sufficient. This is causing these configs to be unusable.

[Ovidiu Poncea (ovidiuponcea)]

Rados GW is enabled by default at platform level as part of Ceph. Then stx-openstack only executes a chart that sets up rados-gw keystone enbpoints. The chart configures swift endpoint, it does not take resources afterwards.

This LP has two parts:
1. Make swift configurable at the platform level.
2. Apply rados-gw keystone configutation chart only if swift is enabled.

We made swift a default platform service as part of https://storyboard.openstack.org/#!/story/2004520 in commit https://opendev.org/starlingx/config/commit/754f49a3575b78517327c3a0a7556cc25de6a18b

The parts that enable swift by default will have to be reverted. Afterwards platform swift can be enabled by using "system storage-backend-modify ceph-store -s swift". Then the overrides to the chart can pick this up.

Question is: are we happy to have swift configurable through "system storage-backend-modify ceph-store -s swift"? Or do we want it through service parameter or a chart override?
I'm asking because the mechanism is already there, it needs to be enabled & retested (and probably parts of some other commits that made changes to this area of code reverted).

[Cindy Xie (xxie1)]

This ticket is more like a feature request - the reasoning about gating of consuming more system resource in AIO seems not the case anymore. mark it as none gating for stx.2.0.

[Frank Miller (sensfan22)]

Swift and the rados-gw were containerized during the stx2.0 release. As part of that feature work the services are now no longer optional but swift was an optional service in the stx1.0 release. As this change in behaviour was introduced in stx2.0, this LP is an stx2.0 issue and should be gating and fixed to align with the stx1.0 behviour. As such I am re-adding the stx2.0 tag. Effort to implement and test should be less than 2 days.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/673218

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/673219

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/673218
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=338ed34ea380f9b73522ac9f8d8fde6e5a52ea7e
Submitter: Zuul
Branch: master

commit 338ed34ea380f9b73522ac9f8d8fde6e5a52ea7e
Author: Robert Church <email address hidden>
Date: Mon Jul 29 01:14:26 2019 -0400

    Configure radosgw and ceph-rgw as optional services

    radosgw is a now an optional platform service which is provisioned via a
    system service parameter. To align with this optionality, the ceph-rgw
    chart which is used to enable the containerized swift endpoints also
    becomes optional.

    Changes include:
    - Update the stx-openstack application disabled_charts setting in the
      application metadata.yaml to include the ceph-rgw chart. This sets the
      initial chart state to disabled.
    - Optimize ceph.pp puppet manifests to provide two runtime classes: one
      for setting up the platform radosgw configuration which will set the
      haproxy configuration and the other for updating the keystone
      information in the ceph configuration based on if the ceph-rgw chart
      is enabled.
    - Update the sm.pp manifest to dynamically provision/deprovision the
      radosgw based on if it's enabled in the service parameters
    - Rename the SWIFT service parameters to RADOSGW as this is the platform
      service being enabled.
    - Restructure ceph.py/ceph.pp to generate and use hieradata such that
      _revert_cephrgw_config() and _update_cephrgw_config() can be combined
      into a single function for runtime updates.

    Change-Id: Id8d5c6b1159881d44810fc3622990456f1e54e75
    Depends-On: If284f622ceac48c4ffd74e7022fdd390971d0fd8
    Partial-Bug: #1833738
    Signed-off-by: Robert Church <email address hidden>

[Frank Miller (sensfan22)]

The main commit for this functionality has been merged. The remaining commit is to trigger a helm release clean-up after disabling a chart and re-applying the application. This remaining commit depends on an armada release upversion which will be done in stx.3.0. As such changing the tag of this LP to stx.3.0 to deliver the remaining commit.

[Al Bailey (albailey1974)]

The cleanup commit is
https://review.opendev.org/#/c/673219/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/673219
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=d42f2df220daf8ff6169ca344afacb0b1ab18eb8
Submitter: Zuul
Branch: master

commit d42f2df220daf8ff6169ca344afacb0b1ab18eb8
Author: Robert Church <email address hidden>
Date: Mon Jul 29 02:12:27 2019 -0400

    On all armada applies provide --enable-chart-cleanup

    When optional charts are enabled/disabled, manifest overrides are
    generated to include/exclude the chart from it's specific chart_group.
    By providing --enable-chart-cleanup to the armada apply, armada will
    purge chart releases that it's no longer managing.

    Prior to this, after disabling a chart and re-applying the application,
    the helm release would need to be manually removed.

    Change-Id: I34c9bcfd4eb4903e9dc74ec8228146b6cb96e74c
    Depends-On: Ic48a2e053d0de7dacfd6a07d817947e11dc8d596
    Closes-Bug: #1833738
    Signed-off-by: Robert Church <email address hidden>