t;> >> groups is stored as a List. It's currently loaded by
> iterating
> >> >> the elements of the json array in order. That looks great to me.
> >> >>
> >> >> It seems odd to me to have a separate order parameter in the API.
> >&g
t looks great to me.
>> >>
>> >> It seems odd to me to have a separate order parameter in the API.
>> >> Since order has to be unique, it's unlikely that you'd be able to
>> >> update the order component to do anything other than "mov
ove to an end"
> >> without updating about half the rows in the db anyway. It just feels
> >> like we're asking more of the API user.
> >>
> >> On Mon, Mar 19, 2018 at 2:04 PM, Chris Lemmons
> wrote:
> >>> Moving a
7;s unlikely that you'd be able to
> >> update the order component to do anything other than "move to an end"
> >> without updating about half the rows in the db anyway. It just feels
> >> like we're asking more of the API user.
> >>
> >
the order component to do anything other than "move to an end"
>> without updating about half the rows in the db anyway. It just feels
>> like we're asking more of the API user.
>>
>> On Mon, Mar 19, 2018 at 2:04 PM, Chris Lemmons wrote:
>>> Moving
anyway. It just feels
> like we're asking more of the API user.
>
> On Mon, Mar 19, 2018 at 2:04 PM, Chris Lemmons wrote:
>> Moving a conversation started in Slack to the mailing list:
>>
>> VijayAnand [8:06 AM]
>> Hi
>>
>> This is regarding TR
Moving a conversation started in Slack to the mailing list:
>
> VijayAnand [8:06 AM]
> Hi
>
> This is regarding TR's Backup Cache Group Selection
> which is https://github.com/apache/incubator-trafficcontrol/issues/1907
> GitHub
> Deterministic Cachegroup failover · I
Moving a conversation started in Slack to the mailing list:
VijayAnand [8:06 AM]
Hi
This is regarding TR's Backup Cache Group Selection
which is https://github.com/apache/incubator-trafficcontrol/issues/1907
GitHub
Deterministic Cachegroup failover · Issue #1907 ·
apache/incubator-trafficco
As another thought, maybe we should take advantage of https://postgis.net/
and figure out how to flip CZF into it.
-Dew
On Tue, Mar 13, 2018 at 10:05 AM, David Neuman
wrote:
> What happens when Geo Limit is set to "CZF Only" with all backup Caches
> are unavailable and fallbackToClosest is set
We should also have some uniqueness constraints on the new table
{primary, fallback} and {primary, order}.
—Eric
> On Mar 13, 2018, at 12:59 PM, Rawlin Peters wrote:
>
> To clarify, if we got a hit in the CZF for the client's IP, then we
> should *not* fail when all specified backup CGs are
To clarify, if we got a hit in the CZF for the client's IP, then we
should *not* fail when all specified backup CGs are unavailable,
fallbackToClosest is set to True, and the DS is set to "CZF only". In
that case we should find the closest available CG (and fail if there
are none). If your current
What happens when Geo Limit is set to "CZF Only" with all backup Caches
are unavailable and fallbackToClosest is set to True. Current
implementation will fail this. Should we do Geo lookup now in this change?
In this case we should fail. If the Geo Limit is set to “CZF Only” then
that is all we u
@Rawlin,
Let me try and get the changes done for TR according to your suggestions.
This change would be like:
1. CZF only contains cache groups which should map back to TO's Cache Group
configurations (cr-config)
2. Backup configurations should reach TR via cr-config in the format you
detailed.
3.
If we start by putting this in the Cache Group API first, then later
we really only have to worry about adding the CIDRs to the API. The
backup config is really just relationships between cache groups, which
makes perfect sense to model in a relational DB rather than the CZF.
Why put something in t
Good point Rawlin, but I think it does answer your questions. CZF for now,
whatever the new CZF thing is after that.
On Mon, Mar 12, 2018 at 1:44 PM, Rawlin Peters
wrote:
> The original scope of this thread was determining where the Backup
> Cache Group config should live (API vs CZF), not nece
The original scope of this thread was determining where the Backup
Cache Group config should live (API vs CZF), not necessarily about
building the entire CZF in the database, although I'm +1 on that idea
as well. I think any decisions made about doing that should probably
be started in a separate t
+1 on building the CZF in the database. Jan tried to go down that rabbit
hole but realized it was a pretty hard problem to solve. I think this is
something we might want to re-visit. Maybe this is something we should
discuss at our meetup and then update this thread with our decisions?
On Mon,
@VijayAnand:
Right, a Coverage Zone that doesn't map to a Cache Group in TO won't
be chosen as a backup in case of failure, but you could have a
Coverage-Zone-not-in-TO that configures Coverage-Zones-in-TO as
backups. But, I think the general sentiment right now is that all
Coverage Zones in the C
Eric, I agree with this as well, maybe we build separate API's for
"loading" CZF formats (or any other types of external data) into the same
area of the data model (however that ultimately looks). If we keep the CZF
data centralized it'll be easier to build relationships if needed.
-Dew
On Mon,
Rawlin,
I believe the following statement is not correct.
However, after reading your initial proposal below, it sounds like you
might have Coverage Zones in your CZF that don't necessarily map back
to Cache Groups in TO. Might that be the case?
We can have Coverage Zones in CZF which donâ
Good point. I think it makes sense to move both the backupList and coordinates
into the CG API. By move coordinates into the API, I’m implying that we
consolidate into 1 set of coordinates per CG. The existing CG coordinates would
now be used for both backup edge CG selection and initial edge cg
So in your CZF example, we can't actually have two CZs using the same
name ("a"), because when that JSON gets parsed one of the CZs will be
overwritten so that there is only one "a" key in the JSON. The names
would have to be "a1" and "a2" for instance and backupList [a, b, c]
and [a, c, b], but I
"I can't imagine why we'd ever want the two sets of coordinates to differ for
the same Cache Group. “
Maybe someone else can chime in about why coordinates were added to the CZF in
the first place, but I’ve also thought of them like this:
CG API Coordinates - Where the cache servers are. To be us
Ok, so the coordinates in the CZF are only used when no available
cache is found in the matched cachegroup. Rather than using the
coordinates of the matched cachegroup that it already knows about from
the API, Traffic Router uses the coordinates from the CZF cachegroup
instead. That seems...not gre
I think the original reason for putting it in the CZF was to stay consistent
with the coordinates backup logic which is also in the CZF.
Unless you have multiple “coordinates” for different networks in the same zone,
would it also make sense to add the coordinates to the Cache Group API as well
Hey Eric (and others),
I'm resurrecting this thread because the PR [1] implementing this
proposed functionality is just about ready to be merged. The full
mailing list discussion can be read here [2] if interested.
I've discussed this PR a bit more with my colleagues here at Comcast,
and while it
t/long.
Thanks,
John
---Original---
From: "Jeff Elsloo "
Date: 2017/3/29 22:45:12
To:
"dev@trafficcontrol.incubator.apache.org";
Subject: Re: Backup Cache Group Selection
Yes, it's expected behavior. What you're describing sounds like a
cachegroup in the CZF without any c
aches deployed to 50% of the
>> >>>> cache groups defined in the CZF. Would we want to use the Geolocation
>> >>>> provider in the event that our source address matches a cachegroup
>> >>>> that does not have any assigned caches? We would ideally have a
n about which cachegroup should service the request instead of
> >>>> falling back to a lower fidelity datasource. This is especially true
> >>>> in the case of RFC 1918 addresses that might appear in one's CZF.
> >>>>
> >>>> Thanks,
> >
;
>>>>
>>>> On Wed, Mar 29, 2017 at 9:12 AM, John Shen (weifensh)
>>>> wrote:
>>>>> Hi Jeff,
>>>>>
>>>>> Thank you for the detail. I am wondering why there are two sets of
>>>> lat/lang,
>>>&g
re two sets of
>>> lat/lang,
>>>> i.e. one in CZF, the other is in Ops GUI Cache Group setting. To
>>> calculate
>>>> the closest CG when matched CG in CZF is not available, the source
>>> lat/long
>>>> is from mathced CZF, and the dest lat/long is
> >
> > > Since there are two sets of lat/long in TR, can we just use the
> lat/long
> > all
> > > from Ops CG settings to get the closest, and do not care about the
> values
> > > set in CZF? At least this will avoid inconsistent config for l
t this will avoid inconsistent config for lat/long.
> >
> > Thanks,
> > John
> >
> > ---Original---
> > From: "Jeff Elsloo "
> > Date: 2017/3/29 22:45:12
> > To:
> > "dev@trafficcontrol.incuba
nsistent config for lat/long.
> >
> > Thanks,
> > John
> >
> > ---Original---
> > From: "Jeff Elsloo "
> > Date: 2017/3/29 22:45:12
> > To:
> > "dev@trafficcontrol.incubator.apache.org" apache.org>;
> > Subject: Re: Backup Ca
oid inconsistent config for lat/long.
>
> Thanks,
> John
>
> ---Original---
> From: "Jeff Elsloo "
> Date: 2017/3/29 22:45:12
> To:
> "dev@trafficcontrol.incubator.apache.org";
> Subject: Re: Backup Cache Group Selection
>
> Yes, it
for lat/long.
Thanks,
John
---Original---
From: "Jeff Elsloo "
Date: 2017/3/29 22:45:12
To:
"dev@trafficcontrol.incubator.apache.org";
Subject: Re: Backup Cache Group Selection
Yes, it's expected behavior. What you're describing sounds like a
cachegroup in the
Yes, it's expected behavior. What you're describing sounds like a
cachegroup in the CZF without any corresponding configuration in
Traffic Ops, or a cachegroup with configuration in Traffic Ops, but
with no available caches (DS assignments, health, etc).
Presuming we have configured geolocation co
Hi Jeff,
I have just tried the getClosestCacheLocation() logic. It appears the CZF
matched lat/long does come from CZF, but the lat/long of the “closest” Cache
Groups is from the configuration by Ops. This means to calculate the distance
from the matched CG and “closest” CG, the source lat/long
Steve: I don't think the patch is required, however, as Eric found,
without the patch there could be some gaps depending on the scenario.
That specific scenario revolved around the "next best cache group" not
having a DS assigned, or a healthy cache with the DS assigned. In that
case, despite the h
The rloc field usually indicates the Geolocation IP of the client (short for
request location)
But here it looks like rloc is reflecting the location of the CG it ultimately
redirected to (response location?).
I would have expected the rloc field to either
1) be blank (because we never did
Jeff,
CZF properly installed: yes
Network address or not: same behavior
But you nailed the API one. There is no cache assigned to us-ga-macon,
which is exactly what I'm testing.
I added cache groups for my testing in the lab which I assigned a few
caches to them :
- us-ga-atlanta 34.0362 -84.32
Dave just let me know that in this case you don't have any caches
assigned in us-ga-macon. I'm not sure how the API behaves at that
point – it likely won't follow the same "next best cache group" logic,
as it was designed as a simple lookup tool.
Can you try simulating a request through Traffic Ro
Are you 100% sure that the Traffic Router has loaded the updated CZF?
If so, what happens when you use an IP within the /20 instead of the
network address (.0)? I tried using a network address of a /22 on a
1.8 TR and it hit the CZF as expected. Ultimately what you're seeing
is a CZF miss, unrelate
Jeff,
I've tried this coverage zone file coordinate overwrite... I might be
missing something.
I defined the following :
"us-ga-macon": {
> "coordinates": {
> "latitude": "32.7261",
> "longitude": "-83.6547"
> },
> "netw
Yes; the feature went into 1.5.x.
--
Thanks,
Jeff
On Thu, Jan 19, 2017 at 10:37 AM, Steve Malenfant wrote:
> I didn't know about this which is good information. Does that work on
> Traffic Router 1.6?
>
> On Mon, Jan 9, 2017 at 12:44 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
I didn't know about this which is good information. Does that work on
Traffic Router 1.6?
On Mon, Jan 9, 2017 at 12:44 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:
> Jeff and I had a quick Slack convo, so I’ll add a followup summary here in
> case anyone else is interested.
>
> Cach
Jeff and I had a quick Slack convo, so I’ll add a followup summary here in case
anyone else is interested.
Cache Group location (lat/long) is configured in Traffic Ops today (and is used
for computing distance from Maxmind Geolocation).
You can also configure the location (lat/long) for a Cach
Eric,
We've got a new requirement here which I've found this tool (untested) that
might solve some of your problem.
https://github.com/maxmind/MaxMind-DB-Writer-perl
One might want to include their subnets into MaxMind DB instead of CZF.
This can include location, Country Codes, etc...
Hope tha
If we applied the proposed change, given your scenario we should fall
through to the return statement that calls getClosestCacheLocation().
That method will order all cache groups based on their lat/long and
the lat/long of the cache group we hit on in the CZF. Once the list is
ordered, we iterate
Where would TR look outside the assigned cache group to find the next closest
cache group?
> On Jan 4, 2017, at 11:25 AM, Eric Friedrich (efriedri)
> wrote:
>
>
> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo
> mailto:jeff.els...@gmail.com>> wrote:
>
> Hey Eric,
>
> It sounds like the use case y
networkNode.getLoc() returns the name of the cache group in the CZF
that the IP falls under.
--
Thanks,
Jeff
On Wed, Jan 4, 2017 at 9:25 AM, Eric Friedrich (efriedri)
wrote:
>
> On Jan 3, 2017, at 5:20 PM, Jeff Elsloo
> mailto:jeff.els...@gmail.com>> wrote:
>
> Hey Eric,
>
> It sounds like the
On Jan 3, 2017, at 5:20 PM, Jeff Elsloo
mailto:jeff.els...@gmail.com>> wrote:
Hey Eric,
It sounds like the use case you're after is an RFC 1918 client
associated with a cache group whose caches are all unavailable for one
reason or another. Is that correct?
Yes, exactly.
I looked at the code
Hey Eric,
It sounds like the use case you're after is an RFC 1918 client
associated with a cache group whose caches are all unavailable for one
reason or another. Is that correct?
I looked at the code a bit, and I think that we can make a minor
change to achieve the behavior you're looking for as
If all caches in the primary cache group are unavailable, our goal is to
provide a backup routing policy for RFC1918 clients.
When client IP is an public Internet IP, the current backup policy is to assign
the client to the geographically closest cache (Distance = MaxMind Geo Lat/Long
- config
Hi Eric,
How does the backup list relate to the RFC1918-is-not-in-geo problem?
To get to a cachegroup you need to get a match in the coverage zone, I would
think?
Rgds,
JvD
> On Dec 22, 2016, at 12:28, Eric Friedrich (efriedri)
> wrote:
>
> The current behavior of cache group selection work
The current behavior of cache group selection works as follows
1) Look for a subnet match in CZF
2) Use MaxMind/Neustar for GeoLocation based on client IP. Choose closest cache
group.
3) Use Delivery Service Geo-Miss Lat/Long. Choose closest cache group.
For deployments where IP addressing is pr
56 matches
Mail list logo
