You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2020/12/19 00:03:04 UTC

[GitHub] [trafficcontrol] rawlinp opened a new issue #5391: TO/TP unable to create types where use_in_table = cachegroup

rawlinp opened a new issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391


   ## I'm submitting a ...
   -  bug report
   
   ## Traffic Control components affected ...
   -  Traffic Ops
   - Traffic Portal
   
   ## Current behavior:
   TO only allows creating new types where `use_in_table = server`.
   
   ## Expected behavior:
   TO only allows creating new types where `use_in_table = server` OR `use_in_table = cachegroup`.
   
   Since we allow creating new server types, it follows that we should probably be able to create new cachegroup types that match those server types. For Flexible Topologies, there might be more types than just `MID`/`MID_LOC` that we'd want to define and use in a topology.
   
   ## Minimal reproduction of the problem with instructions:
   In TP, go to `https://<your TP host>/#!/types/new`, observe that you are only able to create types where `use_in_table = server`.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rawlinp commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rawlinp commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754139602


   If the origin is http://example.org, I would imagine something like this if we used reverse all the way through:
   
   edge.myds.mycdn.com -> remap to mid-1.myds.mycdn.com -> remap to last-tier-cache-1.myds.mycdn.com -> remap to example.org
   
   If we did that, I'd think all of those FQDNs would need to be in DNS. Do you mean we could reverse all the way without that? What would the remaps be? Unless you mean just requiring an "identity" remap for caches past the edge tier -- e.g. example.org -> example.org?
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rob05c edited a comment on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rob05c edited a comment on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754162467

I'm suggesting we configure the Caching Proxy to get a request for the DS FQDN, say `edge.myds.mycdn.com`, and then make a request to its parent, say `mymid.example` with the `Host: edge.mydns.mycdn.com`. The Caching Proxy `mymid.example` will then get that request, and either request its own parent or directly to the real origin.

ATS config would look like
```
map http://ds1.cdn.example http://ds1.cdn.example
dest_domain=ds1.cdn.example parent="mid.cdn.example:80" parent_is_proxy=false
```

No DNS changes, no additional hosts in DNS. I guess we could do it that way, but I agree that would add unnecessary complexity.

These requests would all use regular HTTP requests, rather than any of several Proxy protocols, which are more difficult to debug in production than ordinary HTTP.

I call that a Reverse Proxy, because it's hiding the origin from the client. I guess you could call it a Forward since it's also arguably hiding the client. Regardless what we call it, the important part is that we're avoiding difficult-to-debug CONNECT protocols.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rob05c commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rob05c commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754127145


   I'm not sure what you mean? You mean we'd have to put those FQDNs in DNS? We shouldn't, and can't, the Host header being requested of the RP will have to be the origin's host, the Proxy can't be in DNS with that host.
   
   Or you mean something else? I don't think it introduces any complexity, it should be as simple as changing to `parent_is_proxy=false` in `parent.config`, maybe a couple other tiny changes. Unless I'm missing something?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rob05c commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rob05c commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754162467

ATS config would look like
```
map http://ds1.cdn.example http://ds1.cdn.example
dest_domain=ds1.cdn.example parent="mid.cdn.example:80" parent_is_proxy=false
```

No DNS changes, no additional hosts in DNS. I guess we could do it that way, but I agree that would add unnecessary complexity.

These requests would all use regular HTTP requests, rather than any of several Proxy protocols, which are more difficult to debug in production than ordinary HTTP.

I call that a Reverse Proxy, because it's proxying the Origin and hiding the client. I guess you could call it a Forward since it's also arguably hiding the client. Regardless what we call it, the important part is that we're avoiding difficult-to-debug CONNECT protocols.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rob05c commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rob05c commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754086690


   Any caching Proxy can easily be both Forward and Reverse, depending on the particular request. 
   
   Right now, ATC is basically hard-coded so Edges are RP and Mids are FP. But there's no reason a server couldn't act as a FP for one Delivery Service and RP another. Or, that a server couldn't be a RP in one particular Topology and a FP in another.
   
   I'd vote we move toward making that more flexible, rather than continuing to hard-code it or forcing servers to make all requests as a single type.
   
   Alternatively, I believe it would be a good idea to always do Reverse Proxy (i.e. normal) requests for all requests. IMO the gain of Forward Proxying is negligible, and the complexity and increased difficulty of debugging isn't worth it. It might be worth putting that on the mailing list, and seeing if anyone has a valid use case for ever needing FP, and if not, simplifying ATC to always be RP.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] ocket8888 commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

ocket8888 commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-748416429


   What if instead we didn't allow types to be mutable at all? That way we could really reliably determine the type of something from its Type.
   
   I really think the current use-cases for custom types are better served by applying Tags to something.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rob05c commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rob05c commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754216919


   +1
   
   The other part of this, besides "simply prod debugging," is "simplify TO/TC."
   
   If we don't decide to do the RP-everywhere thing, or we could also say "the first Cache (Edge) in the Topology is Reverse, every other is a Forward" (which is what it does today, with the way I wrote the Topology Config Gen, though it's easy to change).
   
   I'm not seeing a reason ATC needs to specify that. 
   
   Unless some user has a specific need to say "do Forward Proxy requests for this DS/Cache and Reverse for this other one," I'd vote we just remove that concept from ATC, to make ATC/TO/TP simpler. So all caches are just "CACHE" type or whatever, no more Edge/Mid/Reverse/Forward type data. And the config gen just does the right thing.
   
   I'm having a hard time thinking why anyone would need to do that. If not, it makes ATC/TO/TP easier to use.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rawlinp commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rawlinp commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754078267

Ideally, we'd have a way to distinguish whether a server is a forward proxy or a reverse proxy other than by checking its server type prefix (EDGE/MID). That has always been a brittle way of determining that, maybe even a lazy hack to avoid adding a new database column or something. It really seems like there are two types at hand -- server type and proxy type. Right now we are conflating server type with both of those distinct types. Maybe we need to add a proxy type column to the server table, options being `REV/FWD/NONE`?

For cachegroup types, I'm not sure there is much code (other than topology validation and a little MSO stuff) that actually checks the type of a cachegroup. So if we fix topology validation somehow to not depend on cachegroup type names for determining whether or not a cachegroup can be a leaf node, etc., we should be able to create and use new cachegroup types in topologies.

It kind of seems like we'd need a proxy type column on the cachegroup _and_ the server, so we could validate that forward proxy cachegroups aren't leaf nodes. However, maybe a cache can just depend on its cachegroup for the proxy type rather than having the type in both the cachegroup and the server, but that seems kind of weird too.

Maybe the MID/EDGE prefix checking is so built in at this point that we should just continue depending on it, and fix topology validation to check for EDGE/MID/ORG prefixes in the cachegroup type instead of the full type names. Then we could allow creating and using cachegroup types with those prefixes in topologies with all the proper validation.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rawlinp commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rawlinp commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754096999


   That is a good point -- a cache can be both a forward and a reverse proxy.
   
   If we went all reverse proxy, that would mean every cache would require a unique fqdn for every delivery service at each tier. That would add a significant amount of complexity into the system.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] mitchell852 commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

mitchell852 commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-752238998


   I'm pretty sure the reason we limited new types to use_in_table = server is because you can add server types that begin with Edge* or Mid* and they'd _just work_ w/o code changes. So really it should have been "you can only add create types where use_in_table = server AND prefix = EDGE or MID".
   
   I guess my question is if we allow users to create types of use_in_table = cachegroup, will these types _just work_ w/o code changes and if not, should we really allow them to create something that won't even work?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rawlinp commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rawlinp commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-751771559


   Maybe, but we don't have tags today, and that would be quite the paradigm change to entirely depend upon tags instead of types.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [trafficcontrol] rawlinp commented on issue #5391: TO/TP unable to create types where use_in_table = cachegroup

Posted by GitBox <gi...@apache.org>.

rawlinp commented on issue #5391:
URL: https://github.com/apache/trafficcontrol/issues/5391#issuecomment-754207573


   Oh ok. I agree that approach as you've described it wouldn't increase complexity much.
   
   Circling back to this issue, it sounds like we should just continue to rely on the EDGE/MID prefixes to mean reverse/forward, respectively, in order to not prevent us from making this change in the future. If that change is made, we might need a different approach to the validation in order to prevent certain cachegroups from being leaf nodes in the topology. Maybe the right abstraction there is whether or not we want the cachegroup to be open to the Internet. Cachegroups that aren't open to the Internet shouldn't be leaf nodes in a topology.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org