Re: Traffic Ops go client responses

reak people. I propose we add new functions, e.g. `CreateTenantNullable`, > and mark the existing functions as deprecated, and remove them in the next > major version. > > > On Thu, Apr 26, 2018 at 12:02 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> Digging a

Re: Traffic Ops go client responses

implementing the new client like this? - Rawlin On Thu, Apr 26, 2018 at 11:11 AM, Rawlin Peters <rawlin.pet...@gmail.com> wrote: > If you've found some Perl endpoints that aren't returning the modified > record, I think that's definitely a bug, and there should be GitHub > issues fi

Re: Traffic Ops go client responses

modified record. You have to do a Get to verify that > the change occurred. > > Andy > > On 4/25/18, 3:53 PM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote: > > Hey folks, > > I noticed in our TO go client that we aren't decoding the JSON >

Traffic Ops go client responses

Hey folks, I noticed in our TO go client that we aren't decoding the JSON response returned from PUT/POST endpoints. If we actually decoded those responses, it would be quicker and more useful from a user's perspective, save bandwidth from all the unnecessary GETs after POST/PUTs, and also reduce

Re: Updated TO API guidelines

wrote: > Rawlin, > > I have submitted a PR to change some new ds request routes to utilize query > params instead of path/route params (the legacy format): > > https://github.com/apache/incubator-trafficcontrol/pull/2094 > > On Fri, Apr 6, 2018 at 11:59 AM, Rawlin Peters <

Re: Updated TO API guidelines

Do we currently have an example of an API endpoint written in the traffic_ops_golang framework that uses only query parameters like this? How would it compare to the legacy format? -Rawlin On Thu, Apr 5, 2018 at 9:45 AM, Dewayne Richardson wrote: > Thank you John for giving

Re: Delivery Service Origin Refactor

18, at 12:27 PM, Rawlin Peters <rawlin.pet...@gmail.com> wrote: >> >> This Origin Refactor proposal was probably too much to parse at once. >> Here's a slightly shorter version: >> 1. Split Locations out of the Cachegroup table into their own table > EF> Location

Re: Delivery Service Origin Refactor

implementation would continue to use origins created using the Server table, but we would transition the MSO implementation over to using the new Origin table eventually. Questions/thoughts/concerns about any of this? All feedback is welcome. Thanks, Rawlin On Mon, Mar 12, 2018 at 1:46 PM, Rawlin Peters

Re: Backup Cache Group Selection API Format

ary_cg, set_order) >> ); >> >> ALTER TABLE cachegroup ADD COLUMN fallback_to_closest BOOLEAN DEFAULT TRUE; >> Would like to get your views before i start coding for the same >> >> Eric Friedrich [8:15 AM] >> why does the set_order get a default? >> >>

Re: Delivery Service Origin Refactor

etween targets on the fly for things like maintenance, capacity differences, beta testing, etc. - Rawlin > > —Eric > > > > > >> On Mar 14, 2018, at 11:45 AM, Rawlin Peters <rawlin.pet...@gmail.com> wrote: >> >> Yes, I'd say that's essentially the main

Re: Delivery Service Origin Refactor

client location for choosing the origin practically ignores the > accurate information provided by the CZF. It's a combination of the client location, the edge location, and the origin location (total distance from client -> edge -> origin). > > What am I missing? > 10x

Re: Backup Cache Group Selection

implementation will fail this. Should we do Geo lookup now in this change? >> >> Shall i delete my existing PR and create a new one with these changes? >> >> I will try to get the necessary changes for TO (Perl Mojo) along with this. >> Would require your help in TO (Golan

Re: Backup Cache Group Selection

in the CZF to just tear it out later? - Rawlin On Mon, Mar 12, 2018 at 3:12 PM, Dave Neuman <neu...@apache.org> wrote: > 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

Re: Delivery Service Origin Refactor

ation into consideration? > Why the target DSes have different origins in the first place? Are they > have different characteristics additionally to their location? > Thanks, > Nir > > -- Forwarded message -- > From: Rawlin Peters <rawlin.pet...@gmail.com

Delivery Service Origin Refactor

Hey folks, As promised, this email thread will be to discuss how to best associate an Origin Latitude/Longitude with a Delivery Service, primarily so that steering targets can be ordered/sent to the client based upon the location of those targets (i.e. the Origin), a.k.a. Steering Target

Re: Backup Cache Group Selection

e-visit. Maybe this is something we should > discuss at our meetup and then update this thread with our decisions? > > On Mon, Mar 12, 2018 at 11:25 AM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> @VijayAnand: >> >> Right, a Coverage Zone that doesn't map

Re: Backup Cache Group Selection

GROUP3"],? This wont be chosen as backup Cache Group in case > of failure , since it is not in crconfig. > "fallbackToClosestGroup":false >}, > "network6": [ > "1234:5677::\/64", > "1234:5676::\/64" >

Re: Backup Cache Group Selection

; on their specific subnet they have different backup policies. > > Our particular requirement for this feature is a backup at the CacheGroup > level, not the CZ level as I’ve shown here- so perhaps we’re overbuilding it. > > —Eric > > > > > >> On Mar 9, 201

Re: Backup Cache Group Selection

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

Re: Steering Target Geo-Ordering

target with the shortest [client -> edge] distance. This is a more difficult task than just sorting by distance between the client and origin, but it takes into account the fact that the most optimal cachegroups might not be available. - Rawlin On Wed, Feb 28, 2018 at 11:02 AM, Rawlin Peters &l

Re: Steering Target Geo-Ordering

e edge cache, rather than proximity of client to origin. Since the client > is talking to the edge cache and not the origin, this seems like a better > metric. Being able to compose Steering DS would also give us more flexibility > for other use cases in the future as well > > >

Re: Steering Target Geo-Ordering

Are all 3DS’ assigned to all 3 Cache Groups? > > I’ll also assume that the content on the origins, while interchangeable from > a clients perspective, is not identical? (i.e. might contain regionalized > content?) > > —Eric > > > > >> On Feb 23, 2018, at 5:40 P

Re: Steering Target Geo-Ordering

many targets would you > have? What would the type of each target be and what would the value of > each target be? > > Jeremy > > > On Fri, Feb 23, 2018 at 3:40 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> Hey folks, >> >&g

Steering Target Geo-Ordering

Hey folks, At Comcast we have a need to augment CLIENT_STEERING (also regular STEERING while we're at it) to allow targets to be ordered/sorted based upon the client's proximity to the origin of the target delivery services. I'd like to get your feedback on my proposed design and address any of

Re: Traffic Router Enhancement - Default Maxmind Geolocation Override

? > Taking TR localization into account, it might give better granularity. > > Nir > > On Tue, Feb 13, 2018 at 8:34 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > > > Yeah, this basically solves the problem where MaxMind knows a client >

Re: [VOTE] CHANGELOG.md file (second try)

I think you can go ahead and create one. > > Thanks, > Dave > > On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> Hey all, >> >> So it appears this vote passed in favor of adding a CHANGELOG.md file >> without

Re: [VOTE] CHANGELOG.md file (second try)

Hey all, So it appears this vote passed in favor of adding a CHANGELOG.md file without having a changelog label in GitHub. Is anyone currently working on one? With the 2.2 release planned for 2/12/18, I'd like to at least put in some upgrade release notes about Per-Delivery-Service Routing

Re: Delivery Service Self-Service

Replies inline On Fri, Feb 2, 2018 at 1:43 PM, Jeremy Mitchell wrote: > 2. Manage DS regexes > > Here's an explanation of this: > http://traffic-control-cdn.readthedocs.io/en/latest/admin/traffic_ops/using.html#delivery-service-regexp > > Currently, this requires the

Re: [VOTE] CHANGELOG.md file (second try)

I think a "changelog" label is alright, but ideally I think individual developers should apply their own discretion and edit the CHANGELOG.md as part of their PR if they feel like it needs an entry. It might be easier to write meaningful entries when it's still fresh in your mind rather than 3-6

Re: Courtesy notice: per-Delivery-Service Routing Names

ade. Is there a different parameter to > used for the DNS delivery services migration? > > Thanks, > > Steve > > On Fri, Sep 15, 2017 at 5:19 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> Hey folks, >> >> A new feature for Delivery Services

Re: Delivery Service Properties

I'm not a big fan of the ANY_MAP type DeliveryService. This is from the documentation (basically the only information about this type): """ ANY_MAP is not known to Traffic Router. For this deliveryservice, the “Raw remap text” field in the input form will be used as the remap line on the cache.

Re: TR redirects HTTPS requests to Bypass FQDN with port 80 ???

Replies inline On Thu, Nov 2, 2017 at 2:13 AM, Oren Shemesh wrote: > Hi Eric, Rawlin > > (Good to talk to you ! :-) > > Like I wrote, the problem with just fixing the UI (Or using the API, or the > new portal) is that the same DS can be used for both HTTP and HTTPS. > So as long

Re: TR redirects HTTPS requests to Bypass FQDN with port 80 ???

Hi Oren, Looking at the code in traffic_ops, it looks like at one point in time you could append a `:` in the HTTP bypass FQDN field, and `UI::Topology::gen_crconfig_json()` would split it and do the right thing. My guess is that the field validation was added later (i.e. must be a valid

Re: Geolimit Redirect URL

Hi Mike, I haven't had much experience using/testing that feature, so I can't speak with 100% certainty about it. However, what I do know is that field reappears in the Add Delivery Service page when you select an HTTP* content routing type and then choose an option other than 'None' in the 'Geo

Re: Building Traffic-Router - Failed to bring jdnssec-tools

PM, Mark Torluemke <mtorlue...@apache.org> wrote: > I think we should be resilient and try both address families...curl might > even do this 'for free' if we enable retries. > > On Tue, Oct 3, 2017 at 3:21 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >

Re: Building Traffic-Router - Failed to bring jdnssec-tools

It's possible that Docker isn't playing nicely with IPv6 in your build environment. The RPM build script is curling http://www.verisignlabs.com/jdnssec-tools/packages/old-releases/jdnssec-tools-0.12.tar.gz, and in your case is using the record for some reason. My guess is that the container

Courtesy notice: per-Delivery-Service Routing Names

Hey folks, A new feature for Delivery Services has been merged into master recently - per-Delivery-Service Routing Names [1] - and will end up in release 2.2. Just so you're not surprised next time you upgrade your environments, you will now see a "Routing Name" field when creating or editing a