To my knowledge it has not been fixed and will not be fixed for 2.1. On Thu, Aug 10, 2017 at 8:09 AM, Hank Beatty <[email protected]> wrote:
> Does anyone know if this has been fixed? If not, are we planning in fixing > it for 2.1? > > Thanks, > Hank > > > > > -------- Forwarded Message -------- > Subject: [jira] [Updated] (TC-118) Traffic Ops should get it's name > from some confioguration when generating CrConfig > Date: Wed, 14 Jun 2017 19:00:01 +0000 (UTC) > From: Ryan Durfey (JIRA) <[email protected]> > Reply-To: [email protected] > To: [email protected] > > > > [ https://issues.apache.org/jira/browse/TC-118?page=com.atlass > ian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Ryan Durfey updated TC-118: > --------------------------- > Labels: configuration crconfig (was: ) > > Traffic Ops should get it's name from some confioguration when generating >> CrConfig >> ------------------------------------------------------------ >> ---------------------- >> >> Key: TC-118 >> URL: https://issues.apache.org/jira/browse/TC-118 >> Project: Traffic Control >> Issue Type: Bug >> Components: Traffic Ops >> Affects Versions: 1.7.0 >> Reporter: Oren Shemesh >> Priority: Minor >> Labels: configuration, crconfig >> >> The code that generates the CrConfig has a problem when creating the >> "stat" section. >> It fills values for that section, such as "tm_host", based on the HTTP >> headers found in the request that triggered the CrConfig snapshot: >> Here is a snippet from traffic_ops/app/lib/UI/Topology.pm: >> $data_obj->{'stats'}->{'tm_path'} = $self->req->url->path->{'path' >> }; >> $data_obj->{'stats'}->{'tm_host'} = $self->req->headers->host; >> I find this to be a problem for two reasons: >> This code assumes that it is being run from the context of an HTTP >> transaction, which to me sounds like contaminating the logic of actually >> creating the CrConfig with details from the upper layer which currently >> uses this logic. For example, if one would want to run this code from a >> different path (Maybe in a unit test), it would be a problem. >> If the traffic ops is accessed through a NAT, then the host name known to >> the HTTP client issuing the 'Snapshot CrConfig' request is not necessarily >> the same as the traffic ops host name known to the other components of the >> system, e.g. the traffic router that uses this information. >> (This is how I found out about this problem - we are experimenting with >> deploying TC in the cloud (Amazon EC2) and the host name visible to the >> outside world is not the same as the host names used internally) >> I believe that tm_host should come from the database (Currently there is >> no entry from the traffic ops itself, but such an entry can be created for >> this purpose), or from cdn.conf. >> > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) > >
