> 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?



>  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]>
> 

Reply via email to