Re: Updated TO API guidelines

[John Rushford]

Why the change?  It’s my understanding that path parameters should be used to 
specify a particular resource
and query parameters should be used to sort/filter the query.  Why use a query 
parameter to specify a particular
resource?  Is this REST API best practice?

What about sub resource queries such as using the following:

GET api/1.3/deliveryservices/{xmlID}/urisigning

where you are requesting a particular urisigning keys sub resource for the 
particular deliveryservice resource. You can make it work
with an xmlid query parameter but what do you return if the query parameter is 
left off, all uri signing keys?  Is that useful?

John

> On Apr 4, 2018, at 3:23 PM, Jeremy Mitchell  wrote:
> 
> tbh i'm not sure about versioning. I was just trying to suggest that new
> routes be formulated this way per the new API guidelines:
> 
> GET /foos[?id, name, etc=]
> POST /foos
> PUT /foos [?id, name, etc=]
> DELETE /foos [?id, name, etc=]
> 
> instead of the old way:
> 
> GET /foos
> GET /foos/:id
> POST /foos
> PUT /foos/:id
> DELETE /foos/:id
> 
> The difference being the use of query params over route/path params.
> 
> Technically, adding new routes does not break old stuff right so i don't
> think that warrants a major version roll.
> 
> While we're on the subject, what does everyone think if we took this one
> step further and made routes handle a request payload with one or more
> items. For example:
> 
> GET /foos[?id, name, etc=]
> POST /foos <-- takes in an array of foos to create
> PUT /foos <-- takes in an array of foos to update
> DELETE /foos <-- takes in an array of foos to delete
> 
> in this scenario, query params only pertain to the GET. The POST, PUT and
> DELETE rely on the contents of the request json...
> 
> Jeremy
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 4, 2018 at 1:55 PM, Robert Butts 
> wrote:
> 
>> That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
>> 
>> Just to clarify, changing to query parameters breaks compatibility with 1.2
>> and older, so new APIs in that format have to be a new major version, i.e.
>> 2.0, per Semantic Versioning, right?
>> 
>> On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell 
>> wrote:
>> 
>>> FYI - I've updated the TO API guidelines to reflect our desire to move
>> away
>>> from route/path params and embrace query params in the Golang API.
>>> 
>>> https://cwiki.apache.org/confluence/display/TC/API+Guidelines
>>> 
>>> Jeremy
>>> 
>> 

Re: [VOTE] Resolution for Traffic Control graduation to TLP

[John Rushford]

+1

> On Apr 2, 2018, at 7:07 PM, Eric Friedrich (efriedri)  
> wrote:
> 
> +1
>> On Apr 2, 2018, at 4:11 PM, David Neuman  wrote:
>> 
>> Dear Traffic Control community members:
>> 
>> I would like to call a vote on the resolution for Traffic Control to
>> graduate from to an Apache TLP.  We have already voted on whether or not we
>> should start the graduation process [1] and this is the next step.  Please
>> see the resolution below and vote as follows:
>> 
>> [ ] +1 Graduate Traffic Control from the incubator
>> [ ] +0 No Opinion
>> [ ] -1 Do not graduate Traffic Control from the incubator (please provide a
>> reason)
>> 
>> The vote is open for a minimum of 72 hours and will need at least 3 more +1
>> votes than -1 votes from PMC members to succeed.
>> 
>> If this VOTE succeeds, a similar VOTE will be started on the
>> gene...@incubator.apache.org mailing list. If that VOTE succeeds, a
>> resolution will be included in the next Apache Board Meeting.
>> 
>> Please feel free to reach out with any questions.
>> 
>> Thanks,
>> Dave
>> 
>> [1]
>> https://lists.apache.org/thread.html/fb1fae0785feb6568cef6deb6fa20723eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E
>> 
>> -
>> 
>> Establish the Apache Traffic Control Project
>> 
>> WHEREAS, the Board of Directors deems it to be in the best interests of
>> the Foundation and consistent with the Foundation's purpose to establish
>> a Project Management Committee charged with the creation and maintenance
>> of open-source software, for distribution at no charge to the public,
>> related to building, monitoring, configuring, and provisioning a large
>> scale content delivery network (CDN)..
>> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
>> (PMC), to be known as the "Apache Traffic Control Project", be and
>> hereby is established pursuant to Bylaws of the Foundation; and be it
>> further
>> 
>> RESOLVED, that the Apache Traffic Control Project be and hereby is
>> responsible for the creation and maintenance of software related to
>> building, monitoring, configuring, and provisioning a large scale
>> content delivery network (CDN).; and be it further
>> 
>> RESOLVED, that the office of "Vice President, Apache Traffic Control" be
>> and hereby is created, the person holding such office to serve at the
>> direction of the Board of Directors as the chair of the Apache Traffic
>> Control Project, and to have primary responsibility for management of
>> the projects within the scope of responsibility of the Apache Traffic
>> Control Project; and be it further
>> 
>> RESOLVED, that the persons listed immediately below be and hereby are
>> appointed to serve as the initial members of the Apache Traffic Control
>> Project:
>> 
>> * Dan Kirkwood   
>> * David Neuman   
>> * Dewayne Richardson 
>> * Eric Covener   
>> * Eric Friedrich 
>> * Hank Beatty
>> * Jan van Doorn  
>> * Jeff Elsloo
>> * Jeremy Mitchell
>> * Leif Hedstrom  
>> * Mark Torluemke 
>> * Phil Sorber
>> * Steve Malenfant
>> 
>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Neuman be appointed
>> to the office of Vice President, Apache Traffic Control, to serve in
>> accordance with and subject to the direction of the Board of Directors
>> and the Bylaws of the Foundation until death, resignation, retirement,
>> removal or disqualification, or until a successor is appointed; and be
>> it further
>> 
>> RESOLVED, that the initial Apache Traffic Control PMC be and hereby is
>> tasked with the creation of a set of bylaws intended to encourage open
>> development and increased participation in the Apache Traffic Control
>> Project; and be it further
>> 
>> RESOLVED, that the Apache Traffic Control Project be and hereby is
>> tasked with the migration and rationalization of the Apache Incubator
>> Traffic Control podling; and be it further
>> 
>> RESOLVED, that all responsibilities pertaining to the Apache Incubator
>> Traffic Control podling encumbered upon the Apache Incubator PMC are
>> hereafter discharged.
> 

Re: [VOTE] Traffic Control graduation to TLP

[John Rushford]

+1

> On Mar 1, 2018, at 9:20 PM, Jeremy Mitchell  wrote:
> 
> +1
> 
> On Thu, Mar 1, 2018 at 2:06 PM, Nir Sopher  wrote:
> 
>> +1
>> 
>> On Mar 1, 2018 10:27 PM, "Steve Malenfant"  wrote:
>> 
>>> +1
>>> 
>>> On Thu, Mar 1, 2018 at 12:14 PM, Phil Sorber  wrote:
>>> 
 +1
 
 On Thu, Mar 1, 2018 at 1:12 PM Hank Beatty  wrote:
 
> +1
> 
> On 03/01/2018 10:41 AM, Dave Neuman wrote:
>>  Hey All,
>> 
>> After a great discussion amongst the Apache Traffic Control PPMC,
> reviewing
>> the graduation checklist[1], updating the podling status page[2],
>> and
>> updating the project website to ensure the whimsy podling website
 checks
>> pass[3], I would like to call a vote for Apache Traffic Control
> graduating
>> to a top level project.
>> 
>> Apache Traffic Control entered the incubator on July 12, 2016.
>> Since
> then
>> we have announced 4 releases, nominated 4 new committers,
>> organized 3
>> summits, had almost 8,000 commits from 63 different contributors,
>> and
 --
>> most importantly -- we have grown and diversified our community.
 Apache
>> Traffic Control is a healthy project that is already acting like an
> Apache
>> top level project, so we should take the next step.
>> 
>> If we agree that we should graduate to a top level project, the
>> next
> steps
>> will be to pick the initial PMC chair for the TLP and draft a
 Resolution
>> for the PPMC and IPMC to vote upon.
>> 
>> Please take a minute to vote on wheter or not Traffic Control
>> should
>> graduate to a Top Level Project by responding with one of the
 following:
>> 
>> [ ] +1 Apache Traffic Control should graduate.
>> [ ] +0 No opinion
>> [ ] -1 Apache Traffic Control should not graduate (please provide
>> the
>> reason)
>> 
>> The VOTE will be opened for at least the next 72 hours.  Per Apache
>> guidelines[4] I will also be notifying the incubator mailing list
>>> that
 a
>> community vote is under way.
>> 
>> Thanks,
>> Dave
>> 
>> 
>> [1]
>> 
> https://incubator.apache.org/guides/graduation.html#
 graduation_check_list
>> [2] http://incubator.apache.org/projects/trafficcontrol.html
>> [3] https://whimsy.apache.org/pods/project/trafficcontrol
>> [4]
>> 
> https://incubator.apache.org/guides/graduation.html#
 community_graduation_vote
>> 
> 
 
>>> 
>> 

Re: Golang Proxy Validation Dependencies

[John Rushford]

+1

Sent from my iPad

> On Jan 16, 2018, at 2:07 PM, Dave Neuman  wrote:
> 
> +1
> 
>> On Tue, Jan 16, 2018 at 12:58 Jan van Doorn  wrote:
>> 
>> +1 on using libs.
>> 
>>> On Jan 16, 2018, at 10:52 AM, Dan Kirkwood  wrote:
>>> 
>>> +1 -- agree with Jeff -- the validation of the fields of
>>> deliveryservice is something that is incomplete in the Perl
>>> traffic_ops.
>>> 
>>> These libraries make for concise code to do the validation so it will
>>> be easier to extend without much extra code.   It will not be called
>>> on every API function,  but only once on each POST/PUT which are a
>>> small minority of calls.   It also need not be used in every case.
>>> That, to me,  makes the reflection argument much less of a concern.
>>> 
>>> I would like to see it go in sooner than Friday,  but won't argue that
>> point..
>>> 
>>> -dan
>>> 
>>> 
>>> On Tue, Jan 16, 2018 at 10:10 AM, Dewayne Richardson 
>> wrote:
 So, it's been a few days on this topic and I'd like to call a vote for
>> the
 dependencies listed in this thread.  Please vote +1 or -1 by Noon
>> Friday so
 that we can move forward the Golang Proxy development.
 
 Thanks,
 
 -Dew
 
 On Thu, Jan 11, 2018 at 10:53 AM, Jeff Elsloo 
>> wrote:
 
> I don't think we should assume anything about the performance just
> because it uses reflection. Yes, traditionally reflection is
> computationally expensive, however, when used properly the penalty can
> be negligible. I don't think we have enough understanding of these
> libraries to know whether there is a concerning performance penalty.
> 
> As Dewayne said, create, update and delete actions represent a tiny
> fraction of the overall requests into TO. Given that the majority of
> these actions are performed by humans, I would be shocked if there was
> a perceptible performance difference with the reflection based
> validation in place. It's not like we're trying to validate enormous
> and complex objects here; we're talking 20 fields or so for any given
> post.
> 
> I'm +1 on using validation libraries such as these even if they use
> reflection, provided that we do not see dramatic changes in
> performance. I think that's highly unlikely in this case.
> --
> Thanks,
> Jeff
> 
> 
> On Thu, Jan 11, 2018 at 10:07 AM, Chris Lemmons 
> wrote:
>> True, but how many of those out-of-the-box checks are both useful and
>> relevantly complex?
>> 
>> To me, the cool part of ozzo is the way it collects the output and
>> formats it. That's unfortunately also the computationally expensive
>> part.
>> 
>> On Thu, Jan 11, 2018 at 9:49 AM, Dewayne Richardson <
>> dewr...@gmail.com>
> wrote:
>>> Please keep in mind that we do not Create/Update/Delete very often in
>>> Traffic Ops, so the performance penalty for Validation should be
>> taken
> into
>>> consideration.  I also don't want to re-invent all of those
> out-of-the-box
>>> field level checks by hand when I can just use them from here:
>>> https://github.com/asaskevich/govalidator#list-of-functions
>>> 
>>> -Dew
>>> 
>>> On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons 
> wrote:
>>> 
 I like the output style, but I'm a bit concerned on the performance
 front. ozzo appears to do all it's magic with heavy use of
>> reflection,
 which is often a slow spot in go. Most places, it wouldn't matter
 much, but this will be called on every element of every API
>> function,
 so a nod toward performance may be in order. Have we done some
 measurement to see whether this adds a relevant amount of overhead
>> to
 the calls? Or are the calls still dominated by the DB lookup?
 
 Relatedly, is this a major advantage over something like this:
 
 if ds.Active == nil { errMsgs = append(errMsgs, `"active" must be
 provided`) }
 
 On Thu, Jan 11, 2018 at 8:49 AM, Dewayne Richardson <
> dewr...@apache.org>
 wrote:
> We've been moving along with more functionality in the Golang
>> proxy,
 mostly
> the Read's up until now, comparatively TO does much fewer
> Create/Updates.
> Our current task is to circle back and start implementing the
> (C)reate,
> (U)pdate, and (D)eletes.  One of the obvious needs for the this
>> task
> are
> validation rules.  I've been doing research to figure out the
> cleanest
 and
> most maintainable way to rewrite the Perl validation rules in Go.
> 
> TC Issue for tracking
> https://github.com/apache/incubator-trafficcontrol/issues/1756
> 
> These are the two dependencies I'd 

Re: New Committer - Rob Butts

[John Rushford]

Congratulations Rob!

Sent from my iPhone

> On Aug 10, 2017, at 6:59 AM, Dave Neuman  wrote:
> 
> Congratulations, Rob!
> 
>> On Thu, Aug 10, 2017 at 5:26 AM, Eric Friedrich  wrote:
>> 
>> The Project Management Committee (PMC) for Apache Traffic Control
>> (incubating)
>> has invited Rob Butts to become a committer and we are pleased
>> to announce that he has accepted.
>> 
>> Rob began his Traffic Control contributions in November of 2015. Rob's
>> contributions are wide ranging from Dockerization and build processes, to
>> experimental Traffic Ops and most importantly the GoLang evolution of
>> Traffic Monitor. Rob is active within the community, participating in
>> mailing list threads and presenting at ApacheCon summits.
>> 
>> Being a committer enables easier contribution to the
>> project since there is no need to go via the patch
>> submission process. This should enable better productivity.
>> Being a PMC member enables assistance with the management
>> and to guide the direction of the project.
>> 

Re: [VOTE] Move Traffic Control to full GitHub

[John Rushford]

+1


On 5/19/17 7:41 AM, Dremin, Sergey wrote:

+1

On 5/18/17, 2:32 PM, "Jan van Doorn"  wrote:

 In
 
https://lists.apache.org/thread.html/5bdb9b073343f49c1d5b85147eb9d260bf7ad15d61384929993c7e1d@%3Cdev.trafficcontrol.apache.org%3E
 Dave
 mentioned that we can now move to "full" GitHub. Some more information in
 that thread if you are not familiar. I would like to call an official vote
 on that.
 
 This vote will be open for at least 72 hours.
 
  [ ] +1 Move Traffic Control to use full GitHub

  [ ]  0 No opinion
  [ ] -1 Do not Move Traffic Control to use full GitHub because...
 
 Rgds,

 JvD