Hi Jesse,
Thanks for this question. We 've been visiting it already lately. We
haven't gone through a process of documenting it as a policy (as we are
still experimenting) but I 'll do my best to summarize what my
understanding of that recent discussion was (feel free to correct me)
* applications/services that are developed internally and are supporting
end-user applications should always use the scaffolding we provide. As a
helping point, these all are under the helmfile.d/*services hierarchy in
the deployment-charts repo. They all also invariably use the "services
images" as described in
https://wikitech.wikimedia.org/wiki/Kubernetes/Images. And finally, there
are a lot in numbers (I count 33), always increasing.
For these charts, upstream helm charts can be used as an inspiration, but
the ending helm chart should be WMF owned. That way they 'll have a helm
chart that we will be able to keep up to date with our standards, allowing
for consistent behavior across the various sidecars, labels, tolerations,
canaries, affinities and other functionalities that we 've been
implementing. We 've already gone down the road of allowing some helm
charts to diverge from that consistent path and it was painful every time
we needed to do some operation on the services they powered. Needless to
say we have backtracked from it and don't want to ever go down that
path again.
* apps/services that are deployed as a part of a cluster. These are few and
additions happen rarely. They are always deployed by an SRE as part of
functionality added to a cluster. Their distinguishing point is that they
all are under the helmfile.d/admin_ng directory of the helm charts repo.
They also all use images that are defined under the badly named "production
images" part of
https://wikitech.wikimedia.org/wiki/Kubernetes/Images. They
are few in number (I count 8) respectively. For those, **for now** the
agreement is to experiment with upstream charts and figure out if indeed
they make sense or not and how heavy modifications we 'll need to do to
them for our purposes.
Flink-operator is such an example. spark-operator was a chart however the
needed heavy modifications by Ben in the RBAC rules it shipped with as it
came with overly broad rules and thus access.
Specifically for Jaeger, I think it fits the second category, so it
probably is ok to experiment with the upstream chart and figure out if it
is good enough or not.
On Wed, Feb 8, 2023 at 12:53 AM Jesse Hathaway <jhathaway(a)wikimedia.org>
wrote:
What is the general thought process of the group
around using upstream
helm charts?
In my effort to stand up Jaeger I have been using the upstream charts to
test locally in Minikube. Thus far they seem to work pretty well, my
current work in progress may be found here,
https://gitlab.wikimedia.org/repos/sre/jaeger-minikube.
Giuseppe mentioned concerns with the quality of upstream charts. How
does one assess the quality, other than through use?
_______________________________________________
Kubernetes-sig mailing list -- kubernetes-sig(a)lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/kubernetes-sig.lists.wikimedia.…
--
Alexandros Kosiaris
Principal Site Reliability Engineer
Wikimedia Foundation