[atombender]

Sorry, "atomic" was not the best term here.

I don't know if there is a word for it — it comes up in a lot of situations — but given a set of resources, Helm will diff against Kubernetes and wipe out anything superfluous. So if I've deployed a chart that has (A, B, C) and then do a new deploy of (A, B), then C will be deleted. "Destructive diffing"? I don't know.

Kubernetes itself is not atomic right now. I believe Etcd supports multi-key transactions now, so it could be done.

[ownagefool]

Right.

But even if kubernetes and etcd supported multi-document transactions and thus gave you the ability to update data in an atomic way, you'd also need to be doing green/blue deploy and then atomically switching service calls, whilst maintaing old network traffic/service calls goes to old pods and new network traffic/service calls goes to new pods.

Pretty complicated and whilst it can be solved, I dont want us thinking that services will fully function during a helm or even a kubernetes update with major api changes between services. Likely your old service will call the new service and fail. This level of failure might be acceptable or you can work around it by having retries or keeping APIs backwards compatible for several versions.

Apologies for blabbering, I would consider the current default state of deploys with rolling upgades to be akin to eventual consistency, but it's possible it's more clever than that.

[scott_s]

I believe Kubernetes itself supports that kind of a change - that is, re-applying a config and creating or deleting resources based on the update.

I would say that helm is batch, in that it's applying a bunch of stuff at once, but not doing it transactionally.