apache
TP: User is able to assign physical location that is not related to Cache group lat and long for a server.
Component: Traffic Portal UI
Release Info: Version: 3.0.0-10037.0a958899.el7 Build Date: 2019-06-18 23:00:02OURCE API URL: https://localhost/api/
Page: Server Create/update Available under configure->servers click on Plus (Create new) or open any existing server
Fields: Phys Location * Cache Group *
These fields are not linked within traffic portal, although it is meant to indicate the real physical location of the server.
Discrepancy arises when the lat and long co-ordinates of Cache Group doesn't match with the physical location provided This could be done intentionally or unintentionally.
Suggestion: if we logically, technically n geographically connect the cache group to physical location - this human error could be eliminated. As a result, the need for user to select physical location can be dropped.
unfortunately, i don't think a CG can have ONE physical location because the caches in which its comprised of can exist (and typically do) exist in many physical locations (although normally somewhat close to each other). so i'm pretty sure a cache needs it's own physical location assignment.
a cache group has coordinates (lat/long) so TR knows where to send a request. In very simple terms, TR uses the lat/long of the requesting client (as determined by the client's ip + the coverage zone file) to send the request to a cache that exists in the closest cache group.
anyhow, long story short, as it is now:
- a cache needs a phys location (so if there's a problem, a tech knows where the cache physically exists so it can be repaired, removed, decommissioned, etc?
- a cache group needs coordinates so TR can send requests to the nearest caches and uses the cache group to determine this.
to your point, it seems weird that you can put a cache in a cache group that has a west coast lat/long for example and also put an east coast phys location on that same cache.....but, one thing about TC...it's VERY flexible and maybe somebody would want to do that?? :)
I could potentially see the argument of adding lat/long to phys location (and doing some enforcement there to ensure address and lat/long make sense) which as a result would add a lat/long to each cache and removing lat/long from cache group but that would require a much bigger discussion.
@lbathina @mitchell852 It sounds like we don't need Phys Location/Cache Group coordinate parity valiation. Can #3703 be closed?
