red-hat-storage / odf-operator Goto Github PK

OpenShift Data Foundation Meta Operator

License: Apache License 2.0

Dockerfile 1.56% Makefile 11.87% Go 82.97% Shell 3.60%

odf-operator's Introduction

OpenShift Data Foundation Operator

This is the primary operator for Red Hat OpenShift Data Foundation (ODF). It is a "meta" operator, meaning it serves to facilitate the other operators in ODF by providing dependencies and performing administrative tasks outside their scope.

Deploying pre-built images

Installation

The ODF operator can be installed into an OpenShift cluster using Operator Lifecycle Manager (OLM).

For quick install using pre-built container images.

make deploy-with-olm

This creates:

a custom CatalogSource
a new openshift-storage Namespace
an OperatorGroup
a Subscription to the ODF catalog in the openshift-storage namespace

You can check the status of the CSV using the following command:

oc get csv -n openshift-storage

This can take a few minutes. Once PHASE says Succeeded you can create a StorageSystem.

StorageSystem can be created from the console, using the StorageSystem creation wizard. From the CLI, a StorageSystem resource can be created using the example CR as follows,

oc create -f config/samples/ocs-storagecluster-storagesystem.yaml

Development

Build

ODF Operator

The operator image can be built via

make docker-build

ODF Operator Bundle

To create an operator bundle image with the bundle run

make bundle-build

ODF Operator Catalog

An operator catalog image can then be built using

make catalog-build

Deploying development builds

To install own development builds of ODF, first build and push the odf-operator image to your own image repository.

export REGISTRY_NAMESPACE=<quay-username>
export IMAGE_TAG=<some-tag>
make docker-build docker-push

Then build and push the operator bundle image.

export REGISTRY_NAMESPACE=<quay-username>
export IMAGE_TAG=<some-tag>
make bundle-build bundle-push

Next build and push the operator catalog image.

export REGISTRY_NAMESPACE=<quay-username>
export IMAGE_TAG=<some-tag>
make catalog-build catalog-push

Now create a ODF operator and follow the Installation

export REGISTRY_NAMESPACE=<quay-username>
export IMAGE_TAG=<some-tag>
make deploy-with-olm

Running Unit test

Unit tests can be run via

make test

To run a single test

go test -v github.com/red-hat-storage/odf-operator/controllers \
    -run TestIsVendorSystemPresent

Contribution

To contribute to the project follow the contribution guide.

odf-operator's People

Contributors

Stargazers

Watchers

odf-operator's Issues

Updating ODF operator doesn't reboot mds, mgr and mon pods

Hello,

I don't know whether to classify it as an "issue" but I'm very curious, when updating the ODF operator within my Openshift cluster, I notice that the MDS, MGR, and MON pods are not restarted automatically.

All pods except MON, MGR and MDS were automatically rebooted with the update:

csi-cephfsplugin
csi-cephfsplugin-provisioner
csi-rbdplugin
csi-rbdplugin-provisioner
noobaa-core-0
noobaa-db-pg-0
noobaa-endpoint
odf-console
rook-ceph-crashcollector
rook-ceph-osd
rook-ceph-rgw-ocs-storagecluster-cephobjectstore
rook-ceph-tools

See attached file the age difference of operator pods vs mon, mgr and mds pods

I have updated the ODF operator many times and I see this behavior, as I said before, I don't know if it is an issue but I ask you the reason why these pods don't restart.

Is it necessary to restart only these pods manually?

For some reason, at the time of the update, the operator does not touch these pods.

Thanks in advance.

Create OBC with predefined credentials

Hi,

Is it possible to create OBC and provide bucket name, credentials manually instead of generating automatically (access key, secret key)?

Thanks,
Alex

No documentation for deploying all side components

I would like to install all the ODF components via CLI. What would be the way to install all components that get installed when using the market place if I want to install them via CLI?

I would like to do this for CI purposes, Readme.md only mentione installing the ODF it self but comparing what it gets installed in the cluster via marketplace is not the same as some components are missing. Not sure about every detail of what needs to be installed, but at least looking at the pods I see the rook-ceph, console, noobaa, csi-addons, odf-console, ocs-metrics, odf-operator-controller-manager etc.

This is more of lack of documentation or guidance than an issue, so I appreciate if there is any guidance I could look at so I can create all this my self and avoid going through the web UI

Thanks!

Rename the `master` branch to `main`

This is in order to avoid problematic language in this very new repository before it gets used too widely.

Add events in the controllers

generate events in the controllers of odf-operator

Add a LICENSE

report a managed csv status in the storagesystem status

Creating an issue to discuss this further.

Questions:

should we report the status of storagecluster and flashsystemcluster both?
What fields should I report?
or should I just report CSV-name and namespace instead so one can look at the CSV status directly?

example status of CSV for second question:

status:
  conditions:
  - lastTransitionTime: "2021-07-07T10:50:09Z"
    lastUpdateTime: "2021-07-07T10:50:09Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:09Z"
    lastUpdateTime: "2021-07-07T10:50:09Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:09Z"
    lastUpdateTime: "2021-07-07T10:50:09Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:10Z"
    lastUpdateTime: "2021-07-07T10:50:10Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:10Z"
    lastUpdateTime: "2021-07-07T10:50:10Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:10Z"
    lastUpdateTime: "2021-07-07T10:50:10Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:11Z"
    lastUpdateTime: "2021-07-07T10:50:11Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:12Z"
    lastUpdateTime: "2021-07-07T10:50:12Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:12Z"
    lastUpdateTime: "2021-07-07T10:50:12Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:12Z"
    lastUpdateTime: "2021-07-07T10:50:12Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:12Z"
    lastUpdateTime: "2021-07-07T10:50:12Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:13Z"
    lastUpdateTime: "2021-07-07T10:50:13Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:13Z"
    lastUpdateTime: "2021-07-07T10:50:13Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  - lastTransitionTime: "2021-07-07T10:50:13Z"
    lastUpdateTime: "2021-07-07T10:50:13Z"
    message: Webhook rules cannot include the OLM group
    phase: Failed
    reason: InvalidWebhookDescription
  - lastTransitionTime: "2021-07-07T10:50:13Z"
    lastUpdateTime: "2021-07-07T10:50:13Z"
    message: calculated deployment install is bad
    phase: Pending
    reason: NeedsReinstall
  lastTransitionTime: "2021-07-07T10:50:13Z"
  lastUpdateTime: "2021-07-07T10:50:13Z"
  message: calculated deployment install is bad
  phase: Pending
  reason: NeedsReinstall
  requirementStatus:
  - group: apiextensions.k8s.io
    kind: CustomResourceDefinition
    message: CRD is present and Established condition is true
    name: storagesystems.odf.openshift.io
    status: Present
    uuid: 885e8c85-c656-4f33-ab33-b6b00f2c08f7
    version: v1
  - dependents:
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: namespaced rule:{"verbs":["get","list","watch","create","update","patch","delete"],"apiGroups":[""],"resources":["configmaps"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: namespaced rule:{"verbs":["get","list","watch","create","update","patch","delete"],"apiGroups":["coordination.k8s.io"],"resources":["leases"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: namespaced rule:{"verbs":["create","patch"],"apiGroups":[""],"resources":["events"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create","get","list","update","watch"],"apiGroups":["apiextensions.k8s.io"],"resources":["customresourcedefinitions"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["*"],"apiGroups":["console.openshift.io"],"resources":["consolequickstarts"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create","delete","get","list","patch","update","watch"],"apiGroups":["odf.openshift.io"],"resources":["storagesystems"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["update"],"apiGroups":["odf.openshift.io"],"resources":["storagesystems/finalizers"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["get","patch","update"],"apiGroups":["odf.openshift.io"],"resources":["storagesystems/status"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create","delete","get","list","patch","update","watch"],"apiGroups":["operators.coreos.com"],"resources":["catalogsources"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create","delete","get","list","patch","update","watch"],"apiGroups":["operators.coreos.com"],"resources":["subscriptions"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create"],"apiGroups":["authentication.k8s.io"],"resources":["tokenreviews"]}
      status: Satisfied
      version: v1
    - group: rbac.authorization.k8s.io
      kind: PolicyRule
      message: cluster rule:{"verbs":["create"],"apiGroups":["authorization.k8s.io"],"resources":["subjectaccessreviews"]}
      status: Satisfied
      version: v1
    group: ""
    kind: ServiceAccount
    message: ""
    name: odf-operator-controller-manager
    status: Present
    version: v1

Add a CONTRIBUTING guide.

I suggest to mostly copy from ocs-operator (https://github.com/red-hat-data-services/ocs-operator/blob/master/CONTRIBUTING.md) and adjust.

Configure odf console plugin web server to use recommended MIME type

Severity: Medium
Priority: Low

Current behaviour (checked on OCP/ODF 4.15):
Request URL: https:<OCP_BASE_URL>/api/plugins/odf-console/packages_shared_src_utils_index_ts-webpack_sharing_consume_default_react-webpack_sharing_cons-e82239-chunk.js

Response headers:

content-type: application/javascript
x-content-type-options: nosniff

application/javascript is considered to be a legacy JavaScript MIME type but is still a valid one for now. Proper MIME type for JavaScript according to current HTML spec is text/javascript.

Refer: openshift/console#13637 (comment) for more details.

Add a README

Tried to deploy and use odf operator in okd 4.10 & vsphere 6.7

Tried to deploy and use odf operator in okd 4.10 & vsphere 6.7. The deployment worked fine, I was able to create a storage cluster. But when I tried to use the odf storage class my pods could not write to the pvc that was created. Do I need to add a security role to the pod for it to be able to write to the pvc. Any help you can give will be appreciated.

Default PVC Mount Permissions Changed?

In the course of deploying an application to an OpenShift 4.12 cluster, I came across an issue trying to mount a PVC from ODF (operator version 4.12.4-rhodf). Upon further inspection, it looks like the PVC was mounted to the pod with 755 permissions. This was problematic as I was trying to run with UID 1000 without giving privileged access.
As a comparison, I tried the same test on an OCP 4.10 cluster (running ODF operator version 4.10.13). It looks like the PVC was then mounted with 777 permissions.
Is there a reason for this difference in behaviors? Was it something I missed in the ODF documentation? I tried with a storageclass not provided by ODF and saw no difference in behavior across the two OCP clusters.

Below is some test yaml that I used:

kind: Pod
apiVersion: v1
metadata:
  name: test-pod-cephfs-uid1000
spec:
  containers:
  - name: test-pod-cephfs-uid1000
    image: busybox:latest
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "whoami && touch /mnt/SUCCESS && echo \"Success\" && exit 0 || exit 1"
    volumeMounts:
      - name: cephfs-pvc-uid1000
        mountPath: "/mnt"
    securityContext:
      runAsUser: 1000
  restartPolicy: "Never"
  volumes:
    - name: cephfs-pvc-uid1000
      persistentVolumeClaim:
        claimName: test-claim-cephfs-uid1000
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim-cephfs-uid1000
spec:
  storageClassName: ocs-storagecluster-cephfs
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi

ODF Prerequisites

Does ODF require multiple nodes like OCS? Trying to install on a single node Microshift instance and bumping into errors.

If it does require multiple nodes, is there any workaround to allow for a single node?