[jira] [Updated] (TC-130) Service Configuration Streamlining and Sequencing

["Ryan Durfey (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Durfey updated TC-130:
---------------------------
         Labels: configruation state_machine  (was: )
    Component/s: Traffic Ops API
        Summary: Service Configuration Streamlining and Sequencing  (was: Streamlining TC management and operations sequences)

> Service Configuration Streamlining and Sequencing
> -------------------------------------------------
>
>                 Key: TC-130
>                 URL: https://issues.apache.org/jira/browse/TC-130
>             Project: Traffic Control
>          Issue Type: New Feature
>          Components: Traffic Ops, Traffic Ops API, Traffic Router
>            Reporter: Nir Sopher
>              Labels: configruation, state_machine
>
> Hi,
> In order to further improve the simplicity and robustness of the control path for provisioning infrastructure and delivery services, we are currently considering ways to streamline management and operations.
> Currently, when applying changes in traffic-control that require the synchronization between the traffic-router and traffic-servers, the user should be conscious to do so in a certain order. Otherwise, "black holes" may be created. Furthermore, in some of the scenarios the user have to wait and verify that the configuration reached all traffic server before he may apply it to the traffic-router. 
> The main use-cases we would like to address at this point are:
> * Assign servers to a Delivery-Service. 
> For this operation, the configuration must first be applied to the added traffic servers, propagate, and only then applied to the traffic-router.
> * Remove servers assignment to a Delivery-Service. 
> For this operation, the configuration must first be applied to the traffic-router, and only then to the traffic-servers.
> * Add a new delivery service.
> This is practically a private case of servers assignment to a delivery-service.
> * Delete a delivery service.
> This is practically a private case of servers assignment removal from a delivery-service.
> * Update settings that must be applied together on the traffic servers and the router. 
> We would like to simplify the procedure, allowing the deployment of new configuration in a single operation, instead of doing it step by step. 
> One solution can be based on the insight that deploying such configuration changes may be done by initially updating the traffic server with added functionality (e.g remap-rule), then updating the router, and lastly, removing old functionality from the traffic servers. Such a solution can be orchestrated by traffic-ops, probably without complicating other components.
> Other solutions may provide more flexibility, but would probably involve adding complexity to other components such as traffic-router. 
> An example to such a solution, already under discussion in a mail tread (10x Eric:) may be based on the concept of a delivery-service configuration "generation" which would be an ordinal identifier for the a delivery service configuration. A "generation" changes whenever the remap rule changes or the consistent hash mapping of content to server changes (e.g. due to additional server assignment).
> In such a solution, each traffic-server may hold a single generation for each delivery service configuration, while traffic-router may hold a history of generations and know which server holds which configuration generation.
> This approach introduces a considerable flexibility. It allows configurations to be set one after the other with no need to wait between them.
> On the other hand, complicated algorithms for solving the issue may impose more risk to the network when applied, comparing to a simple "traffic-ops" orchestrated solution.
> Both approaches fit well with TC-129: Create TO API endpoint to queue all servers for a delivery service
> I'm not sure what is preferable from an operator point of view. I'm also not familiar with TC 3.0 "Config State Machine" solution to validate he different approaches against.
> Nir



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)