Bug 1689762 - The storageClassName is "" in pvc when storageclass is not in CLO
Summary: The storageClassName is "" in pvc when storageclass is not in CLO
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.1.0
Assignee: ewolinet
QA Contact: Anping Li
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-18 03:17 UTC by Anping Li
Modified: 2019-06-04 10:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:46:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:46:06 UTC

Description Anping Li 2019-03-18 03:17:31 UTC
Description of problem:
If the storage size is specified and storageClassName is not set. the clusterlogging operator generate the pvc resource file using storageClassName: "".   that cause the pvc couldn't be bind as there isn't storageClassName "".

If we want to use default storage class, Remove the storageclass from the PVC resource file.  if we want to use storageClassName as mandatory. We need to update the document.



Version-Release number of selected component (if applicable):
clusterlogging operator v4.x

How reproducible:
Always

Steps to Reproduce:
1. provide logging CLO Resource without storageclass options.
apiVersion: "logging.openshift.io/v1alpha1"
kind: "ClusterLogging"
metadata:
  name: "nostorageclassname"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 200m
          memory: 2Gi
      storage:
        size: "20G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
  curation:
    type: "curator"
    curator:
      schedule: "*/10 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

2. Check the pvc status
 oc get pvc 
 oc edit pvc

Actual results:
The pvc could't be binding as the storageclass name is "".

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  creationTimestamp: 2019-03-18T02:37:36Z
  finalizers:
  - kubernetes.io/pvc-protection
  name: elasticsearch-elasticsearch-clientdatamaster-0-3
  namespace: openshift-logging
  resourceVersion: "27499"
  selfLink: /api/v1/namespaces/openshift-logging/persistentvolumeclaims/elasticsearch-elasticsearch-clientdatamaster-0-3
  uid: ca5f2068-4926-11e9-b285-0a3cd40e33ca
spec:
  accessModes:
  - ReadWriteOnce
  dataSource: null
  resources:
    requests:
      storage: 20G
  storageClassName: ""
status:
  phase: Pending


Expected results:
A) Remove the storageclass option from pvc.  so the pvc can use the default storageclass.
B) indicate storageclass is a mandatory variable

Comment 1 ewolinet 2019-03-18 16:43:14 UTC
If you do not have a storageClassName there it should be interpreted that you want to use an emptydir volume with that size.
We aren't correctly evaluating that it is empty. We need to be able to evaluate "" differently from not provided per the k8s docs [1].


[1] https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1

Comment 3 Anping Li 2019-03-26 09:08:40 UTC
Verified and pass on quay.io/openshift/origin-cluster-logging-operator:latest

Comment 5 errata-xmlrpc 2019-06-04 10:46:01 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/RHBA-2019:0758


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