Cachegroup ui update with fallbacks

CHANGELOG.md

@@ -22,6 +22,10 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/).
 - To traffic_ops_ort.pl added the ability to handle ##OVERRIDE## delivery service ANY_MAP raw remap text to replace and comment out a base delivery service remap rules. THIS IS A TEMPORARY HACK until versioned delivery services are implemented.
 
 ### Changed
+- Traffic Ops Golang Endpoints
+  - Updated /api/1.1/cachegroups: Cache Group Fallbacks are included
+  - Updated /api/1.1/cachegroups: fixed so fallbackToClosest can be set through API
+    - Warning:  a PUT of an old Cache Group JSON without the fallbackToClosest field will result in a `null` value for that field
 - Issue 2821: Fixed "Traffic Router may choose wrong certificate when SNI names overlap"
 - traffic_ops/app/bin/checks/ToDnssecRefresh.pl now requires "user" and "pass" parameters of an operations-level user! Update your scripts accordingly! This was necessary to move to an API endpoint with proper authentication, which may be safely exposed.
 

docs/source/admin/quick_howto/cachegroup_fallback.rst

@@ -0,0 +1,65 @@
+..
+..
+.. _cachegroup-fallback-qht:
+
+*******************************
+Configure Cache Group Fallbacks
+*******************************
+
+.. seealso:: :ref:`tp-configure-cache-groups`
+
+#. Go to 'Topology', click on :term:`Cache Group`\ s, and click on your desired :term:`Cache Group` or click the :guilabel:`+` button to create a new :term:`Cache Group`.
+
+	.. figure:: cachegroup_fallback/00.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Cache Groups page
+
+		Cache Groups Page
+
+#. Verify that the :term:`Cache Group` is of type EDGE_LOC. :term:`Cache Group` Failovers only apply to EDGE_LOC :term:`Cache Group`\ s.
+
+	.. figure:: cachegroup_fallback/01.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Cache Group details page
+
+		Cache Group Details Page
+
+#. Once EDGE_LOC is selected, the Failover Cache Groups section will appear at the bottom of the page. If you are editing an existing :term:`Cache Group`, then the current Failovers will be listed. If creating a new :term:`Cache Group`, the Fallback to Geo Failover box will default to be checked.
+
+	.. figure:: cachegroup_fallback/02.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Failover Cache Groups section of the Cache Group details page
+
+		Failover Cache Groups Section of Cache Group Details Page
+
+#. To add a new Failover to the list, select the "Add Failover :term:`Cache Group`" drop down and choose which :term:`Cache Group` you would like. While in the drop down, you can also type in order to search.
+
+	.. figure:: cachegroup_fallback/03.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Failover Cache Groups section of the Cache Group details page
+
+		Add New Failover Cache Group Section of Cache Group Details Page
+
+#. The order of the Failovers is important. If you want to reorder the Failovers, you can drag and drop them into a new position. A red line will appear to show where the Failover will be dropped.
+
+	.. figure:: cachegroup_fallback/04.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Failover Cache Groups Drag and Drop of the Cache Group details page
+
+		Failover Cache Groups Section Drag and Drop Functionality
+
+#. To remove a Failover, click the trash can symbol on the right hand side of the list.
+
+	.. figure:: cachegroup_fallback/05.png
+		:width: 60%
+		:align: center
+		:alt: Screenshot of the Traffic Portal UI depicting the Failover Cache Groups Delete of the Cache Group details page
+
+		Failover Cache Groups Delete
+
+#. Click the :guilabel:`Update` button (if editing existing :term:`Cache Group`) or the :guilabel:`Create` button (if creating new :term:`Cache Group`) in order to save the Failovers to the :term:`Cache Group`.

docs/source/admin/quick_howto/index.rst

@@ -28,3 +28,4 @@ Traffic Control is a complicated system, and documenting it is not trivial. Some
 	ds_requests
 	steering
 	ciab
+	cachegroup_fallback

docs/source/admin/quick_howto/multi_site.rst

@@ -21,7 +21,7 @@ Configure Multi-Site Origin
 
 The following steps will take you through the procedure of setting up a Multi-Site Origin (MSO).
 
-#. Create Cache Groups for the origin locations, and assign the appropriate parent-child relationship between the mid and origin Cache Groups. Each mid Cache Group can be assigned a primary and secondary origin parent Cache Group. When the mid cache parent configuration is generated, origins in the primary Cache Groups will be listed first, followed by origins in the secondary Cache Group. Origin servers assigned to the Delivery Service that are assigned to neither the primary nor secondary Cache Groups will be listed last.
+#. Create :term:`Cache Group`\ s for the origin locations, and assign the appropriate parent-child relationship between the mid and origin :term:`Cache Group`\ s. Each mid :term:`Cache Group` can be assigned a primary and secondary origin parent :term:`Cache Group`. When the mid cache parent configuration is generated, origins in the primary :term:`Cache Group`\ s will be listed first, followed by origins in the secondary :term:`Cache Group`. Origin servers assigned to the Delivery Service that are assigned to neither the primary nor secondary :term:`Cache Group`\ s will be listed last.
 
 	.. figure:: multi_site/00.png
 		:scale: 100%
@@ -55,7 +55,7 @@ The following steps will take you through the procedure of setting up a Multi-Si
 
 		- If there are multiple CDNs created on the same Traffic Ops, delivery services across different CDNs may have the same OSBU configured.
 		- If several delivery services in the same CDN have the same MSO algorithm configured, they may share the same OSBU.
-		- If delivery services are assigned with different MID cache groups respectively, they can share the same OSBU.
+		- If delivery services are assigned with different MID :term:`Cache Group`\ s respectively, they can share the same OSBU.
 		- This OSBU must be valid - ATS will perform a DNS lookup on this FQDN even if IPs, not DNS, are used in the parent.config.
 		- The OSBU entered as the "Origin Server Base URL" will be sent to the origins as a host header. All origins must be configured to respond to this host.
 

docs/source/admin/traffic_ops/configuration.rst

@@ -240,18 +240,18 @@ Below is a list of Traffic Server plug-ins that need to be configured in the par
 
 Below is a list of cache parameters for special configuration, which are unlikely to need changes, but may be useful in particular circumstances:
 
-+--------------------------+-------------------+-------------------------------------------------------------------------------------------------------------------------+
-|           Name           |    Config File    |                                                       Description                                                       |
-+==========================+===================+=========================================================================================================================+
-| not_a_parent             | parent.config     | This is a boolean flag and is considered 'true' if it exists and has any value except 'false'.                          |
-|                          |                   | This prevents servers with this parameter in their profile from being inserted into the ``parent.config`` generated for |
-|                          |                   | servers with this server's Cache Group as a parent of their CacheGroup. This is primarily useful for when edge caches   |
-|                          |                   | are configured to have a Cache Group of other edge caches as parents (a highly unusual configuration), and it is        |
-|                          |                   | necessary to exclude some, but not all, edges in the parent Cache Group from the ``parent.config`` (for example,        |
-|                          |                   | because they lack necessary capabilities), but still have all edges in the same Cache Group in order to take traffic    |
-|                          |                   | from ordinary Delivery Services at that Cache Group's geographic location. Once again, this is a highly unusual         |
-|                          |                   | scenario, and under ordinary circumstances this parameter should not exist.                                             |
-+--------------------------+-------------------+-------------------------------------------------------------------------------------------------------------------------+
++--------------------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------+
+|           Name           |    Config File    |                                                       Description                                                               |
++==========================+===================+=================================================================================================================================+
+| not_a_parent             | parent.config     | This is a boolean flag and is considered 'true' if it exists and has any value except 'false'.                                  |
+|                          |                   | This prevents servers with this parameter in their profile from being inserted into the ``parent.config`` generated for servers |
+|                          |                   | with this server's :term:`Cache Group` as a parent of their :term:`Cache Group`. This is primarily useful for when edge caches  |
+|                          |                   | are configured to have a :term:`Cache Group` of other edge caches as parents (a highly unusual configuration), and it is        |
+|                          |                   | necessary to exclude some, but not all, edges in the parent :term:`Cache Group` from the ``parent.config`` (for example,        |
+|                          |                   | because they lack necessary capabilities), but still have all edges in the same :term:`Cache Group` in order to take traffic    |
+|                          |                   | from ordinary Delivery Services at that :term:`Cache Group`\ 's geographic location. Once again, this is a highly unusual       |
+|                          |                   | scenario, and under ordinary circumstances this parameter should not exist.                                                     |
++--------------------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------+
 
 
 Regions, Locations and Cache Groups
@@ -266,7 +266,7 @@ All servers have to have a 'location', which is their physical location. Each lo
 
 To create these structures in Traffic Portal, first in enter your divisions under `Topology->Divisions`, then enter the regions in `Topology->Regions`, referencing the divisions entered and, finally, enter the physical locations in `Topology->Phys Locations`, referencing the regions entered.
 
-All servers also have to be part of a Cache Group. A Cache Group is a logical grouping of caches, that don't have to be in the same physical location (in fact, usually a cache group is spread across minimally 2 physical Locations for redundancy purposes), but share geographical coordinates for content routing purposes.
+All servers also have to be part of a :term:`Cache Group`. A :term:`Cache Group` is a logical grouping of caches, that don't have to be in the same physical location (in fact, usually a :term:`Cache Group` is spread across minimally 2 physical Locations for redundancy purposes), but share geographical coordinates for content routing purposes.