Ensure HTTP endpoints are accessible outside the cluster

[everettraven]

Following #113 we should ensure that the necessary HTTP endpoints for getting catalog contents are accessible from outside the cluster. A user shouldn't have to perform any magic to curl the endpoint containing a Catalog's contents.

In essence, a user should be able to fetch the catalog content via the command line by:

• Running kubectl get catalog {catalogName} -o yaml to fetch Catalog details
• Running curl {Catalog.Status.contentURL} to fetch all the contents of the Catalog

[anik120]

This to me reads more as "write a kubectl plugin that connects to the service exposed by the controller to fetch and explore catalog content on cluster (get packages, get bundle should be sufficient to begin with). Unless there's a different way of solving this, we should probably modify the issue to be more explicit about what needs to be done.

[everettraven]

I was more so trying to convey that a user should be able to do a kubectl get catalog operatorhubio -o yaml and take the URL from the Catalog.Status and put it into a curl command like curl {catalog.status.url} and receive the catalog contents. No kubectl plugin required at this stage IMO

[anik120]

I see, we're talking Ingress here then. That's fine.

[joelanford]

What's proposed is likely not possible. The catalog's status.contentURL field will very likely be an https URL whose host:port is resolvable/routable only inside the cluster.

My assumption would be that we would document standard ways of exposing a Service's endpoints outside the cluster and then the curl command would use whatever endpoint was exposed. Options would include:

• Using ingress. In this case, the URL that is curled would be resolvable by a DNS resolver outside the cluster, and then the ingress would reverse proxy to the underlying service.
• Using a NodePort service. In this case, the URL that is curled would be to a cluster host running kube-proxy. The port would be a high-numbered port, likely not the same as the service port.

[everettraven]

What's proposed is likely not possible. The catalog's status.contentURL field will very likely be an https URL whose host:port is resolvable/routable only inside the cluster.
My assumption would be that we would document standard ways of exposing a Service's endpoints outside the cluster and then the curl command would use whatever endpoint was exposed

That's a fair assumption. I didn't think too far into if this approach is possible, but if the way to go about this is to document a standard way to access the service's endpoints using something like curl that is fine as well

[everettraven]

/assign @rashmigottipati