Closed krancour closed 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.
I see. But seems we can agree there are some candidates for this treatment that didn't receive it yet.
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
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.
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.
@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.
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 toreplicas: 1
, with no corresponding deployment existing at all.)