deis / charts

(OBSOLETE) Helm Classic v1 Charts for Deis Workflow
https://deis.com/workflow/
MIT License
45 stars 36 forks source link

We're only 1/2 way transitioned to deployments? #337

Closed krancour closed 8 years ago

krancour commented 8 years ago

Looks like we're using deployments for some components (e.g. controller and router), but are still relying on RCs for others (e.g. database, logger... others?) We could stand to be more consistent on this.

(I know RCs are supposed to continue to exist and just be set to replicas: 0, and that's not what I am reporting here. I'm RCs still set to replicas: 1, with no corresponding deployment existing at all.)

helgi commented 8 years ago

Deployments are not going to work for some of those components which is why they were left out, intentionally.

When you have Deployments with helm-keep then you are doing a rolling-update, something a Database will not like a whole lot, same with other data stores, unless they are replicated so there is no data loss. PetSets will be the dealio there when that's stable enough.

Logger (and some log subcomponent) potentially can be moved tho, @jchauncey mentioned that being the case but it requires someone with working knowledge of that stack to take on the work.

krancour commented 8 years ago

I see. But seems we can agree there are some candidates for this treatment that didn't receive it yet.

helgi commented 8 years ago

Yeah, but no urgency to move them over either. Originally only router was supposed to move and I took a stab at a few easy services since I had the time and knowledge.

At this point we need to identify which other components can be moved without causing data loss, etc

krancour commented 8 years ago

Logger is now stateless. It would be a candidate. I'd let others more familiar with each component speak to the suitability of each for the ol' deployment treatment.

mboersma commented 8 years ago

Yeah, but no urgency to move them over either.

That's what I wanted to hear. Onward with the v2.4 release then--I'll mark this for the next release unless someone disagrees.

bacongobbler commented 8 years ago

@helgi is on point for postgres. A replication controller is the best way to deploy because we want to guarantee that only 1 pod runs at a time during an upgrade. The old container needs to finish shipping its last WAL log before the new one can replay from object storage.