+1 on the overall design and thanks for the efforts! I totally agree with the plan of implementing the MVP first. However, since the FLIP is for the whole feature instead of only MVP, how about adding a *Roadmap* or *Future Work* section to write down plans include (but not limited to): * Dynamic switching between unaligned and aligned checkpoints * Supporting local recovery
What do you think? What's more, the existing PoC result of e2e checkpoint duration and throughput looks great, but the recovery/restore time is not mentioned. Not sure whether we also aim at providing a comparative recovery speed with aligned checkpoint in the MVP implementation? Hopefully we could (smile). Best Regards, Yu On Wed, 11 Mar 2020 at 06:14, Thomas Weise <t...@apache.org> wrote: > +1 > > Thanks for putting this together, looking forward to the experimental > support in the next release. > > One clarification: since the MVP won't support rescaling, does it imply > that savepoints will always use aligned checkpointing? If so, this would > still block the user from taking a savepoint and resume with increased > parallelism to resolve a prolonged/permanent backpressure condition? > > Thanks, > Thomas > > > On Tue, Mar 10, 2020 at 6:33 AM Arvid Heise <ar...@ververica.com> wrote: > > > Hi all, > > > > I would like to start the vote for FLIP-76 [1], which is discussed and > > reached a consensus in the discussion thread [2]. > > > > The vote will be open until March. 13th (72h), unless there is an > objection > > or not enough votes. > > > > Thanks, > > Arvid > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints > > [2] > > > > > http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-FLIP-76-Unaligned-checkpoints-td33651.html > > >
