github.com/lukasheimann/cloudfoundrycli@v7.1.0+incompatible/doc/adr/0008-swap-traffic-controller-for-log-cache.md (about)

     1  # 8. Swap Traffic Controller for Log Cache
     2  
     3  Date: 2020-04-09
     4  
     5  ## Status
     6  
     7  Accepted
     8  
     9  ## Context
    10  
    11  _The issue motivating this decision, and any context that influences or constrains the decision._
    12  
    13  The Loggregator team decided to move to a ["Shared
    14  Nothing" architecture](https://docs.google.com/document/d/1_Ve4wAkeCC0fIJ1TiAWSfxzNp5zB_Ndoq5UmfUNJtgs/edit?usp=sharing)
    15  that would improve scalability of log egress from the platform. This architecture deprecated the V1 Firehose Traffic Controller,
    16  the component from which the cf CLI retrieved application logs. As a result, the Loggregator team proposed modifying the cf CLI to retrieve
    17  logs from Log Cache instead.
    18  
    19  ## Decision
    20  
    21  _The change that we're proposing or have agreed to implement._
    22  
    23  After December 2019, the CLI's minimum supported version of cf-deployment contains Log Cache. Therefore, in 2020:
    24  
    25  * cf CLI v7 will be modified to retrieve application logs from Log Cache
    26  * cf CLI v6 will be modified to retrieve application logs from Log Cache _with the exception of experimental v3-prefixed commands_
    27  * cf CLI v6/v7 legacy command implementations accessible through the Plugin API
    28    will be modified to retrieve application logs from Log Cache
    29  
    30  There will be no user-facing or breaking changes.
    31  
    32  ## Consequences
    33  
    34  _What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated._
    35  
    36  * Cloud Foundry log egress is expected to become more scalable and resource
    37    efficient
    38  * We will be limited in our ability to modify the Log Cache API by our minimum
    39    supported version [policy](https://github.com/cloudfoundry/cli/wiki/Versioning-Policy).
    40  * The Traffic Controller V1 implementation was based on a long-lived Websocket
    41    connection. Log Cache requires the client to make GET requests to an HTTP API
    42    to retrieve application logs.
    43  * The log envelopes for an application are grouped together into
    44    source-id "buckets". This poses the risk that logs may be shown for a different
    45    operation than that being performed by the user.
    46  * Authorization for log retrieval would previously need to be done once when
    47    establishing a long-lived connection for streaming logs. It must now be
    48    performed for each request made when "walking" Log Cache.
    49  * Log Cache may perform caching of authorized source-ids. Users that push a
    50    number of applications in quick succession may be unable to retrieve logs.