Great feedback Eric. My response is below. Ryan Durfey M | 303-524-5099 24x7 CDN Support: 866-405-2993 or [email protected]
On 4/28/17, 8:18 AM, "Eric Friedrich (efriedri)" <[email protected]> wrote: > On Apr 27, 2017, at 12:19 PM, Durfey, Ryan <[email protected]> wrote: > > As we move into Self-Service discussions, Configuration Management needs to be discussed in greater depth. I wanted to get the conversation started and get feedback from everyone on what the future state should look like and how we get there from our current state. > > TO 2.1 Changes In Progress > Several changes are underway with TO 2.1 that will make a significant impact to current challenges. Derek G., keep me honest. > > 1. Invalidation is being decoupled from configuration updates > * Allows for invalidations on 1 min CRON jobs which should take approximately 3 min total to apply to mid and edge tier in succession. > * Allows configs to be applied to mid tier and edge tier simultaneously reducing time by half. > 2. Reduction in the overall number of config files generated per configuration update > * Allows configs to be applied on tighter than the current 15 min CRON intervals, though not sure how rapidly yet. Will require testing. > This still leaves us with a monolithic configuration management process which contains all Server and Service configs. This presents some challenges to individual Self-Service. > > Future State (v3?) Ideas > > 1. Separate out Server configs from Service configs so they can be: > * Tested separately > * Applied separately > * Logged & reported separately > * Reverted separately > * Non-blocking when issues are encountered. > 2. Separate out individual Service configs for same reasons as above. > 3. Allow for instant push of new configs, no CRON wait time. EF> We have to be careful with Pushes. Depending on how its implemented, this may open up a new API (and a new attack surface) on publicly accessible caches. Any reason to believe a 1 minute cronjob would not be fast enough? RD: I think instant push is the ideal especially if you need to roll something back that is broken. But the reality is that a 1 min cronjob would be pretty close and I wouldn’t have issues with that. I think we attempt to articulate the ideal situation and any time we can get an 80/20 solution that gets us close with significantly less headaches we are very happy with that. > 4. Allow for Service builds and changes to be staged for initial testing prior to production roll out. > 5. Allow for rollback of config changes in both staging and production environments. > 6. Log all Service changes so that a Tenant User can pull back a history of all changes related to their services through the API. > > > Ryan Durfey > Sr. Product Manager - CDN | Comcast Technology Solutions > 1899 Wynkoop Ste. 550 | Denver, CO 8020 > M | 303-524-5099 > [email protected]<mailto:[email protected]> > 24x7 CDN Support: 866-405-2993 or [email protected]<mailto:[email protected]> >
