Installing TC 2.1 from scratch - Remarks

[Nir Sopher <ni...@qwilt.com>]

Hi All,

We have recently installed a new TC 2.1 instance.
During the process we encountered a few issues, described below.
Most of the issues are the outcome of the TC being "new". I have listed
them below to enrich the community knowledge base. JIRAs for improvements
were opened as well.

The installation details:

   1. The different components images were built based on commit
   3980b41797c8f2b616277df4b74e73a011c48869.
   2. For TPv2 we used a later (quite recent) commit.
   3. Golang Traffic-Monitor was used.
   4. We imported the profiles as published in the TC web site
   <http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/>


The first issue we encountered, after installing all the different
components, and connecting them together as required, was a failure of TM
to pull the cr-config.
TM log had the following as full with message "MonitorConfigPoller:
skipping this iteration, Session is nil".
It seems that the configuration was ignored as there were still no DS to
Server assignment.
Note that as the TR pulls the configuration from the TM, the TR was not
able to pull configuration as well.
JIRA created: TC-526 <https://issues.apache.org/jira/browse/TC-526> - TM
does not pull configuration where no DS/Server assignment exists


After adding the assignment Traffic Monitor started to monitor the caches.
However, at that point we did not have real caches yet. This due to
different issues with ATS installation on Centos7
- We tried to install ATS 5.3 on Centos7 server, so we can also install the
ORT RPM we created. However, astat installation failed.
- We tried to install ATS 6.2.1 downloaded from the ATS download page
<http://trafficserver.apache.org/downloads>. However, the ORT script failed
to pull configuration, as the "ATS RPM" was not installed.


We decided to move on and test the rest of the system, forcing the
configured servers to be "ONLINE" (this will bite us later on).
At that point, we approached the HHTTP delivery service via the tr (wget
http://tr....).
We expected to be redirected to the (non-existing) caches, however, we were
redirected to the "bypass" URL.
Looking at the TR access.log, we saw that reason for moving to the bypass
was "DS_CLIENT_GEO_UNSUPPORTED", even-though there were no geo restrictions
set to the DS.
The traffic_router.log shows that the traffic-router fails to download the
geolocation data-base from http://${toHostname}/MaxMind/
auto/GeoIP2-City.mmdb.gz, this is for 2 reasons:
1. The "${toHostname} " is not being replaced with the actual Ops host-name.
2. Even when replacing the variable with the actual host-name, the "
MaxMind/auto/GeoIP2-City.mmdb.gz" path does not exists. We replaced it with
"routing/GeoLite2-City.mmdb.gz"
Similar issues were found for the federations and coverage-zone file
JIRA created:
TC-527 <https://issues.apache.org/jira/browse/TC-527> - Traffic_Router
Default Profile - Uses unsupported pattern (${toHostname})
TC-528 <https://issues.apache.org/jira/browse/TC-528> - Traffic Router - To
support the ${toHostname} pattern when parsing the cr-config
TC-529 <https://issues.apache.org/jira/browse/TC-529> -
<https://issues.apache.org/jira/browse/TC-529>TRAFFIC_ROUTER default
profile points to non existing geolocation DB endpoint
TC-530 <https://issues.apache.org/jira/browse/TC-530> - TRAFFIC_ROUTER
default profile points to non existing coverage-zone DB endpoint


Initial adjustments of the TRAFFIC_ROUTER profile had no effect, as the TM
did not pull the new cr-config.
TM log indicated the reason:  "No REPORTED caches exist in Traffic Ops,
nothing to poll." (a reminder: edge and mid servers exist, but are force to
be ONLINE and not "REPORTED").
We moved the "mid" server to REPORTED, restarted the monitor, and finally
got our redirect.
TC-531 <https://issues.apache.org/jira/browse/TC-531> -  Traffic Monitor
does not pull new cr-config when all servers in in "ONLINE" and not
"REPORTED"


Finally we connected the new Traffic-Portal to the TC.
Note that currently there is an issue installing nodejs on Centos7 server,
as the http-parser RPM was removed from epel. See additional info
<https://bugs.centos.org/view.php?id=13669&nbn=1> and JIRA open by Jeremy:
TC-521 <https://issues.apache.org/jira/browse/TC-521> -  TPv2 - http-parser
dependency cannot be resolved
'
One the portal was up, it made a great impression!!! we are now starting to
"play" with it.
Note that initially the login to the server failed. The issue was resolved
once we opened the firewall from the Ops server to the Portal (Portal to
Ops was already open).

I hope this would help others installing TC 2.1.

Nir

Re: Installing TC 2.1 from scratch - Remarks

[Jeremy Mitchell <mi...@gmail.com>]

Nir,

Thanks for sharing your experience regarding the install of TC2.1 and
thanks for creating all the related issues. Re: traffic portal a PR was
submitted / merged for TC-521 <https://issues.apache.org/jira/browse/TC-521>
 -  TPv2 - http-parser dependency cannot be resolved (
https://github.com/apache/incubator-trafficcontrol/pull/815)

Jeremy

On Tue, Aug 15, 2017 at 3:19 PM, Nir Sopher <ni...@qwilt.com> wrote:

> Hi All,
>
> We have recently installed a new TC 2.1 instance.
> During the process we encountered a few issues, described below.
> Most of the issues are the outcome of the TC being "new". I have listed
> them below to enrich the community knowledge base. JIRAs for improvements
> were opened as well.
>
> The installation details:
>
>    1. The different components images were built based on
>    commit 3980b41797c8f2b616277df4b74e73a011c48869.
>    2. For TPv2 we used a later (quite recent) commit.
>    3. Golang Traffic-Monitor was used.
>    4. We imported the profiles as published in the TC web site
>    <http://trafficcontrol.apache.org/downloads/profiles/2.0.x/default/>
>
>
> The first issue we encountered, after installing all the different
> components, and connecting them together as required, was a failure of TM
> to pull the cr-config.
> TM log had the following as full with message "MonitorConfigPoller:
> skipping this iteration, Session is nil".
> It seems that the configuration was ignored as there were still no DS to
> Server assignment.
> Note that as the TR pulls the configuration from the TM, the TR was not
> able to pull configuration as well.
> JIRA created: TC-526 <https://issues.apache.org/jira/browse/TC-526> - TM
> does not pull configuration where no DS/Server assignment exists
>
>
> After adding the assignment Traffic Monitor started to monitor the caches.
> However, at that point we did not have real caches yet. This due to
> different issues with ATS installation on Centos7
> - We tried to install ATS 5.3 on Centos7 server, so we can also install
> the ORT RPM we created. However, astat installation failed.
> - We tried to install ATS 6.2.1 downloaded from the ATS download page
> <http://trafficserver.apache.org/downloads>. However, the ORT script
> failed to pull configuration, as the "ATS RPM" was not installed.
>
>
> We decided to move on and test the rest of the system, forcing the
> configured servers to be "ONLINE" (this will bite us later on).
> At that point, we approached the HHTTP delivery service via the tr (wget
> http://tr....).
> We expected to be redirected to the (non-existing) caches, however, we
> were redirected to the "bypass" URL.
> Looking at the TR access.log, we saw that reason for moving to the bypass
> was "DS_CLIENT_GEO_UNSUPPORTED", even-though there were no geo restrictions
> set to the DS.
> The traffic_router.log shows that the traffic-router fails to download the
> geolocation data-base from http://${toHostname}/MaxMind/a
> uto/GeoIP2-City.mmdb.gz, this is for 2 reasons:
> 1. The "${toHostname} " is not being replaced with the actual Ops
> host-name.
> 2. Even when replacing the variable with the actual host-name, the "
> MaxMind/auto/GeoIP2-City.mmdb.gz" path does not exists. We replaced it
> with "routing/GeoLite2-City.mmdb.gz"
> Similar issues were found for the federations and coverage-zone file
> JIRA created:
> TC-527 <https://issues.apache.org/jira/browse/TC-527> - Traffic_Router
> Default Profile - Uses unsupported pattern (${toHostname})
> TC-528 <https://issues.apache.org/jira/browse/TC-528> - Traffic Router -
> To support the ${toHostname} pattern when parsing the cr-config
> TC-529 <https://issues.apache.org/jira/browse/TC-529> -
> <https://issues.apache.org/jira/browse/TC-529>TRAFFIC_ROUTER default
> profile points to non existing geolocation DB endpoint
> TC-530 <https://issues.apache.org/jira/browse/TC-530> - TRAFFIC_ROUTER
> default profile points to non existing coverage-zone DB endpoint
>
>
> Initial adjustments of the TRAFFIC_ROUTER profile had no effect, as the TM
> did not pull the new cr-config.
> TM log indicated the reason:  "No REPORTED caches exist in Traffic Ops,
> nothing to poll." (a reminder: edge and mid servers exist, but are force
> to be ONLINE and not "REPORTED").
> We moved the "mid" server to REPORTED, restarted the monitor, and finally
> got our redirect.
> TC-531 <https://issues.apache.org/jira/browse/TC-531> -  Traffic Monitor
> does not pull new cr-config when all servers in in "ONLINE" and not
> "REPORTED"
>
>
> Finally we connected the new Traffic-Portal to the TC.
> Note that currently there is an issue installing nodejs on Centos7 server,
> as the http-parser RPM was removed from epel. See additional info
> <https://bugs.centos.org/view.php?id=13669&nbn=1> and JIRA open by
> Jeremy: TC-521 <https://issues.apache.org/jira/browse/TC-521> -  TPv2 -
> http-parser dependency cannot be resolved
> '
> One the portal was up, it made a great impression!!! we are now starting
> to "play" with it.
> Note that initially the login to the server failed. The issue was resolved
> once we opened the firewall from the Ops server to the Portal (Portal to
> Ops was already open).
>
> I hope this would help others installing TC 2.1.
>
> Nir
>