Re: Traffic Router Enhancement - Default Maxmind Geolocation Override

2018-02-21 Thread Jeff Elsloo 
Unless there are objections, I will be merging this PR (#1866) in the
near future. Please speak up now if you have any concerns.
--
Thanks,
Jeff


On Mon, Feb 19, 2018 at 10:24 AM, Rivas, Jesse  wrote:
> Nir,
>
> I'm not familiar with the behavior of other geo DBs concerning default 
> locations, but as long as there are distinct conditions where we can 
> determine that a response is a default, we can expand this enhancement in the 
> future to work with other DBs as well.
>
> -Jesse
>
> On 2/19/18, 7:11 AM, "Nir Sopher"  wrote:
>
> Are you familiar with the behavior of other ip to geo DBs?
> Anyway +1 from me.
> I would also be happy to review and merge.
> Nir
>
> On Feb 16, 2018 18:22, "Rivas, Jesse"  wrote:
>
> > If there are no objections to the proposed enhancement for a MaxMind
> > override location on a per country, per CDN basis, then I will move 
> forward
> > with the changes and work with a committer to get the PR merged.
> >
> > -Jesse
> >
> > On 2/15/18, 8:37 AM, "Eric Friedrich (efriedri)" 
> > wrote:
> >
> > Sounds great, thanks!
> >
> > > On Feb 15, 2018, at 10:33 AM, Rivas, Jesse 
> 
> > wrote:
> > >
> > > Eric,
> > >
> > > We can determine a response from MaxMind is a default location 
> when
> > the following conditions are met: the country code is populated, the 
> city
> > is null, the postal code is null, and the subdivisions list is empty. If
> > these conditions are met, we check for an instance of
> > maxmind.default.override with the same country code. This allows users 
> to
> > have one MaxMind override per country, per CDN.
> > >
> > > -Jesse
> > >
> > > On 2/15/18, 6:04 AM, "Eric Friedrich (efriedri)" 
> 
> > wrote:
> > >
> > >How does the suggested fix know when maxmind is returning a
> > “default location” versus an actual location?
> > >
> > >Hopefully the solution is applicable to CDNs which are spread
> > across multiple countries and geographies?
> > >
> > >—Eric
> > >
> > >> On Feb 13, 2018, at 1:34 PM, Rawlin Peters 
> 
> > wrote:
> > >>
> > >> Yeah, this basically solves the problem where MaxMind knows a 
> client
> > >> is in the US (or another country) but doesn't know the state, 
> city,
> > >> zip, etc., so it's not a "true" miss. In that case MaxMind 
> returns
> > the
> > >> geographic center of that country as the client's location, but 
> we
> > >> don't want to route those clients to the cache group closest to 
> that
> > >> location because it might not be the ideal cachegroup. By using 
> this
> > >> parameter we can shift this high volume of "US" traffic that is
> > >> essentially being localized to a lake in Kansas to a cachegroup 
> more
> > >> capable of handling that load. And we can do this on a 
> per-country
> > >> basis because we can create multiple of these parameters (which 
> we
> > >> wouldn't be able to do if we just used the Default Miss Lat/Lon 
> of a
> > >> DeliveryService).
> > >>
> > >> -Rawlin
> > >>
> > >> On Tue, Feb 13, 2018 at 11:10 AM, Rivas, Jesse <
> > jesse_ri...@comcast.com> wrote:
> > >>> Steve,
> > >>>
> > >>> Using the miss location for the DS was a potential solution that
> > we talked about. However, the miss location is intended for use when the
> > client IP falls through MaxMind without any data. Since the default
> > location doesn't fit this criteria, it was decided to use a profile
> > parameter to preserve granularity.
> > >>>
> > >>> Jesse
> > >>>
> > >>> On 2/13/18, 11:06 AM, "Steve Malenfant" 
> > wrote:
> > >>>
> > >>>   Jesse,
> > >>>
> > >>>   I'm not exactly sure how MaxMind return this default value but
> > would there
> > >>>   be a way to use the MISS location specified in the DS? Seems
> > like that is
> > >>>   what it was intended for.
> > >>>
> > >>>   Steve
> > >>>
> > >>>   On Tue, Feb 13, 2018 at 12:42 PM, Rivas, Jesse <
> > jesse_ri...@comcast.com>
> > >>>   wrote:
> > >>>
> >  Hi all,
> > 
> > 
> > 
> >  At Comcast, we have been seeing a pattern of the same cache 
> group
> > being
> >  overloaded nightly as traffic increases on the CDN. The cause 
> was
> >  determined to be a default location that the geolocation 
> provider
> > MaxMind
> >  returns for client IPs that it does not have additional data 
> for.
> > For the
> >  US, MaxMind returns a geolocation with the coordinates:
> > 37.751,-97.82

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

2018-02-21 Thread Steve Malenfant 
+1

Upgraded the following succesfully to RC1:
Traffic Ops
Traffic Portal
Traffic Monitor (from java to golang)
Traffic Router
Traffic Stats

I only opened a single issue related with some required parameter for
Traffic Monitor. But if used according to the default RASCAL profiles, no
problem. Logs are specific. Issue is #1902.

Steve

On Wed, Feb 14, 2018 at 4:01 PM, Robert Butts  wrote:

> Hello All,
>
> I've prepared a release for v2.2.0-RC1
>
> The vote is open for at least 72 hours and passes if a majority of at least
> 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.1.0:
> https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-2.1.0...RELEASE-2.2.0-RC1
>
> This corresponds to git:
>  Hash: ea549797d98c4fe96e484c9e88f82e2d7f876c1e
>  Tag: RELEASE-2.2.0-RC1
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC1
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC1
>
>
> Thanks!
>

Re: Traffic Ops API Swagger Doc

2018-02-21 Thread Dewayne Richardson 
I mentioned a week ago if we should use Swagger for documenting the API
(with my example findings).  Since I have seen no -1's the plan is to move
forward with Swagger and only document the Golang Proxy routes (1.3), the
Perl routes will still use the existing 1.2 API docs.

In terms of how we integrate with our existing doc the hope is to generate
a new traffic-ops-api-1.3.rst file for the 1.3 api docs and hook into the
mainline docs accordingly.

Thanks,

-Dew

On Tue, Feb 20, 2018 at 10:50 AM, Jeremy Mitchell 
wrote:

> Eric, are you saying you never want to write RST anymore? me neither. yuck!
>
> On Tue, Feb 20, 2018 at 9:57 AM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > Is it possible to take the swagger generated documentation and have that
> > automatically included in the read-the-docs site?
> >
> > Asked another way: Can swagger generate docs in ReStructed Text (.rst)
> > format?
> >
> > —Eric
> >
> >
> > > On Feb 20, 2018, at 11:38 AM, Dave Neuman  wrote:
> > >
> > > Sounds good.  I look forward to seeing it merged into our repo.
> > > I guess this means there will need to be a PR to remove our current API
> > > docs as they get moved to swagger.
> > >
> > > On Tue, Feb 20, 2018 at 8:40 AM, Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > >> I think this all sounds very promising. Some advantages that I see
> are:
> > >>
> > >> - docs never drift from API implementation (currently our docs get out
> > of
> > >> sync real fast)
> > >> - this provides yet another interface -
> > >> https://app.swaggerhub.com/apis/dewrich/traffic-ops_api/1.3 -  (in
> > >> addition
> > >> to TP) to interact with the API
> > >> - a great way to demonstrate / educate developers on the capabilities
> of
> > >> the api
> > >>
> > >> plus, i heard some bonus features that could be really interesting:
> > >>
> > >> - auto generation of a TO golang client. can we deprecate the old TO
> > client
> > >> in favor of an auto-generated one? The current TO client never seems
> to
> > >> stay in sync with the api
> > >> - generating server stubs
> > >>
> > >> imo our api can never be fully auto-generated because of the business
> > logic
> > >> that needs to be accounted forbut it would be pretty neat if all
> we
> > had
> > >> to do was "define" the api in a yaml file and that yaml file would
> spit
> > out
> > >> documentation, tests, clients (be it golang or java or whatever), and
> > >> server side code (stubs) and then all we could focus on writing code
> > >> specific to business logic.
> > >>
> > >> my guess is to really do this right, we'd have to rev the api version
> to
> > >> 2.0 to make the api more swagger friendly...tools (swagger) like
> > >> consistency and our api is far from consistent...
> > >>
> > >> jeremy
> > >>
> > >> On Wed, Feb 14, 2018 at 10:08 AM, Durfey, Ryan <
> ryan_dur...@comcast.com
> > >
> > >> wrote:
> > >>
> > >>> I am +1 on the swagger concept.  This makes working with APIs much
> > easier
> > >>> for non-developer staff and makes it easier to educate customers as
> > well.
> > >>>
> > >>> Ryan DurfeyM | 303-524-5099
> > >>> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com > >>> cdn_supp...@comcast.com>
> > >>>
> > >>> From: Dewayne Richardson 
> > >>> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> > >>> dev@trafficcontrol.incubator.apache.org>
> > >>> Date: Wednesday, February 14, 2018 at 9:34 AM
> > >>> To: "dev@trafficcontrol.incubator.apache.org" <
> > >>> dev@trafficcontrol.incubator.apache.org>
> > >>> Subject: Traffic Ops API Swagger Doc
> > >>>
> > >>> We've been working diligently on the TO Golang Rewrite
> > >>> 
> > project
> > >> to
> > >>> obviously rewrite the Perl into Go, but also to improve our Testing
> and
> > >>> Documentation efforts.  I presented the idea of using Swagger several
> > >>> summits (years) ago about using Swagger to help drive our Traffic Ops
> > API
> > >>> documentation.  Since then Swagger has evolved and is becoming the de
> > >> facto
> > >>> standard for building (the potential for generating TO Golang Client
> > and
> > >>> Server stubs is now available) and documenting REST APIs.
> > >>>
> > >>> I would like to propose going forward that we use Swagger for future
> > API
> > >>> level documentation (because it can be generated out of our Golang
> > >>> code/structs).  The below resources point out a TO API version 1.3
> (the
> > >>> version we decided to rev for the rewritten Golang endpoints).  The
> > >> intent
> > >>> behind 1.3 is obviously an improved version of the API (entirely
> > backward
> > >>> compatible to 1.2), but also to give us a starting point for building
> > the
> > >>> API doc in Swagger.
> > >>>
> > >>> The following resources are my examples:
> > >>>
> > >>> Swagger has several implementations and I chose go-swagger
> > >>>  because it has more
> Golang
> > >>>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

2018-02-21 Thread Dave Neuman 
Hi Steve, for the upgrade did you go from 2.1 -> 2.2?

On Wed, Feb 21, 2018 at 10:15 AM, Steve Malenfant 
wrote:

> +1
>
> Upgraded the following succesfully to RC1:
> Traffic Ops
> Traffic Portal
> Traffic Monitor (from java to golang)
> Traffic Router
> Traffic Stats
>
> I only opened a single issue related with some required parameter for
> Traffic Monitor. But if used according to the default RASCAL profiles, no
> problem. Logs are specific. Issue is #1902.
>
> Steve
>
> On Wed, Feb 14, 2018 at 4:01 PM, Robert Butts  wrote:
>
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC1
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/
> > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC1
> >
> > This corresponds to git:
> >  Hash: ea549797d98c4fe96e484c9e88f82e2d7f876c1e
> >  Tag: RELEASE-2.2.0-RC1
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC1
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F&op=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC1
> >
> >
> > Thanks!
> >
>