1. 15 Apr, 2020 1 commit
    • Matt Farina's avatar
      Fix issue with sorting pod lists · 493cd340
      Matt Farina authored
      
      The sorting previously used the selfref which contained the name
      on the end for all cases except pods. In that case the selfref
      was to pods and not the specific pod. This caused an issue where
      multiple pods had the same selfref used as the key for softing.
      
      The objects being sorted are tables that each have one row. In the
      new setup the key is the first cells value from the first and only
      row. This is the name of the resource.
      
      Note, the Get function now requests a table. The tests have been
      updated to return a Table type for the objects.
      
      Closes #7924
      
      Signed-off-by: default avatarMatt Farina <matt@mattfarina.com>
      Unverified
      493cd340
  2. 30 Mar, 2020 1 commit
  3. 25 Mar, 2020 1 commit
  4. 20 Mar, 2020 1 commit
    • Matt Farina's avatar
      Restores display of object status when displaying helm status · e8396c92
      Matt Farina authored
      
      Changes to the Kubernetes API server and kubectl libraries caused
      the status to no longer display when helm status was run for a
      release. This change restores the status display.
      
      Generation of the tables for display was moved server
      side. A request for the data as a table is made and a kubectl
      printer for tables can display this data. Kubectl uses this setup and
      the structure here closely resembles kubectl. kubectl is still
      able to display objects as tables from prior to server side
      printing but only prints limited information.
      
      Note, an extra request is made because table responses cannot be
      easily transformed into Go objects for Kubernetes types to work
      with. There is one request to get the resources for display in
      a table and a second request to get the resources to lookup the
      related pods. The related pods are now requested as a table as
      well for display purposes.
      
      This is likely part of the larger trend to move features like
      this server side so that more libraries in more languages can
      get to the feature.
      
      Closes #6896
      
      Signed-off-by: default avatarMatt Farina <matt@mattfarina.com>
      Unverified
      e8396c92
  5. 07 Nov, 2019 1 commit
    • Taylor Thomas's avatar
      fix(kube): Fixes wait for jobs · 77c97342
      Taylor Thomas authored
      
      This happened to be a bug we identified in Helm 3 and did not check if
      it existed in Helm 2. The improved logic for job waiting used an automatic
      retry. However, when we were creating the watcher, we were listing on everything
      of that same api version and kind. So if you had more than 1 hook and the first
      was successful, it would think everything was successful. I have validated that
      this now fails as intended if a job is failing
      
      Closes #6767
      
      Signed-off-by: default avatarTaylor Thomas <taylor.thomas@microsoft.com>
      77c97342
  6. 06 Nov, 2019 1 commit
  7. 29 Oct, 2019 1 commit
  8. 11 Oct, 2019 1 commit
    • Matthew Fisher's avatar
      fix(kube): fix race condition · 33bb8885
      Matthew Fisher authored
      
      .Get() calls perform() on a list of infos, populating two shared maps. perform() now concurrently calls the ResourceActorFunc concurrently based on GVK, causing a data race condition in .Get()
      
      This fixes that condition by locking the function to ensure these functions run serially for Helm 2 to fix the data race condition. This has since been optimized in Helm 3 so it's no longer an issue.
      
      Signed-off-by: default avatarMatthew Fisher <matt.fisher@microsoft.com>
      Unverified
      33bb8885
  9. 10 Oct, 2019 1 commit
  10. 08 Oct, 2019 3 commits
  11. 03 Oct, 2019 1 commit
  12. 01 Oct, 2019 1 commit
  13. 30 Aug, 2019 1 commit
  14. 23 Aug, 2019 1 commit
  15. 26 Jul, 2019 1 commit
    • Yusuke Kuoka's avatar
      fix: upgrade with CRD changes · ae52477f
      Yusuke Kuoka authored
      
      Probably since K8s 1.13.x, `converter.ConvertToVersion(info.Object, groupVersioner)` which is the body of `asVersioned` doesn't return an error or an "unstructured" object, but `apiextensions/v1beta1.CustomResourceDefinition`.
      
      The result was `helm upgrade` with any changes in CRD consistently failing.
      
      This fixes that by adding an additional case of the conversion result being `v1beta1.CustomResourceDefinition`.
      
      This is a backward-compatible change as it doesn't remove existing switch cases for older K8s versions.
      
      Fixes #5853
      
      Signed-off-by: default avatarYusuke Kuoka <ykuoka@gmail.com>
      ae52477f
  16. 24 Jul, 2019 1 commit
  17. 20 Jun, 2019 1 commit
  18. 19 May, 2019 1 commit
  19. 25 Apr, 2019 1 commit
  20. 22 Apr, 2019 1 commit
  21. 17 Apr, 2019 1 commit
  22. 10 Apr, 2019 1 commit
  23. 04 Apr, 2019 1 commit
  24. 30 Mar, 2019 1 commit
  25. 26 Mar, 2019 1 commit
  26. 25 Mar, 2019 1 commit
  27. 22 Mar, 2019 2 commits
    • Fernando Barbosa's avatar
    • Timofey Kirillov's avatar
      Fix `no RESOURCE with the name NAME found` · 5ffe4ce5
      Timofey Kirillov authored
      This is the fix for only one particular, but important case.
      
      The case when a new resource has been added to the chart and
      there is an error in the chart, which leads to release failure.
      In this case after first failed release upgrade new resource will be
      created in the cluster. On the next release upgrade there will be the error:
      `no RESOURCE with the name NAME found` for this newly created resource
      from the previous release upgrade.
      
      The root of this problem is in the side effect of the first release process,
      Release invariant says: if resouce exists in the kubernetes cluster, then
      it should exist in the release storage. But this invariant has been broken
      by helm itself -- because helm created new resources as side effect and not
      adopted them into release storage.
      
      To maintain release invariant for such case during release upgrade operation
      all newly *successfully* created resources will be deleted in the case
      of an error in the subsequent resources update.
      
      Th...
      Unverified
      5ffe4ce5
  28. 16 Mar, 2019 1 commit
  29. 04 Mar, 2019 1 commit
  30. 07 Feb, 2019 1 commit
  31. 29 Jan, 2019 1 commit
  32. 08 Jan, 2019 2 commits
  33. 05 Dec, 2018 1 commit
  34. 29 Nov, 2018 1 commit
    • Morten Torkildsen's avatar
      fix(helm): Allow custom resources in hooks (#4986) · 55a33857
      Morten Torkildsen authored
      
      Currently the code that handles hooks uses a builder that creates the versioned types rather than unstructured. This results in an error whenever a custom resource is used in the hook as the type will not be registered in the scheme used in Helm. This changes this to use a builder that created unstructured resources and only converts to the versioned type when needed.
      
      Signed-off-by: default avatarMorten Torkildsen <mortent@google.com>
      55a33857
  35. 28 Nov, 2018 1 commit
  36. 15 Nov, 2018 1 commit
    • Morten Torkildsen's avatar
      fix(helm): Fix linebreaks when printing custom resources · 5ac37fba
      Morten Torkildsen authored
      
      The output from helm status is not correct for custom resources. The
      HumanReadablePrinter from Kubernetes only outputs the column names when
      the type differs from the previous one. This makes the output
      inconsistent and also creates problems for putting in the correct line
      breaks. This PR sets up a new printer for each type, thereby making sure
      that all types are printed with the correct use of line breaks and with
      column names.
      
      Signed-off-by: default avatarMorten Torkildsen <mortent@google.com>
      5ac37fba