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 <hbea...@apache.org> 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) <j...@apache.org>
> Reply-To:       dev@trafficcontrol.incubator.apache.org
> To:     iss...@trafficcontrol.incubator.apache.org
>
>
>
>      [ 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)
>
>

Reply via email to