Hi folks. Is there any progress on eclipse/packages#2
Actually we like to enhance the Ditto chart, but it is still not available from a registry.
@ctron you mentioned that charts will become available at https://www.eclipse.org/packages/charts/, unfortunately I got a 404. What has to be done, to get the charts published there?
Actually we like to enhance the Ditto chart, but it is still not available from a registry.
@ctron you mentioned that charts will become available at https://www.eclipse.org/packages/charts/, unfortunately I got a 404. What has to be done, to get the charts published there?
hi Axel .. the Ditto chart is published as snapshot, see: https://www.eclipse.org/packages/charts/index.yaml
what is missing is the addition to helm hub I think
sure .. it is part of the following Jenkins job which @ctron did back last year: https://ci.eclipse.org/packages/job/Website/job/master/
Maybe best in here: https://www.eclipse.org/packages/repository/
Which is the following markdown file: https://github.com/eclipse/packages/blob/master/homepage/repository.md
Which is the following markdown file: https://github.com/eclipse/packages/blob/master/homepage/repository.md
When running the tests for Hono alone, I run into an issue with Prometheus: eclipse/packages#13 … but I guess this is a prometheus issue
@sophokles73 You could give kind a try (see https://github.com/eclipse/packages/tree/master/charts/ditto#local-setup for example), next to that you can play around w/ the resource and probe configuration for both releases (ditto and hono).
I did have issues with those in the past, and IIRC worked around that using using the ClusterIP instead.
Using
ClusterIP effectively prevents access from outside of the cluster. Since we are talking about Hono's public remote APIs here, I do not think that we should set it to ClusterIP. However, we could set it to NodePort, then the services wouldn't wait for a loadbalancer to provide an ingress. There already is a configuration property in the values.yaml file (useLoadBalancer) for controlling this. The default value is true ...
LoadBalancer is the default because it allows for the default config to be used to deploy to both a local minikube as well as e.g. a managed Kubernetes on Azure/AWS (which provide load balancers as part of the managed service offering) and for using exactly the same commands/steps in the getting started guide. Changing the default to be NodePort is of course possible but would require to (re-)introduce a distinction between minikube and managed cluster in the Getting Started guide. I would rather like to prevent that.
users still have the ability to enable LoadBalancer though
NodePort is the only thing that works …
looks like there's another way as well. https://github.com/helm/chart-testing/blob/master/doc/ct_install.md describes how CI specific config values can be used by adding a corresponding
So, based on that, it should be sufficient to add a file
*-values.yaml file to the ci folder of the chart ...So, based on that, it should be sufficient to add a file
ci-values.yaml with content useLoadBalancer: false to the ci folder of the chart.
yes, that didn't work
not for me, and I don't seem to be the only one
maybe you know the wrong people :D
again … we can leave the LoadBalancer a default, but at least for the ct we need to switch … later on we can always put in a note that "if it doesn't work: use NodePort"
Jens, you are usually the first person to try to find out why something is not working as expected. Did you actually spend any time figuring out why it doesn't work on your machine ("it doesn't work on my machine" is the little brother of "it works on my machine", isn't it?)
Yes, I did … and after spending a few hours, I gave up and switched to NodePort … which always works … I saw reports from other people as well … now if that is a problem to some people, while NodePort isn't a problem … I would say that it makes more sense, in the context of "getting started quickly" to use the solution which works better … but if LoadBalancer is more important to you, let's use that
nevertheless, we cannot validate it with the CI pipeline
I have outlined a way to set that property during execution of the CI pipeline. Have you tried that?