controller must react to bucket request updates.

Should we have one Kustomization file to deploy all of COSI or should each repo have Kustomization file it's component?

See container-object-storage-interface/cosi-controller-manager#9 (comment) for details.

Implement BucketRequest Add

Bug Report

What happened:

For the BAR and BR controller - after updating the finalizers, the update request for the status would intermittently error.

What you expected to happen:

The expected behavior was that both the finalizer and status would be updated without any errors.

How to reproduce this bug (as minimally and precisely as possible):

Run the controller, and create a BR. The bucket will be created, but the bucketrequest will not be updated with the status. This means future requests will receive an incomplete BR, and they will consequently error.

Anything else relevant for this bug report?:

Environment:

• Kubernetes version (use kubectl version), please list client and server:
• Controller version (provide the release tag or commit hash):
• Provisoner name and version (provide the release tag or commit hash):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

• In bucket creation, if !errors.IsAlreadyExists{}

Implement Add for BucketAccessRequests

Bug Report

What happened:
I wanted to test-drive COSI and tried to deploy it into my Kubernetes cluster using the github.com/kubernetes-sigs/container-object-storage-interface-controller kustomization. Pod was unable to start: exec /controller-manager: exec format error

My cluster is running on ARM machines, not x86.

What you expected to happen:

Get the COSI controller running.

How to reproduce this bug (as minimally and precisely as possible):

• Deploy a Kubernetes cluster on ARM
• Deploy github.com/kubernetes-sigs/container-object-storage-interface-controller

Anything else relevant for this bug report?:

• As ARM is getting more and more popular, not only on-prem but also in the cloud, please consider to provide multiarch images for at least x86_64 and arm64.
• I'd happy to help or create a PR, as I built many multiarch containers myself. But I've no idea about the Kubernetes image build and release pipelines and processes.

Environment:

• Kubernetes version (use kubectl version), please list client and server:

Client Version: v1.28.3
Server Version: v1.28.2+k3s1

• Controller version (provide the release tag or commit hash):
  commit 7e7b773
• Provisoner name and version (provide the release tag or commit hash):
  n/a
• Cloud provider or hardware configuration:
  ARM64 HW
• OS (e.g: cat /etc/os-release):

PRETTY_NAME="Ubuntu 23.04"
NAME="Ubuntu"
VERSION_ID="23.04"
VERSION="23.04 (Lunar Lobster)"
VERSION_CODENAME=lunar
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=lunar
LOGO=ubuntu-logo

• Kernel (e.g. uname -a):
  Linux tpi-node1 6.2.0-1016-raspi #18-Ubuntu SMP PREEMPT Thu Oct 12 13:26:36 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Enhancement

Add support for helm installation for COSI
Is your feature request related to a problem?/Why is this needed

Currently, COSI controller can be installed via Kubectl, but in k8s world, most apps are deployed via helm
Describe the solution you'd like in detail

Describe alternatives you've considered

Additional context

In further the apis and server may be integrate with core K8s codespace which will be available with k8s images, but currently it is not present

The current readme.md is out of date, and does not give guidelines for new persons interested in the project to easily get started and contribute.

Bug Report

What happened:
What the bucket was created by the controller, the prefixing logic was not correct.

What you expected to happen:
The logic should follow this pattern:

if br.prefix is set, then bucketname is "{{br.prefix}}-{{br.uid}}"
if not it is “br-{{br.uid}}”

How to reproduce this bug (as minimally and precisely as possible):
Try to create a bucket with no prefix

Anything else relevant for this bug report?:
N/A

Environment:
N/A

Enhancement

Is your feature request related to a problem?/Why is this needed
I want to deploy multiple instances of this controller in different namespaces

Describe the solution you'd like in detail
per namespace installation, Id like the controller to watch resources in the namespace it installed in

Describe alternatives you've considered
maybe a list of allowed namespaces

Bug Report

What happened:

Deployed all the COSI components and the sample provisioner for Minio.
Created a BucketClass and a Bucket Request.
Got the error:

E0225 15:06:33.702088       1 bucketrequest.go:85] error getting bucketclass: [&{{BucketClass objectstorage.k8s.io/v1alpha1} {my-bucketclass    98a672fd-dd77-4a04-9e06-0d3cbaf7c851 17330 1 2021-02-25 15:06:28 +0000 UTC <nil>  map[] map[] [] []  [{kubectl-create Update objectstorage.k8s.io/v1alpha1 2021-02-25 15:06:28 +0000 UTC FieldsV1 {"f:isDefaultBucketClass":{},"f:protocol":{".":{},"f:name":{},"f:s3":{".":{},"f:bucketName":{},"f:endpoint":{},"f:region":{}}},"f:provisioner":{},"f:retentionPolicy":{}}}]} false []  {false false false false}  map[] }] v1alpha1.BucketClass.Protocol: ReadString: expects " or n, but found {, error found in #10 byte of ...|rotocol":{"name":"s3|..., bigger context ...|8a672fd-dd77-4a04-9e06-0d3cbaf7c851"},"protocol":{"name":"s3","s3":{"bucketName":"my-bucket","endpoi|...
I0225 15:06:33.702173       1 bucketrequest.go:47] BucketClass specified does not exist while processing BucketRequest bucket-request.

I believe this happens because the image hosted on quay.io/containerobjectstorage/objectstorage-controller is old.

What you expected to happen:

To create a Bucket object

How to reproduce this bug (as minimally and precisely as possible):

Install all COSI components and sample provisioner:

kubectl create -k github.com/kubernetes-sigs/container-object-storage-interface-api
kubectl create -k github.com/kubernetes-sigs/container-object-storage-interface-csi-adapter
kubectl create -k github.com/kubernetes-sigs/container-object-storage-interface-controller
kubectl create -k github.com/kubernetes-sigs/container-object-storage-interface-provisioner-sidecar

Create the BucketClass and the BucketRequest:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
  name: my-bucketclass
provisioner: "sample-provisioner.objectstorage.k8s.io-dev"
protocol:
  name: "s3"
  s3:
    endpoint: "minio-service.minio-ns:9000"
    bucketName: "my-bucket"
    region: ""
---
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketRequest
metadata:
  name: bucket-request
spec:
  bucketPrefix: "cosi"
  bucketClassName: "my-bucketclass"

Environment:

Minikube

It looks the default configuration doesn't setup correctly the service account permission at the cluster scope.

After the default deployment, I got the following error :

E1011 13:13:55.028830 1 reflector.go:127] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:156: Failed to watch *v1alpha1.BucketAccessRequest: failed to list *v1alpha1.BucketAccessRequest: bucketaccessrequests.objectstorage.k8s.io is forbidden: User "system:serviceaccount:default:objectstorage-controller-sa" cannot list resource "bucketaccessrequests" in API group "objectstorage.k8s.io" at the cluster scope

We need to create finalizers for the BR and BAR to ensure that the B and BA must be deleted before the BR/BAR is removed.

This will ensure there are no dangling BRs that do not Bs and the same applies to the BAR.

From container-object-storage-interface/cosi-controller-manager#9 (comment)

Create logic in controller to process bucket request delete.

Review RBAC for controller. @rrati raised a question on update permission in container-object-storage-interface/cosi-controller-manager#9 (comment).

As per @NicolasT comments in container-object-storage-interface/cosi-controller-manager#9 (comment) we should also review list and watch events permissions.

Now that kustomize files have been added to the root of the project, we need a getting started guide which explains how to deploy and concerns around it. The deployment step itself is a single command now:

  kubectl create -k github.com/kubernetes-sigs/container-object-storage-controller

/assign tparikh

controller must process bucketaccessrequest deletes.

From container-object-storage-interface/cosi-controller-manager#9 (comment)

Generally, a kustomization should not deploy a namespace. It's up to the administrator to choose in which NS it gets deployed, and provision the NS.

Bug Report

As described in title.

Environment:

• Kubernetes version (use kubectl version), please list client and server:
• Controller version (provide the release tag or commit hash):
• Provisoner name and version (provide the release tag or commit hash):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others: