Suggestion: Improve MinIO Setup and Configuration

[carlmes]

A suggestion for some minor improvements to the MinIO configuration in the components/apps/minio location:

• Randomize the MinIO admin user name and password instead of minio123, since the AWS demo clusters are internet facing.
• Add an OpenShift Application Menu using a ConsoleLink object, so that uses can easily access the admin UI

There's a great example in the Fraud Detection Demo, specifically this script that we could copy some logic / content from:

oc apply -n <your-project-name/> -f https://github.com/rh-aiservices-bu/fraud-detection/raw/main/setup/setup-s3.yaml

Here's the job that generates a randomized password.

For the application menu, an example ConsoleLink:

apiVersion: console.openshift.io/v1
kind: ConsoleLink
metadata:
  name: link-minio
spec:
  href: "https://minio-console-fraud-detection.apps.cluster-zk244.zk244.sandbox1964.opentlc.com/"
  location: ApplicationMenu
  text: MinIO Console
  applicationMenu:
    section: AI Applications
    imageURL: https://min.io/resources/favs/favicon-32x32.png

That shows as:

[strangiato]

Just a few thoughts...

Random passwords are always good, especially if it isn't a huge uplift in maintenance.

Building out minio as a helm chart that we can reuse may be something to consider. It helps make maintaining these kinds of more complex options a bit easier. I haven't gone down that route yet personally since I try to avoid minio in anything but demo environments. It wouldn't hurt to have a more codified / opinionated way to deploy minio though in an OCP environment.

Managing cluster URLs that we need to populate into the console link object is a bit of a pain. We have a process in composer-ai that we can pull from if we need to that sets it up as an env var though. It is a bit hacky but it gets the job done.

I'm generally not a fan of treating minio as a cluster/multi-tenant resource. Personally I think it should be something that the team that is using it should be responsible for managing their own instance. I know the team that put together the fraud detection demo tends to try to use a central minio instance though. In the real world I feel like orgs that do actually use minio use it because s3 isn't a solved problem at the cluster level and it needs to be solved at the use case level. A lot of this is going to be dictated by our customer though and what they want to do.

If we do move towards model car as we discussed in slack, minio goes away for model serving at least which would make me happy!