OCI server permission errors in registry operator kubernetes deployments

[michael-valdron]

Which area this feature is related to?

/kind bug

Which area this bug is related to?

/area registry

What versions of software are you using?

Go project

Operating System and version: N/A

Go Pkg Version: 1.18

Bug Summary

Describe the bug:

Deploying the devfile registry using the registry operator on a minikube environment causes a number of permission errors to occur on the OCI server when pushing stacks/samples. OpenShift environments are not effected by this issue.

To Reproduce:

Use the registry operator to deploy a devfile registry onto a minikube environment (tested using a headless deployment):

cat <<EOF | kubectl apply -f -
apiVersion: registry.devfile.io/v1alpha1
kind: DevfileRegistry
metadata:
  name: devfile-registry
spec:
  devfileIndex:
    image: quay.io/devfile/devfile-index:next
  headless: true
EOF

Expected behavior

Any logs, error output, screenshots etc? Provide the devfile that sees this bug, if applicable

2023/02/13 19:40:17 Pushed to localhost:5000/devfile-catalog/python-django:2.1.0 with digest sha256:7f01aec41910fe1cd15547ff2af01bdbea126d101c511287cd90ca7e6b4b3103
2023/02/13 19:40:17 failed to generate /www/data/sample_index.json: failed to write /www/data/sample_index.json: open /www/data/sample_index.json: permission denied

Additional context

Any workaround?

Possible workaround might be to remove the security context blocks source from deployment.go and rebuild the registry operator for the minikube environment. This would involve the registry admin to alter the source making it not a feasible workaround in most cases. These security contexts are needed for compatibility with an OpenShift environment.

Suggestion on how to fix the bug

Changes to the security context setups are needed to ensure compatibility with both OpenShift and Kubernetes.

Target Date: 04-04-2023

[michael-valdron]

Using config.ControllerCfg.IsOpenShift to only set security context specs if cluster is OpenShift.

[michael-valdron]

The fqdn field is no longer being populated with cr.Status.URL value, currently investigating.

[michael-valdron]

The fqdn field is no longer being populated with cr.Status.URL value, currently investigating.

Confirmed that this problem exists still before the changes in this issue have been applied, moving onto the review process for these changes and reopening #1028 to investigate separately.

[michael-valdron]

Seems that part of the solution for #1092 also fixes this issue: #1092 (comment). Going to use this solution instead to cover both issues and provide compatible security context setups to Kubernetes environments.

[michael-valdron]

Now ready for review: devfile/registry-operator#40