At the summit, I presented a plan for automated change integrity (the "snapshot-queue" problem).
The technical spec is on the wiki at: https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity Solving the "snapshot-queue" problem is just one of many parts of implementing Self Service, but it's one of the algorithmically hard problems. In a nutshell, the plan is to use timestamps as an implicit state machine, to track what changes have been applied where. The plan involves minimal API changes; the existing API will remain, and we'll add the minimum necessary additional APIs. At some level, a state machine is unavoidable to solve this problem, and using timestamps is one of the simplest, easiest to understand, most powerful ways to do it. Further, comprehensive timestamps make a great deal of other features -- tracking changes through the CDN, debugging configuration issues, computing and displaying change progress, replacing the monolithic CRConfig with changesets, and many other things -- much easier to implement. If anyone has issues with this plan, please let us know as soon as possible. The plan is to start working on it immediately. That said, this isn't a small project, it will take a considerable amount of time to implement. Likewise, because of the scale of the problem, the current spec is almost certainly incomplete, and we'll have to adjust or add things as we discover them. Finally, @nirs has a plan for delivery service versions. That plan should integrate well with the Change Integrity plan, and I believe both features will be able to reuse the same "delivery service snapshot/version" database table, hopefully as simple as changing the table to use the version instead of the timestamp, and changing the SQL queries to follow the additional redirect. Thanks,
