Bug 1415297

Updated info:

If I let the ansible installer fail. And, I clean up openshift-infra and logging projects (basically do the "cleanup" steps outlined in the docs); then do the following...create the yaml file:

```
kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
  name: aws-ebs-slow
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  zone: us-west-1b
  iopsPerGB: "100" 
  encrypted: "false"
```

Create the storageclass with `oc create -f storage-class-default.yaml` ...I restart the installer at this point then it goes as expected.

QE has test Metrics deploy with cloud-provider enabled AWS instance in version 3.3.1 and later, and could bound dynamic pv to cassandra pod.

I am trying to figure out what the issue is here exactly.

This does not sounds like its a metrics or logging issues, but an installation problem.

@sdodson: why did you move this to metrics?

From https://bugzilla.redhat.com/show_bug.cgi?id=1415297#c1 it sounds like the problem is that the StorageClass was not setup properly. Once its installed correctly, then the metrics and logging installation goes without issue.

Is this suppose to be done automatically in the ansible install? or is this suppose to be a separate step that a user would be required to perform?

I don't know if this is suppose to be an installation issue, a problem where our docs don't outline that you have to do this set, or just that the user forgot a step.

I am reassigning this to the installer component. The metrics component is not responsible for setting up things like StorageClass

Additional thoughts.

@mwringe I agree this is an installation issue.

@all

1) I believe that the installer should create a storageclass if we are setting dynamic storage in the ansible host file

IF NOT

2) The ansible installer should provide a mechanism for setting up storageclasses

IF NOT

3) The VERY least there it should be stated on the docs that you need a storageclass

HOWEVER, that's a "chicken/egg" problem because how can I set up storage class if OCP isn't installed?

Need to add configuration validation to ensure that if *_storage_type=dynamic then we also have a cloud provider defined.

Yes both were set.

comment 8 has details, implement in openshift_sanitize_inventory role

Per https://github.com/openshift/openshift-ansible/pull/5566 we should now fail the install if we are setting any storage kind == 'dynamic' without enabling dynamic provisioning.

1.  The message [1] [2] will be reported if we setpenshift_hosted_logging_storage_kind=dynamic or openshift_hosted_metrics_storage_kind=dynamic

[1]
ok: [openshift-181.lab.eng.nay.redhat.com] => {
    "msg": [
        "[DEPRECATION WARNING]: openshift_hosted_logging_storage_kind is a deprecated variable and will be no longer be used in the next minor release. Please update your inventory accordingly.", 
        "[DEPRECATION WARNING]: openshift_hosted_metrics_storage_kind is a deprecated variable and will be no longer be used in the next minor release. Please update your inventory accordingly."
    ]
}


[2]TASK [openshift_sanitize_inventory : Ensure that dynamic provisioning is set if using dynamic storage] ************************************************************************************************************
task path: /usr/share/ansible/openshift-ansible/roles/openshift_sanitize_inventory/tasks/unsupported.yml:24
fatal: [openshift-182.lab.eng.nay.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "Using a storage kind of 'dynamic' without enabling dynamic provisioning nor\nsetting a cloud provider will cause generated PVCs to not be able to bind as\nintended. Either update to not use a dynamic storage or set\nopenshift_master_dynamic_provisioning_enabled to True and set an\nopenshift_cloudprovider_kind. You can disable this check with\n'dynamic_volumes_check=False'."}
fatal: [openshift-181.lab.eng.nay.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "Using a storage kind of 'dynamic' without enabling dynamic provisioning nor\nsetting a cloud provider will cause generated PVCs to not be able to bind as\nintended. Either update to not use a dynamic storage or set\nopenshift_master_dynamic_provisioning_enabled to True and set an\nopenshift_cloudprovider_kind. You can disable this check with\n'dynamic_volumes_check=False'."}
fatal: [openshift-217.lab.eng.nay.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "Using a storage kind of 'dynamic' without enabling dynamic provisioning nor\nsetting a cloud provider will cause generated PVCs to not be able to bind as\nintended. Either update to not use a dynamic storage or set\nopenshift_master_dynamic_provisioning_enabled to True and set an\nopenshift_cloudprovider_kind. You can disable this check with\n'dynamic_volumes_check=False'."}
fatal: [openshift-210.lab.eng.nay.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "Using a storage kind of 'dynamic' without enabling dynamic provisioning nor\nsetting a cloud provider will cause generated PVCs to not be able to bind as\nintended. Either update to not use a dynamic storage or set\nopenshift_master_dynamic_provisioning_enabled to True and set an\nopenshift_cloudprovider_kind. You can disable this check with\n'dynamic_volumes_check=False'."}
fatal: [openshift-226.lab.eng.nay.redhat.com]: FAILED! => {"changed": false, "failed": true, "msg": "Using a storage kind of 'dynamic' without enabling dynamic provisioning nor\nsetting a cloud provider will cause generated PVCs to not be able to bind as\nintended. Either update to not use a dynamic storage or set\nopenshift_master_dynamic_provisioning_enabled to True and set an\nopenshift_cloudprovider_kind. You can disable this check with\n'dynamic_volumes_check=False'."}

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/RHSA-2017:3188