search

projectcontour / contour-operator

Experimental repository to explore an operator for deploying Contour
Apache License 2.0
43 stars 34 forks source link

Add Support for Managing Required CRDs #42

Open danehans opened 4 years ago

danehans commented 4 years ago

Please describe the problem you have Add support for managing Contour CRDs (i.e. HTTPProxy) through a CustomResourceDefinition resource.

/cc @jpeach @Miciah

danehans commented 4 years ago

@jpeach @stevesloka thoughts on how to manage the CRDs? Since the CRDs are quite large and relatively constant, should we consider something like go-bindata or go-yaml to marshal the CRD yamls into Go structs?

stevesloka commented 4 years ago

What CRDs are you referring to @danehans? What do you need to manage? Sorry not following the issue described here.

Miciah commented 4 years ago

I assume we're talking about exactly the set of CRDs that are defined in https://github.com/projectcontour/contour/blob/master/examples/contour/01-crds.yaml, right?

I don't think the operator necessarily needs to manage the CRDs itself; rather, the CRDs can be packaged with the operator. In the case of OLM, the CRDs would be in the operator's CSV metadata, if I understand correctly.

jpeach commented 4 years ago

I don't think the operator necessarily needs to manage the CRDs itself; rather, the CRDs can be packaged with the operator.

If the operator upgrades contour controller versions, then I think that it ought to upgrade the CRD, since the versions are often locked or interdependent.

danehans commented 4 years ago

I assume we're talking about exactly the set of CRDs that are defined in https://github.com/projectcontour/contour/blob/master/examples/contour/01-crds.yaml, right?

@Miciah that is correct.

danehans commented 4 years ago

If the operator upgrades contour controller versions, then I think that it ought to upgrade the CRD, since the versions are often locked or interdependent.

@jpeach do you have any recommendations for managing the CRD's? Are either of the approach I suggest above viable?

jpeach commented 4 years ago

If the operator upgrades contour controller versions, then I think that it ought to upgrade the CRD, since the versions are often locked or interdependent.

@jpeach do you have any recommendations for managing the CRD's?

The best that I can come up with for now is for the operator to bundle the CRDs with go-bindata. At build time, you could pull the versioned YAML from https://projectcontour.io/quickstart/vxxx/contour.yaml (we could add a mapping for just the CRD) and package them. New Contour releases would need new operator releases.

Longer term, maybe shipping some sort of OCI Artifact, or a CRD-only helm chart would let the operator automatically pull CRDs at the right version.

However, as Contour deployments evolve, maybe the operator will need to release at the same cadence to track those changes.

On the other hand, installing the operator requires installing it's own CRD. Maybe the operator install process would also install the Contour API CRDs?

Miciah commented 4 years ago

Here's an interesting article about go-bindata and related projects; the article raises concerns around the project status of https://github.com/jteeuwen/go-bindata and compares some alternatives: https://tech.townsourced.com/post/embedding-static-files-in-go/

jpeach commented 4 years ago

go-bindata is now at https://github.com/go-bindata/go-bindata

Miciah commented 3 years ago

How are these as short-term and long-term goals?

We'd like to get the short-term goal for v1alpha1, but failing that, the operator needs to at least create the 3 CRDs in https://github.com/projectcontour/contour/blob/main/examples/contour/01-crds.yaml.

Miciah commented 3 years ago

Looks like https://github.com/go-bindata/go-bindata is not actively maintained, and there is discussion of changing to https://github.com/kevinburke/go-bindata in Kubernetes: https://github.com/kubernetes/kubernetes/issues/96169

jpeach commented 3 years ago

Looks like https://github.com/go-bindata/go-bindata is not actively maintained, and there is discussion of changing to https://github.com/kevinburke/go-bindata in Kubernetes: kubernetes/kubernetes#96169

Apparently embed is coming to Go 1.16.

danehans commented 3 years ago

xref: https://github.com/projectcontour/contour-operator/pull/120 that manages CRDs through a make workflow. This should suffice for v1alpha1. Additional Contour CRD management can be addressed post v1alpha1.

stevesloka commented 3 years ago

You should be able to create the CRD right from the apis package that is exposed from Contour today, no need to parse into yaml and back out.

stevesloka commented 3 years ago

So I poked around with this a bit. It's been a while since I last did this (https://github.com/upmc-enterprises/elasticsearch-operator/blob/master/pkg/k8sutil/k8sutil.go#L174-L187) and things have changed a bit. =)

I made this repo to play with and works, however, the code gen stuff is a problem unless we can find a way to generate the specs in go and not yaml: https://github.com/stevesloka/createcrd/blob/main/main.go

danehans commented 3 years ago

xref https://github.com/projectcontour/contour/pull/3676