How to handle additional domains or ports in the case of minio object storage

[costrouc]

Description

Minio requires a domain (or port ... easiest option) for object storage. The reason for using minio is to reduce our dependence on cloud provider storage. However the major downside is that now we have to expose the object storage. This is needed for viewing/downloading conda-store resources such as logs, conda-pack, docker images, etc. Object storage (s3) protocol does not support path prefixes and thus must use an entire domain. We would reuse the domain being using for the qhub cluster and use a different port. The downsite of using a seperate domain is that yet another certificate is required which makes the deployment more complicated for enterprise deployments.

Value/benefit

• needed for viewing/downloading conda-store resources such as logs, conda-pack, docker images, etc.

This feature is critical to long term adoption of Conda-Store within QHub. Viewing logs of conda builds is an important feature. However prior to Conda-Store being added to QHub this feature was not available.

If the request is related to a specific version of Kubernetes or Cloud provider

N/A

Discussion

I see two directions to solve this and would like team input:

• deployment the object storage at a seperate port within the same domain (traditionally s3 used 80/443 but we can use another)
• use a seperate domain and add to the docs that another certificate is required ... while it is not necissarily required in this case many extensions we work on will only provide this as an option so we likely need to plan for this anyways

[costrouc]

Blocker for #798

[viniciusdc]

Hi @costrouc, based on my latest research it seems that there is no standard for storage ports, basically, the most commonly used for internet data communication are 80, 443, and 8443 (where 8008 and 8080 are officially alternative ports for HTTP as well, as reference).

I would then suggest using 443xx with xx being any 2‑digit number, e.g. 44301, those ports 44300–44399 are normally not used, according to the Wikipedia list of TCP/UDP port numbers. Or I also suggest using 5443 as per this example at Docker docs.

It is, 8080 for HTTP and 8443 for HTTPS

[viniciusdc]

Regarding the implementation of those in the minIO config, I found the docs relating to its helm chart, so we can work based on this section of the chart:

## Expose the MinIO service to be accessed from outside the cluster (LoadBalancer service).
## or access it from within the cluster (ClusterIP service). Set the service type and the port to serve it.
## ref: http://kubernetes.io/docs/user-guide/services/
##
service:
  type: ClusterIP
  clusterIP: ~
  ## Make sure to match it to minioAPIPort
  port: "9000"
  nodePort: 32000

[trallard]

Was this fully resolved by #988 @costrouc @HarshCasper if so can we close this issue?

[viniciusdc]

Closed by #988