Description of problem:

  When upgrading from 3.4 to 3.5 logging, the settings for the number of primary
  shards for new indices, and the number of replicas of those primary shards for
  new indices is not preserved.

  The 3.4 method of deployment as a deployer pod via a template, and with 3.5 the
  deployment is via ansible.

  The defaults for the ansible playbook is:

    number_of_shards = 1
    number_of_replicas = 0

  This can lead to data loss as new indices are created after an upgrade. If a PV
  is lost, or corrupted, or node becomes unavailable that hosts that PV, then
  access to data in those indices is lost entirely.

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

  3.5.*

How reproducible:

  All upgrades from 3.4 to 3.5 (apparently).

  This bug needs to be verified with the exact conditions under which it occurs.

Steps to Reproduce:

  1. Take a 3.4 cluster with the logging-elasticsearch configmap having a value of
     1 for number_of_replicas
  2. Upgrade to 3.5
  3. Observe the logging-elasticsearch configmap to see what the value is for
     number_of_replicas

Actual results:

  The elasticsearch configmap is changed to have a default of 0 for
  number_of_replicas and 1 for number_of_shards.

Expected results:

  The previous elasticsearch configmap is maintained.