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

[rashmigottipati]

Can close this as it's completed via #209

[joelanford]

Thanks for the callout @rashmigottipati! Feel free to close directly when you see stuff like this.

And also (you're probably aware, but I know its easy to forget) there's some GH syntax you can put in PR descriptions/comments that will get GH to do this for you automatically: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

[rashmigottipati]

@joelanford yeah, my bad, I forgot linking the GH issue in the PR description when I'd created it but added it after the PR was merged, so I don't think it was able to pick it up. 😅 And I was unable to close it directly as I don't see the "Close" button, I think it's because I am not a maintainer on this project.

[joelanford]

I think it's because I am not a maintainer on this project.

Ah! Well we should fix that!

EDIT: Done!

[rashmigottipati]

@joelanford thank you!