[RESULT] [VOTE] Resolution for Traffic Control graduation to TLP

[Dave Neuman]

Hi All,
This vote has passed with 9 binding +1 votes and 0 -1 votes.  Thanks to all
who voted, I will work on submitting our resolution to the IPMC!

--Dave

On Thu, Apr 12, 2018 at 2:30 PM, David Neuman 
wrote:

> Thanks to everyone for voting.  It has been plenty of time so I am calling
> this vote.  I will send a resolution shortly.
> Thanks!
> Dave
>
> On Wed, Apr 4, 2018 at 9:01 AM, Jeremy Mitchell 
> wrote:
>
>> +1
>>
>> Jeremy
>>
>> On Mon, Apr 2, 2018 at 10:28 PM, Jason Tucker 
>> wrote:
>>
>> > +1
>> >
>> > On Tue, Apr 3, 2018 at 2:58 AM, John Rushford 
>> > wrote:
>> >
>> > > +1
>> > >
>> > > > On Apr 2, 2018, at 7:07 PM, Eric Friedrich (efriedri) <
>> > > efrie...@cisco.com> 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/fb1fae0785feb6568cef6de
>> b6fa207
>> > > 23eba54ed63a445462d44564d3@%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

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

[David Neuman]

Thanks to everyone for voting.  It has been plenty of time so I am calling
this vote.  I will send a resolution shortly.
Thanks!
Dave

On Wed, Apr 4, 2018 at 9:01 AM, Jeremy Mitchell 
wrote:

> +1
>
> Jeremy
>
> On Mon, Apr 2, 2018 at 10:28 PM, Jason Tucker 
> wrote:
>
> > +1
> >
> > On Tue, Apr 3, 2018 at 2:58 AM, John Rushford 
> > wrote:
> >
> > > +1
> > >
> > > > On Apr 2, 2018, at 7:07 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> 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/fb1fae0785feb6568cef6deb6fa207
> > > 23eba54ed63a445462d44564d3@%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 

Re: Updated TO API guidelines

[Jeremy Mitchell]

@dave - you're right. the PR referenced above did not update version, docs
or tests.

re: version - these were very new endpoints. i simply rewrote it to follow
the new api guidelines. i think the risk of doing that was low as TP is the
only consumer of this endpoint.
re: docs - docs for 1.3 endpoints haven't been written. we're going to
depend on swagger for that. right dewayne?
re: tests - yep, i failed to update the existing tests and broke them and
submitted this subsequent PR -
https://github.com/apache/incubator-trafficcontrol/pull/2106

@rawlin -

i agree. i'd love to dump support for the `?(.json) ` suffix. seems
redundant. i would suggest that any new GET routes don't include it.

On Mon, Apr 9, 2018 at 12:02 PM, Rawlin Peters 
wrote:

> Thanks for the example, Jeremy. Do we have any guidelines about
> whether or not the `?(.json) ` suffix should be supported for new API
> endpoints? It seems pointless because the API will always return JSON.
>
> - Rawlin
>
> On Fri, Apr 6, 2018 at 3:14 PM, Jeremy Mitchell 
> 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 
> > wrote:
> >
> >> 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 us "API Use Cases" to think about with these
> >> new
> >> > TO API Guidelines.  The main goal for these changes are to build TO
> API's
> >> > that are intuitive.  I'm of the opinion that if the API's are
> intuitive
> >> > (with easy to understand patterns) that prevents me from wasting time
> >> > looking up API docs.  A nice side effect of having simple standards
> and
> >> > patterns is that simplicity ripples into our API Go code which allows
> us
> >> to
> >> > easily build frameworks that do all of the work instead of the API
> >> > snowflakes that we have today.
> >> >
> >> > I encourage everyone to shoot as many holes into our thoughts around
> this
> >> > new direction so that we can see the bigger picture.
> >> >
> >> > -Dew
> >> >
> >> > On Wed, Apr 4, 2018 at 10:29 PM, John Rushford 
> >> wrote:
> >> >
> >> >> 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