Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Axel Köhler
    @axdotl
    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?
    Thomas Jaeckle
    @thjaeckle
    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
    Axel Köhler
    @axdotl
    Ahhh... great. Then I would prepare a PR for the Helm Hub and update the Ditto chart afterwards.
    Thomas Jaeckle
    @thjaeckle
    cool :+1:
    Axel Köhler
    @axdotl
    May I ask how are the publishing process currently works?
    Thomas Jaeckle
    @thjaeckle
    I guess we can also change the Ditto helm chart version to 1.0.0
    sure .. it is part of the following Jenkins job which @ctron did back last year: https://ci.eclipse.org/packages/job/Website/job/master/
    Axel Köhler
    @axdotl
    Is this already documented somewhere? If not, do you agree when I'm adding some docu to the packages project about CI and publishing process? (at least for the Helm part)
    Thomas Jaeckle
    @thjaeckle
    I don't think that it is documented ..
    Would be great to add that, yes. Where do you want to put that? As part of the packages website or in a markdown file (e.g. in a to be created charts/README.md)
    Axel Köhler
    @axdotl
    I'll do it in the mentioned md file.
    Kai Hudalla
    @sophokles73
    Hi, I am currently trying to deploy the Hono and Ditto charts into the same minikube cluster with 8GB RAM. Deploying one of them works well. However, when I start the other one, pods begin to restart. I suppose that is because of memory. Anybody having the same experience?
    Jens Reimann
    @ctron
    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
    Axel Köhler
    @axdotl
    @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).
    Jens Reimann
    @ctron
    I just saw a note on the eclipse architecural council mailing list, that for github action, we will not get credentials. So I guess pushing content to the website is not an option, and we continue to use the jenkins build job for that.
    Jens Reimann
    @ctron
    @sophokles73 as I am a noob when it comes to plain kubernetes load balancers, and ingress … can you imagine a reason why the hono services don't come up properly?
    I did have issues with those in the past, and IIRC worked around that using using the ClusterIP instead.
    Kai Hudalla
    @sophokles73
    @ctron Hey Jens, you might have a point there. The Hono chart by default installs services with a loadbalancer type. We could use a NodePort instead and that might indeed fix the deployment problem ni the CI pipeline ...
    Jens Reimann
    @ctron
    I just checked Ditto, and they are using ClusterIP be default … but allow to freely set the type using the values … could that be the way for Hono as well?
    Kai Hudalla
    @sophokles73
    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 ...
    Jens Reimann
    @ctron
    I made a change to allow configuring it, and default to NodePort, the CI was green with that change. I changed the version of the chart to 2.0.0, and if the CI is green again, we can think about merging that.
    Jens Reimann
    @ctron
    @sophokles73 do you have any thoughts on the discussion around ClusterIP vs NodePort vs LoadBalancer?
    Jens Reimann
    @ctron
    Ok … looks like NodePort as a default is good enough
    Kai Hudalla
    @sophokles73
    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.
    Jens Reimann
    @ctron
    well it looks like there is no other choice … to me it looks like ClusterIP is the only thing which works
    users still have the ability to enable LoadBalancer though
    Kai Hudalla
    @sophokles73
    Didn't you say that it works with NodePort?
    Jens Reimann
    @ctron
    sorry, yes!
    NodePort is the only thing that works …
    Kai Hudalla
    @sophokles73
    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 *-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.
    Jens Reimann
    @ctron
    yes, but that would still leave you with broken services in Minikube
    Kai Hudalla
    @sophokles73
    how so?
    Jens Reimann
    @ctron
    When running minikube the services also didn't come up, and connecting wasn't possible
    Kai Hudalla
    @sophokles73
    That's why we explicitly tell users to run minikube tunnel ...
    Jens Reimann
    @ctron
    and it did work with the NodePort and the minikube ip
    yes, that didn't work
    Kai Hudalla
    @sophokles73
    that works like a charm ...
    Jens Reimann
    @ctron
    nope
    not for me, and I don't seem to be the only one
    Kai Hudalla
    @sophokles73
    I only know people for whom it works. there is no corresponding issue as well, so FMPOV nobody has a problem with it ...
    Jens Reimann
    @ctron
    I mean we can still let the default be load balancer, if it is that important … but then I would recommend to change it for the package-zero chart, and for the ct validation
    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"
    Kai Hudalla
    @sophokles73
    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?)
    Jens Reimann
    @ctron
    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
    Kai Hudalla
    @sophokles73
    I absolutely do not want to re-write the Getting Started guide to contain specific steps for minikube vs. managed cluster.
    Nothing prevents you from using --set useLoadBalancer=false on the helm install command line, if that works better for you ...
    I have outlined a way to set that property during execution of the CI pipeline. Have you tried that?
    Jens Reimann
    @ctron
    I will switch the default and do that next