https://pulumi.com logo
Join Slack
Powered by
is there a way to force a resource to be replaced?...
# general
b
is there a way to force a resource to be replaced? it seems there's a bug where updating the labels of a 
clusterIP
service doesn't cause a replace, instead it tries to update the service which causes an error because the 
spec.clusterIP
field is immutable and set by kubernetes if not specified at creation time
c
@bitter-dentist-28132 When you say updating the labels should cause a replace, what do you mean?
which labels?
b
the service's metadata.labels field
i.e.
Copy code
~ kubernetes:core/v1:Service: (update)
            [id=default/nginxingresscontroller-nginx-ingress-default-backend]
            [urn=urn:pulumi:nightly::cfm::kubernetes:<http://helm.sh/v2:Chart$kubernetes:core/v1:Service::nginxingresscontroller-nginx-ingress-default-backend|helm.sh/v2:Chart$kubernetes:core/v1:Service::nginxingresscontroller-nginx-ingress-default-backend>]
            [provider=urn:pulumi:nightly::cfm::pulumi:providers:kubernetes::cfm::a54fb532-f407-4d17-8436-5dd9fb344698]
          ~ metadata: {
              ~ labels: {
                  ~ chart: "nginx-ingress-1.17.1" => "nginx-ingress-1.17.1"
                }
            }
c
why should that trigger a replace?
b
anything should trigger a replace when you've got a service of type 
clusterIP
when you haven't specified 
spec.clusterIP
, otherwise you end up with:
Copy code
* Service "nginxingresscontroller-nginx-ingress-default-backend" is invalid: spec.clusterIP: Invalid value: "": field is immutable
unfortunately, that field is not really immutable, in that kubernetes changes it to an automatically-assigned IP if it's empty. it's just not mutable for the user.
c
We shouldn’t be triggering a replace unless you change a field that is immutable. If you didn’t change 
.spec.clusterIP
, it should be an update.
it sounds like somehow 
""
is getting passed as the value of `.spec.clusterIP`—so if the API server filled that value in, that might register it as a change, I guess?
are you instantiating this from YAML or a helm chart?
b
this one is a helm chart
c
yeah. when we’ve seen this before it’s because the hlm author put 
""
in that field.
really, really annoying.
b
😑
c
it’s pretty common though.
b
it always boggles my mind how terrible helm is
c
it pretty much precludes ever updating the chart. 🙂
b
i guess i'll open a bug on the chart...
c
if you use the 
transformations
callback you can fix this by setting 
clusterIP: undefined
it’s a huge pain.
b
ah, looks like i can specify 
.Values.controller.metrics.service.omitClusterIP
, very odd that it'll put an empty clusterIP by default instead of just not specifying that key
c
lol
one day I’ll write a kube linter and just run it on every goddamn helm chart.
I know they exist, but there’s a bunch of stuff like this that I feel like I know and a lot of other people don’t.
b
heh. yeah, that and adding an explicit 
namespace: {{ .Release.Namespace }}
everywhere so that it doesn't rely on tiller's resource transformations.
such a strange tool.
anyway, thanks a bunch, wouldn't have guessed the chart was doing that.
c
yeah, this is the sort of bug that you just have to pick up after a looooooooong time helping people debug. 🙂
s
@creamy-potato-29402 There’s already a 
helm lint
command. Don’t know if it tests for this, though.
31 Views
Open in Slack
PreviousNext
Powered by