[ 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)