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

[David Neuman]

+1
Checked hashes
Ran `pkg` to build the RPMs
Installed Traffic Ops
Ran postinstall

On Tue, May 1, 2018 at 1:13 PM, Robert Butts  wrote:

> Hello All,
>
> I've prepared a release for v2.2.0-RC5
>
> 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-RC5
>
> This corresponds to git:
>  Hash: 3dec97f5577514e8ea21c26959562afdb0297245
>  Tag: RELEASE-2.2.0-RC5
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC5
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=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/RC5
>
>
> Thanks!
>

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 <mitchell...@apache.org>
wrote:

> +1
>
> Jeremy
>
> On Mon, Apr 2, 2018 at 10:28 PM, Jason Tucker <jasonwtuc...@gmail.com>
> wrote:
>
> > +1
> >
> > On Tue, Apr 3, 2018 at 2:58 AM, John Rushford <jjrushf...@gmail.com>
> > 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 <david.neuma...@gmail.com>
> > > 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   <dang...@apache.org>
> > > >> * David Neuman  

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

[David Neuman]

+1
I tested the following:
- building with the pkg command
- signatures
- checksums (were we supposed to get rid of md5?  I must have missed that)
- installed and started traffic_stats


On Wed, Apr 4, 2018 at 11:04 AM, Robert Butts  wrote:

> Hello All,
>
> I've prepared a release for v2.2.0-RC4
>
> 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-RC4
>
> This corresponds to git:
>  Hash: 45151f8e518fe92dfa64c7311b877cb13299debc
>  Tag: RELEASE-2.2.0-RC4
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC4
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=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), and sha512 checksum are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC4
>
>
>
> Thanks!
>

[VOTE] Resolution for Traffic Control graduation to TLP

[David Neuman]

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   <dang...@apache.org>
 * David Neuman   <neu...@apache.org>
 * Dewayne Richardson <dewr...@apache.org>
 * Eric Covener   <cove...@apache.org>
 * Eric Friedrich <fri...@apache.org>
 * Hank Beatty<hbea...@apache.org>
 * Jan van Doorn  <j...@apache.org>
 * Jeff Elsloo<els...@apache.org>
 * Jeremy Mitchell<mitchell...@apache.org>
 * Leif Hedstrom  <zw...@apache.org>
 * Mark Torluemke <mtorlue...@apache.org>
 * Phil Sorber<sor...@apache.org>
 * Steve Malenfant<smalenf...@apache.org>

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: Question about the poll model of the Traffic Monitor

[David Neuman]

Hi Zhilin,
Is it possible to get this design doc added to our wiki?  I create a design
docs page here (https://cwiki.apache.org/confluence/display/TC/Design+Docs).
I think it would be good to get the document there so it doesn't get lost
over time.

Thanks!
Dave

On Wed, Mar 28, 2018 at 10:41 PM, Zhilin Huang (zhilhuan) <
zhilh...@cisco.com> wrote:

> Hi Guys,
>
> Thanks a lot for the discussion. I should put the design earlier for
> review, and sorry for the delay. Here is the link for the design doc:
> https://docs.google.com/document/d/1vgq-pGNoLLYf7Y3cu5hWu67TUKpN5hucrp
> -ZS9nSsd4/edit?usp=sharing
>
> Short summary for the feature design:
> ---
> There is feature request from market to add secondary IPs support on edge
> cache servers, and the functionality to assign a delivery service to a
> secondary IP of an edge cache.
>
> This feature requires Traffic Ops implementation to support secondary IP
> configuration for edge cache, and delivery service assignment to secondary
> IP.
>
> Traffic Monitor should also monitor connectivity of secondary IPs
> configured. And Traffic Router needs support to resolve streamer FQDN to
> secondary IP assigned in a delivery service.
>
> Traffic Server should record the IP serving client request. And should
> reject request to an unassigned IP for a delivery service.
>
> This design has taken compatibility into consideration: if no secondary IP
> configured, or some parts of the system has not been upgraded to the
> version supports this feature, the traffic will be served by primary IPs as
> before.
> ---
>
> Replies for Robert's comments is embedded in the email thread. Much
> appreciated and welcome to any further comments.
>
> Thanks,
> Zhilin
>
>
>
>
> On 29/03/2018, 10:19 AM, "Neil Hao (nbaoping)" 
> wrote:
>
> Hi Robert/Nir,
>
> Thanks very much for the quick and detail reply, and sorry for that I
> didn’t make the whole feature clearly. Actually, it’s our Secondary IP
> feature, which is a big feature that will bring change to all the
> components in the Traffic Control. I thought our teammate reviewed the
> design with you guys before, but it seems not. And after discussion, we
> will start the whole feature design review with you guys soon, I think it
> will be better to continue the discussion after that.
>
> Thanks,
> Neil
>
> On 3/29/18, 1:16 AM, "Robert Butts"  wrote:
>
> I agree with Nir, it's not as simple as changing a structure to
> `[]URL`,
> it's a bigger architectural design question.
>
> How do you plan to mark caches Unavailable if they're unhealthy on
> one
> interface, but healthy on another?
>
> Right now, Traffic Router needs a boolean for each cache, it
> doesn't know
> anything about multiple network interfaces, IPv4 vs IPv6, etc. It
> only
> knows the FQDN, which is all the clients it's giving DNS records
> to will
> know when they request the cache.
>
> Questions:
> Is a cache marked Unavailable when any interface is unreachable?
> Or all of
> them?
> ZH> Actually, we will care about an IP availability instead of interface
> availability. Please take a look at 3.1.2 of the design doc.
>
> What if an interface is reachable, but one interface reports
> different
> stats than another interface? For example, what if someone
> configures a
> different caching proxy (ATS) on each interface?
> ZH> Will only use 1 ATS to serve traffic from all IPs configured.
>
> How are stats aggregated? Should the monitor aggregate all stats
> from
> different polls and interfaces together, and consider them the same
> "server"? If not, how do we reconcile the different stats with
> what the
> Monitor reports on `CrStates` and `CacheStats`? If so, again, what
> happens
> if different interfaces have different ATS instances, so e.g. the
> byte
> count on one is 100, and the other is 1000, then 101, then 1001.
> It simply
> won't work. Do we handle that? Or just ignore it, and document "all
> interfaces must report the same stats"? Do we try to detect that
> and give a
> useful error or warning?
> ZH> The bandwidth for interfaces will be aggregated. We will only have 1
> ATS to serve traffic from all interfaces. The connectivity check is IP
> based. And the stats collection will be interface based. Please take a look
> at 3.1.2 of the design doc for details.
>
> In Traffic Ops, servers have specific data used for polling.
> Traffic
> Monitor gets the stats URI path from Parameters, and the URI IP
> from the
> Servers table. It doesn't use the FQDN, Server Host or Server
> Domain. Where
> would these other interfaces come from? Parameters? Or another
> table linked
> to the servers table? (I'd really, really rather we didn't put
> more data in
> unsafe Parameters, 

Re: Backup Cache Group Selection

[David Neuman]

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 use.
​

On Tue, Mar 13, 2018 at 8:17 AM, Vijay Anand <
vijayanand.jayaman...@gmail.com> wrote:

> @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. fallbackToClosest will be True by default. If backupLocation config is
> present, it will be assumed as false unless otherwise it is stated as TRUE
> explicitly.
> 4. This will work irrespective of the coverage Zones in CZF as long as the
> backup Cache Group specified is in cr-config.
>
> I have a doubt in this as well.
>
> 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?
>
> 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 (Golang) and TP. Will keep you posted.
>
> Thanks,
> Vijayanand S
>
>
>
>
> On Tue, Mar 13, 2018 at 3:04 AM, Rawlin Peters 
> wrote:
>
> > 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 the CZF to just tear it out later?
> >
> > - Rawlin
> >
> > On Mon, Mar 12, 2018 at 3:12 PM, Dave Neuman  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 PM, Rawlin Peters <
> rawlin.pet...@gmail.com>
> > > wrote:
> > >
> > >> 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 thread.
> > >>
> > >> - Rawlin
> > >>
> > >> On Mon, Mar 12, 2018 at 1:11 PM, Dave Neuman 
> wrote:
> > >> > +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, Mar 12, 2018 at 11:25 AM, Rawlin Peters <
> > rawlin.pet...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> >> @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 CZF should map back to Cache Groups in TO, so
> > >> >> the backup config should also be done via the Cache Group API.
> > >> >>
> > >> >> So from the Traffic Router perspective, the process should become:
> > >> >> 1. Rather than parsing from the CZF into the NetworkNode class,
> parse
> > >> >> Cache Group backup config from the CRConfig into the existing
> > >> >> CacheLocation class
> > >> >> 2. in the DS request flow, the NetworkNode will map back to a
> > >> >> registered CacheLocation which would contain the backup CG config
> > >> >>
> > >> >> The rest of the PR's behavior should stay the same, it's just a
> > matter
> > >> >> of the config being located in a different class. To give you an
> idea
> > >> >> of how I would format it in the CRConfig (so you know how to parse
> it
> > >> >> out), here is a snippet of "edgeLocations" from CRConfig.json:
> > >> >>
> > >> >> "edgeLocations": {
> > >> >> "edge-cg-1": {
> > >> >>   "latitude": 1.00,
> > >> >>   "longitude": 2.00,
> > >> >>   "backupLocations": {
> > >> >>   "list": ["edge-cg-2"],
> > >> >>   "fallbackToClosest": false
> > >> >>   }
> > >> >> },
> > >> >> "edge-cg-2": {
> > >> >>   "latitude": 3.00,
> > >> >>   "longitude": 4.00
> > >> >> },
> > >> >> }
> > >> >>
> > >> >> The "backupLocations" section would still remain optional (if
> > missing,
> > >> >> follow existing 

Re: [VOTE] Traffic Control graduation to TLP

[David Neuman]

Hi All,
I am calling this vote as PASSED!
I will send out a results email shortly, and notify the IPMC.
Please keep an eye out for the next communication which should be a vote on
our resolution.

Thanks,
Dave

On Fri, Mar 2, 2018 at 2:43 PM, Leif Hedstrom  wrote:

> +1
>
> — Leif
>
> > On Mar 1, 2018, at 08:41, 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
>
>

Remove file with invalid license

[David Neuman]

Hey all,
I don't know if you have been following the release 2.1 thread on the
incubator list [1] , but we have been given a -1 vote by the IPMC for
having a file in our release [2] that has an incompatible license.  There
is some debate about the license, and we have reached out to Legal for more
information [3] (thanks Eric!), but we haven't heard back from legal yet.
Instead of waiting for legal to get back to us, I would like to propose
that we instead remove this file from our release.  The file in question is
just a list of weak passwords and I feel like we can easily include a blank
file, or a file with a couple passwords that we generate, and individual
installs of Traffic Control can replace this file as they see fit.  This will
remove issue of having an incompatible license in our release and should
also not require us to do a code change.  The downside of removing this
file is that we will need to create another 2.1 release candidate and go
through the vote process again.  I would really like to see us get 2.1
released before the end of the year, and at this point our chances are
looking pretty slim.  So, does anyone object to removing this file from our
release?  If not, I will put an issue into github, remove the file, and
back port the change so that we can get another 2.1 release candidate out.

Thanks,
Dave


[1]
https://lists.apache.org/thread.html/c211f049e3d68af90196c30f6b6d31a67b3072029dea1efe7d35c9dc@%3Cdev.trafficcontrol.apache.org%3E
[2]
apache-trafficcontrol-2.1.0-incubating/traffic_ops/app/conf/invalid_passwords.txt
[3] https://issues.apache.org/jira/browse/LEGAL-356

Re: ATS

[David Neuman]

Hi Satheesh,
I think that really depends upon your use case and which tier of the CDN
you are asking about.
Are you asking about an Edge Tier or a Mid Tier?  Are you going to be doing
a lot of on-disk caching or do you need more RAM caching?



On Thu, Dec 14, 2017 at 11:51 PM, satheeshsr...@gmail.com <
satheeshsr...@gmail.com> wrote:

> Hi,
>
> Could you pls share me Apache Traffic server Hardware requirement.
>
> Thanks,
> Satheesh R
>

Re: Apache TrafficServer

[David Neuman]

Hey Satheesh,
you might have better luck with the question by asking it to
d...@trafficserver.apache.org or us...@trafficserver.apache.org.  Those are
the ATS mailing lists and they are full of ATS experts.
Thanks!
Dave

On Wed, Dec 6, 2017 at 12:13 AM, satheeshsr...@gmail.com <
satheeshsr...@gmail.com> wrote:

> Dear All,
> I had "@plugin=cache_promote.so @pparam=–policy=lru @pparam=–hits=3
> @pparam=–buckets=1" for my remap config.But cache automatically store
> for the first hit.
> any one suggest me , The correct way to fix it.
>
> Thanks,
> Satheesh R
>

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

[David Neuman]

I have not seen this issue.  It's interesting that it is trying ipv6 for
that.

On Tue, Oct 3, 2017 at 2:33 PM, Nir Sopher  wrote:

> Hi,
>
> Yesterday I tried to build the latest 2.1.x traffic-control, calling the
> ./pkg command.
> The command failed on traffic-router build, and according to the below log,
> it is related to bringing the JDNSSEC tools library, not sure from which
> repository.
>
> Does anybody else encountered a similar issue?
>
> Thanks,
> Nir
>
> Building the rpm.
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
>   0 00 00 0  0  0 --:--:--  0:02:07 --:--:--
>  0curl: (7) Failed to connect to 2620:74:13:4400::201: Network is
> unreachable
> Could not download required jdnssec-tools-0.12 library: 7
>

Re: Traffic Controller on RedHat Servers

[David Neuman]

+1 to what Eric said.  We have and are running ATC on RHEL servers.

On Wed, Sep 13, 2017 at 12:03 PM, Burak Sarp 
wrote:

> Thanks Eric
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, September 13, 2017, 8:49 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> We’ve successfully run Traffic Control on Red Hat Servers. Some of the RPM
> versions are slightly different but there are no major changes required
>
> —Eric
>
> > On Sep 13, 2017, at 1:24 PM, Burak Sarp 
> wrote:
> >
> > Hi all,
> > I know that traffic controller requires Centos,Unfortunately we dont
> have Centos servers, so we are going with RedHat servers.
> > Do you have any experience and comment about that?
> > Thanks,Sarp
>
>
>
>
>

Re: Obsolete Traffic Ops API endpoint removal

[David Neuman]

Hey Rawlin,
I took a look through our splunk logs and it looks like we don't have
anything at Comcast that has hit that endpoint in the last 90 days.
For this reason, I am +1 on removing.

Thanks,
Dave

On Thu, Jul 6, 2017 at 11:27 AM, Robert Butts 
wrote:

> This isn't obsolete, so much as a prototype. It was intended to be "better"
> than the CRConfig and replace it for TR. Much the same way
> `configs/monitoring.json` is the "next generation" endpoint for Traffic
> Monitor (and which is now used in the Golang TM).
>
> That said, as you say, it's incomplete and not currently in use by Traffic
> Control, and probably not useful. I don't have a strong opinion, if you
> want to push for deprecating and removing it. I do have a strong opinion,
> that it should be marked "deprecated" in the next release, and removed in
> the release after, not immediately removed. That should be the normal
> procedure, we should give anyone using Traffic Control a chance to migrate
> before removing things.
>
>
> On Thu, Jul 6, 2017 at 11:14 AM, Peters, Rawlin  >
> wrote:
>
> > Hey all,
> >
> > I believe I’ve found an obsolete/broken API endpoint [1] that might be a
> > good candidate for removal. Here is an example request:
> >
> > GET /api/1.2/cdns/mycdn/configs/routing
> >
> > This will return a json object that looks like the following:
> >
> > {
> > “response”: {
> > “trafficServers”: […],
> > “stats”: {…},
> > “cacheGroups”: […],
> > “config”: {…},
> > “trafficMonitors”: […],
> > “trafficRouters”: […]
> > }
> > }
> >
> > As you might notice, this looks very similar to CRConfig.json except that
> > most of the keys are named differently (e.g. “trafficRouters” vs.
> > “contentRouters”). There is a lot of overlapping information between this
> > and CRConfig which makes me believe that perhaps this API was a precursor
> > to CRConfig that is now obsolete. Further evidence that it’s out-of-date
> > includes (among other things) missing “httpsPort” fields in the objects
> and
> > empty “deliveryServices” arrays for every “trafficServer” object (the
> > arrays shouldn’t be empty if there are delivery services assigned). Also,
> > it seems to be targeted for Traffic Router usage, but Traffic Routers
> > currently pull their CRConfig from Traffic Monitors.
> >
> > The following API endpoints [2][3] seem to provide more up-to-date
> > information via CRConfig and should already replace the outdated endpoint
> > above:
> >
> > GET /api/1.2/cdns/mycdn/snapshot
> > GET /genfiles/view/bycdnname/mycdn/CRConfig.json
> >
> > I propose that we remove this API endpoint [1] unless someone can verify
> > that it’s still in use somewhere (with a good reason to not use a
> CRConfig
> > endpoint instead). I will wait a few days for responses before starting
> on
> > a Pull Request to remove it.
> >
> > Thanks,
> > Rawlin Peters
> >
> > [1] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L469
> > [2] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L439
> > [3] https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L331
> >
> >
>

Re: Update on RFC7871 - Client Subnet in DNS Support

[David Neuman]

+1, excited to see this one come through.

On Fri, Jun 2, 2017 at 12:15 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> We are planning to add support for RFC7871 to Traffic Router. Here is a
> brief description of the feature. Comments appreciated!
>
> Background
>  Clients do not make DNS requests directly to TR. Typically TR requests
> come from DNS resolvers within the infrastructure. Today, Cache Group
> selection for DNS Delivery Services is based on the IP address of the DNS
> resolver making the request to TR. RFC7871 includes the client subnet in an
> EDNS0 option within the DNS query. When the ECS OPT is present (and the
> feature is enabled via a TR parameter), Traffic Router will use this IP in
> place of the source IP of the DNS packet (the IP of the resolver). This IP
> will be used in the CZF and maxmind lookups.
>
> Requirements
>
>   1.  If DNS query includes ECS option in the Optional Record, Traffic
> Router will use the IP address included in the ECS option as the client
> address for Cache Group Selection
>   2.  If there are multiple ECS options in the Optional Record, the one
> with the longest IP prefix - i.e. the ECS option with largest Source Net
> Mask will be used
>   3.  If DNS query includes ECS Option, then DNS response from Traffic
> Router will also include the ECS Option. In the response the Scope Net Mask
> is set to be same as the Source Net Mask. This is required by RFC 7871 for
> DNS caching to work properly.
>   4.  It is assumed that customers/operators will ensure that Source Net
> Mask for a subnet specified in the ECS is at greater than or equal to the
> net mask for the corresponding subnet entry in the CZF file. e.g. if ECS
> Option has 192.168.10.0/8, then 192.168.0.0/16 in CZF will work, but
> 192.168.10./28 will not work.
>   5.  Add a TR parameter to disable use of ECS field even when present
>
> Design
>
> To support this feature new logic will be added to NameServer.query()
> function. The new logic will be responsible for parsing ECS option in the
> OptionalRecord of the incoming DNS Request, and retrieving the Client IP
> address and the associated Source Net Mask (Scope Net Mask must be 0 in the
> incoming Request per RFC 7871). Please note that the underlying DNS library
> xbill/dnsjava already has support for parsing the ECS Options. These
> functions from the library will be leveraged.
>
>   1.  Message.getOPT().getOptions(EDNSOption.Code.CLIENT_SUBNET) will
> return list of ClientSubnetOption for the incoming Request (Message)
>   2.  ClientSubnetOption has public methods to retrieve netmask and Client
> IP address:  getSourceNetmask(), getAddress()
>
> If ECS option is present, then the IP address retrieved from the ECS
> option, and will be passed as the Client IP address to the Traffic Router
> (through getZone call) for CZF/geo lookup
>
> If ECS option is present, then ClientSubnetOption will be created and
> included in the DNS response. In the Response the Scope Net Mask of the
> ClientSubnetOption is set as the Source Net Mask
>
> Testing
>   We’ll test against all of the various CZF, National, Regional, VPN
> Blocking features and will do our best to check with DNSSEC
>
> —Eric
>
>
>
>
>
>

Re: LDAP Access

[David Neuman]

If you know the user id then there is a DISALLOWED role you can assign them
to.

Re: [VOTE] Adding a CHANGELOG.md file

[David Neuman]

I am calling this vote closed and failed.  It is clear that we do not want
to have to manually manage a changelog file; at a minimum it should be an
automated process.



On Wed, May 17, 2017 at 2:43 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> The Influx Changelog contains sections for Features vs Bugfixes.
>
> I personally find that useful and would like to keep something similar in
> our Changelog. Hopefully with JIRA or Issues we can indicate with a label
> or tag which section this item should go into (defaulting to Bugfix to not
> be a pain)
>
> —Eric
>
>
> > On May 17, 2017, at 2:34 PM, Dave Neuman  wrote:
> >
> > yeah, something that creates an automated Changelog.MD file is better
> than
> > putting it in a github release.  If I understood the talks I went to
> > earlier, Apache does not like it when you create a "release" before you
> > actually vote on release candidates, etc.
> >
> > I am +1 with an automated release, once we move to "full" github.
> >
> > On Wed, May 17, 2017 at 1:22 PM, Dan Kirkwood  wrote:
> >
> >> yeah -- what Hank said...
> >>
> >> On Wed, May 17, 2017 at 11:17 AM, Hank Beatty 
> wrote:
> >>> -1 for a manual changelog - doing a compare between branches/commits in
> >>> github is relatively simple.
> >>>
> >>> +1 for a scripted changelog -
> >>> https://github.com/skywinder/github-changelog-generator - There is
> even
> >> a
> >>> list of alternatives:
> >>> https://github.com/skywinder/Github-Changelog-Generator/
> >> wiki/Alternatives
> >>>
> >>> On 05/17/2017 12:52 PM, Phil Sorber wrote:
> 
>  Here is a link to an example script generated CHANGES file from Jira:
> 
>  https://raw.githubusercontent.com/apache/trafficserver/6.0.x/CHANGES
> 
>  On Wed, May 17, 2017 at 10:48 AM Phil Sorber 
> wrote:
> 
> > The script can be updated to do Jira. ATS used a Jira version before
> >> they
> > went to github. You can also separate out easily. In fact, we did it
> >> more
> > easily with Jira than with github, since those categories are
> mutually
> > exclusive in Jira and labels in github are not. You could also have a
> > developer run the script regularly, or have CI do it.
> >
> > To Eric's comment, if you can make that indication in Jira/GitHub
> then
> > you
> > can transition that to the script. For example, a "Changelog" label
> in
> > github that would mean to have it included.
> >
> > On Wed, May 17, 2017 at 10:37 AM Eric Friedrich (efriedri) <
> > efrie...@cisco.com> wrote:
> >
> >> What about a compromise where developer chooses whether or not a
> >> feature/important fix is worth mentioning in the release notes. This
> >> would
> >> be at feature granularity not individual commit.
> >>
> >> Then at release build time, a script gathers from JIRA/Github API
> all
> >> fixes that were committed in that release and checks that into repo.
> >>
> >> —Eric
> >>
> >>> On May 17, 2017, at 12:18 PM, Phil Sorber 
> wrote:
> >>>
> >>> Don't we have a script that can generate this? ATS had this for a
> >> long
> >>
> >> time
> >>>
> >>> and it became a huge hassle. It caused merge conflicts all the
> time,
> >>
> >> that
> >>>
> >>> while easy to address, were a huge nuisance. It also ended up out
> of
> >>
> >> date
> >>>
> >>> often.
> >>>
> >>> On Wed, May 17, 2017 at 10:11 AM Gelinas, Derek <
> >>
> >> derek_geli...@comcast.com>
> >>>
> >>> wrote:
> >>>
>  +1 for sure. It'll also give us a way to scan the notes and see
> what
> >>
> >> needs
> 
>  documenting and what doesn't yet have it.
> 
> > On May 17, 2017, at 11:44 AM, Dave Neuman 
> >> wrote:
> >
> > Hey All,
> > One thing we discussed at the meetup was the addition of a
> >>
> >> CHANGELOG.md
> >
> > file to the project.   This file will contain changes that are
> made
> > to
> 
>  the
> >
> > project including bug fixes and new features. (e.g.
> > https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md
> ).
> 
>  Adding
> >
> > this file means that we will now require each PR to contain an
> >> update
> >>
> >> to
> >
> > the CHANGELOG.md file, and our documentation will need to be
> >> updated
> > accordingly.
> > I thought it would be good to open a vote for adding this file,
> and
> >>
> >> if it
> >
> > passes, I will update the documentation and add a CHANGELOG.md
> >> file.
> >
> > Thanks,
> > Dave
> 
> 
> >>
> >>
> 
> >>>
> >>
>
>

Re: Proposal for CDN definition file based configuration management

[David Neuman]

The discussion around delivery service configs should probably be it's own
thread, however I am going to contribute to the hijacking of this thread
anyway.

We need to make sure that we keep the Traffic Router in mind when
discussing delivery service changes that get applied "instantly" and
individually.  There are certain attributes of a delivery service that
affect the Traffic Router and we need to make sure that we don't cause an
issue by pushing a config to a cache before the Traffic Router has it or
visa-versa.

On Fri, Apr 14, 2017 at 8:07 AM, Amir Yeshurun  wrote:

> It seems that with Nir's approach there is no problem to enforce a size
> limit on historical data
>
> On Fri, Apr 14, 2017 at 4:07 PM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
>
> > I think this sounds good Nir.
> >
> > Its not so much the size that is the main concern. Rather, people tend to
> > have strong reactions to “its permanent, it will be there forever”. As
> long
> > as we give some way to delete and preferably with a batch mode we should
> be
> > all set.
> >
> > —Eric
> >
> > > On Apr 13, 2017, at 3:08 PM, Nir Sopher  wrote:
> > >
> > > Hi Eric,
> > >
> > > I thought to start with saving for each configuration the range of
> dates
> > it
> > > was the "head" revision, and the range of dates it was deployed.
> > > This will allow the operator to remove old versions via designated
> script
> > > using criteria like "configuration age", "ds history length" or "was it
> > > deployed". For example "Leave all deployed revisions and up to 100 non
> > > deployed revisions".
> > > I haven't thought of the option to support the marking of configuration
> > > versions as "never delete", but it can surely be added.
> > >
> > > I did not intended to create something more sophisticated, and believe
> > that
> > > the mentioned script will be used only on rare cases that something is
> > > trashing the DB, as the math I did lead me to believe it is a none
> issue:
> > > Judging from the kable-town example, a delivery-service configuration
> > size
> > > is less than 500B. Lets say the average is *1K *to support future
> growth.
> > > Lets also say we support *10K *DSs (which is much much more than any TC
> > > deployment I'm aware of has) and we have *1K *revisions per DS.
> > > In such a case versioning will use 10GB, which I believe is not an
> issue
> > > for postgres to hold (yet, I'm not a postgres expert).
> > >
> > > Nir
> > >
> > >
> > > On Thu, Apr 13, 2017 at 3:53 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> wrote:
> > >
> > >> Hey Nir-
> > >>  If we keep all DS versions in the DB, are there any concerns about
> the
> > >> amount of data retained? I know Delivery Services don’t change very
> > often,
> > >> but over time do we really need to keep the last 1000 revisions of a
> > >> delivery service?
> > >>
> > >> Its more of an implementation detail, but I think it would be useful
> to
> > >> give some control over version retention policies (i.e. keep last n
> > based
> > >> on quantity or dates, mark some as “never delete”)
> > >>
> > >> More inline
> > >>> On Apr 12, 2017, at 12:53 AM, Nir Sopher  wrote:
> > >>>
> > >>> Thanks Derek for the clarification.
> > >>>
> > >>> So the definition file is a global file for the CDN.
> > >>> Does it contain the information of which server has which DS?
> > >>> Does it hold all CDN's DSs configuration together?
> > >>> On a single DS change, will all servers in the CDN download the
> entire
> > >> file
> > >>> for every DS change?
> > >>>
> > >>> What I'm practically asking is, if it is not already your intention,
> > "can
> > >>> the definition file hold only the information of which server holds
> > which
> > >>> DS (and configuration version when we add it), and the DS
> configuration
> > >> be
> > >>> held and pulled separately on a DS level granularity?"
> > >>>
> > >>> When discussing "self-service" we would like to decouple the
> operations
> > >> of
> > >>> the different users / content providers. Ultimately, when a DS is
> > >> changed,
> > >>> the change should be deployed immediately to the CDN - with no
> > dependency
> > >>> with other DSs, and possibly with "no buffering" by the operator
> > >> deploying
> > >>> batch of DS changes together. This allows to improve the user
> > experience
> > >>> and independence when working on the CDN.
> > >>> Following the change you are suggesting, will the DS configuration
> > >>> deployment coupling get tighter? We prefer not to have the need to
> > >> "finish
> > >>> your work and not start additional work before the queued run has
> > >>> completed".
> > >> EF> Agree. The less steps our users have to take, the happier they
> are.
> > If
> > >> it was a common workflow to batch a bunch of DS changes and them roll
> > them
> > >> out together, I would probably be a stronger advocate for keeping the
> > queue
> > >> update/snapshot crconfig steps around. In 

Re: 2.0 release?

[David Neuman]

Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet
released, why don't we just remove the `ResumeSession` method all together
and eliminate the dependency?  Otherwise we are deprecating something that
we never formally released.

On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts 
wrote:

> Regarding `TC-119: traffic_ops/client dependency license issue`:
>
> It looks like the persistent cookie jar is only needed by Traffic Ops
> Client `ResumeSession(toURL string, insecure bool) (*Session, error)`.
> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone else is
> using it. Because it returns an error, and persisted cookies have
> lifetimes, any current users already must handle errors from persisted
> cookies being expired. Thus, we can change it to always return an error
> with only degraded performance (and not much, login is cheap), without loss
> of functionality.
>
> To fix TC-119, I propose we document `ResumeSession` as deprecated, and
> change it to always return an error, which lets us remove the dependency,
> without the development cost of writing our own persistent cookie store
> that no one is using.
>
> Any objections?
>
>
> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell 
> wrote:
>
> > These all got fixed and backported to 2.0:
> >
> > TC-203: Mojo doesn’t set cachable headers on public files”
> > TC-190: TTL type mismatch in CrConfig
> > TC-189: ssl_multicert.config too slow
> >
> > So Jan and Dave just need to close the issues.
> >
> > On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin  >
> > wrote:
> >
> > > Hi Eric,
> > > I was going to address the immediate Postinstall issues TC-185. I am
> way
> > > late on this. I created a fork yesterday, need to run a couple of tests
> > and
> > > then I can push to this fork.
> > > Jeff Martin
> > >
> > >
> > > On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) <
> > > efrie...@cisco.com> wrote:
> > >
> > > > We have some release blockers for 2.0. Specifically:
> > > >
> > > > TC-119: traffic_ops/client dependency license issue
> > > > We cannot ship with Category-X LGPL software, so I’m waiting for
> > this
> > > > to be resolved before cutting a release branch
> > > >  "TC-185 post install doesn’t run due to missing perl module”
> > > > We shouldn’t ship a release in which the install process is
> broken
> > in
> > > > this way.
> > > >*There’s no assignee yet for this, any volunteers?*
> > > >
> > > > I think if we can get those two taken care of we can cut an RC0 later
> > > this
> > > > week.
> > > >
> > > > Major bugs we will ship with (unless someone objects):
> > > > TC-203: Mojo doesn’t set cachable headers on public files”
> > > > TC-190: TTL type mismatch in CrConfig
> > > > TC-189: ssl_multicert.config too slow
> > > >
> > > > —Eric
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On Apr 4, 2017, at 1:13 PM, Dave Neuman  wrote:
> > > > >
> > > > > Good question.  I would also like to see us try to get some release
> > > > > candidates out for 2.0.  I am pretty sure the actual install and
> > > > > postinstall need work.  There are also a couple of issue that are
> > still
> > > > > assigned to 2.0 and unresolved:
> > > > > https://issues.apache.org/jira/browse/TC/fixforversion/
> > > > 12338562/?selectedTab=com.atlassian.jira.jira-projects-
> > > > plugin:version-summary-panel
> > > > > .
> > > > >
> > > > > On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn 
> > > wrote:
> > > > >
> > > > >> When are we planning to release 2.0? We at Comcast are running
> what
> > we
> > > > >> call 2.0…. So we are +1, I am pretty sure.
> > > > >>
> > > > >> Eric: are you waiting for something? Which cats need herding?
> > > > >>
> > > > >> Rgds,
> > > > >> JvD
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: Removing 'internal' from TO API

[David Neuman]

At least a few of those (Steering, federations) were put in the "internal"
namespace to work around Comcast specific issues.  I don't know that I like
the idea of duplicating routes, if anything we should see what is impacted
by moving them out of the internal namespace.

On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell 
wrote:

> Currently, we have a number of API routes scoped as "internal". Here are a
> few examples:
>
> https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
>
> I believe this is going to make it more difficult as we try to implement
> more granular roles / capabilities coupled with tenancy.
>
> So I'm proposing that we create a duplicate non-internal route like this,
> for example:
>
> $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
>
> that way we can slowly move away from the "internal" routes and eventually
> deprecate them.
>
> I think with our upcoming more robust role / tenancy model, there is no
> longer a need for "internal".
>
> Thoughts?
>
> Jeremy
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC5

[David Neuman]

I spot checked a few files that were missing license headers in RC4 and the
license was there.  Since the only thing that changes between RCs was the
license files, I am going to rely on my original testing and vote +1.

On Tue, Dec 20, 2016 at 11:07 AM, Dan Kirkwood  wrote:

> One correction:  The signed source tarball and checksums are available
> here:
>   https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/1.8.0/RC5/
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC4

[David Neuman]

A little late, but I am +1.

On Mon, Dec 12, 2016 at 9:43 AM, Dan Kirkwood  wrote:

> Reminder -- 1.8.0-RC4 is open for voting until 5pm MST today.   Please
> vote by replying to this email.  The release is available here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/
>
>
> On Thu, Dec 8, 2016 at 12:58 PM, Dan Kirkwood  wrote:
> > Hello All,
> >
> > I've prepared another release for v1.8.0 (RC4)
> >
> > Changes since 1.7.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-1.7.0...RELEASE-1.8.0-RC4
> >
> > This corresponds to git:
> >   Hash: 7d8a88d0512ffe0354c2bc079ddbf2e7b67b6c3e
> >   Tag: RELEASE-1.8.0-RC4
> >
> > Which can be verified with the following:git tag -v RELEASE-1.8.0-RC4
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > Note that we are not providing the RPM files this time.   The only
> > artifact provided is a source tar file which can be downloaded from
> > here:
> >
> >   https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/1.8.0/RC4/
> >
> > Let me know if you need the rpm files and I can make arrangements to
> > get them to you.
> >
> > Per Apache guidelines, the .tar.gz file is signed with my pgp key (see
> > above) and md5 and sha1 checksums are also provided there.
> >
> > We'd like to shorten the turnaround time to around 3 days,  so this
> > vote is open until the end of the day Monday, December 12, 2016.
> >
> > Thanks!
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC3

[David Neuman]

I can help with the Traffic Monitor files.

On Fri, Dec 2, 2016 at 4:07 PM, Leif Hedstrom  wrote:

>
> > On Dec 1, 2016, at 4:02 PM, Dan Kirkwood  wrote:
> >
> > Hello All,
> >
> > I've prepared another release for v1.8.0 (RC3)
> >
> > Changes since 1.7.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-1.7.0...RELEASE-1.8.0-RC3
> >
> > This corresponds to git:
> > Hash: daf585eacdcae4f57d60f14b4b6170b004058559
> > Tag: RELEASE-1.8.0-RC3
> >
>
>
> More nitpicking :).
>
> 1) Your .md5 is slightly unusual, pretty sure most ASF projects use a
> format like
>
> fedora (15:44) 271/0 $ md5sum incubator-trafficcontrol-1.8.
> 0.4569.daf585ea.tar.gz
> d51294f20b2c19ab024cbb214740c498  incubator-trafficcontrol-1.8.
> 0.4569.daf585ea.tar.gz
>
>
> 2) For shits and giggles, throw in the SHA1 sum too (it’s not required,
> but suggested).
>
> 3) if it was me, I’d drop the commit ID :). I assume you are tagging the
> git repo with the release version anyways, right ?
>
> 4) I’d much prefer if the tar-ball unpacked into e.g.
> incubator-trafficcontrol-1.8.0-RC3 or some such.
>
> 5) There are still quite a lot of files lacking Apache License. See some
> examples below. I can give a complete list if you need. Also, I couldn’t
> find an exclude file to feed to the RAT app, that might also be something
> to provide? There are legitimate cases where you can’t put a license into
> files, such as the JSON files.
>
> 6) Continuing on 5), there’s a few things that looks like imports, but I
> don’t see a blurb in NOTICE for ‘em. E.g.
>
> traffic_monitor/experimental/vendor/github.com/davecheney/gmx/ <
> http://github.com/davecheney/gmx/>
> traffic_monitor/experimental/vendor/gopkg.in/fsnotify.v1
>
>
> I’m not 100% certain what the Incubator release policies are right now,
> but I’d be surprised if they would not have a beef with the large amounts
> of source files without license or attributions.
>
> Cheers,
>
> — leif
>
>   traffic_monitor/.classpath
>   traffic_monitor/.pmd
>   traffic_monitor/.project
>   traffic_monitor/README.md
>   traffic_monitor/pom.xml
>   traffic_monitor/build/pmd/ruleset.xml
>   traffic_monitor/etc/_astats
>   traffic_monitor/etc/_astats_static
>   traffic_monitor/etc/ats_sim.js
>   traffic_monitor/experimental/common/adapter/adapter.go
>   traffic_monitor/experimental/common/crstates/crstates.go
>   traffic_monitor/experimental/common/fetcher/fetcher.go
>   traffic_monitor/experimental/common/handler/handler.go
>   traffic_monitor/experimental/common/instrumentation/instrumentation.go
>   traffic_monitor/experimental/common/log/log.go
>   traffic_monitor/experimental/common/poller/poller.go
>   traffic_monitor/experimental/conf/traffic_ops.cfg
>   traffic_monitor/experimental/traffic_monitor/build.sh
>   traffic_monitor/experimental/traffic_monitor/index.html
>   traffic_monitor/experimental/traffic_monitor/sorttable.js
>   traffic_monitor/experimental/traffic_monitor/traffic_
> monitor-example-config.json
>   traffic_monitor/experimental/traffic_monitor/traffic_monitor.go
>   traffic_monitor/experimental/traffic_monitor/version.go
>   traffic_monitor/experimental/traffic_monitor/cache/astats.go
>   traffic_monitor/experimental/traffic_monitor/cache/astats.json
>   traffic_monitor/experimental/traffic_monitor/cache/astats_test.go
>   traffic_monitor/experimental/traffic_monitor/cache/cache.go
>   traffic_monitor/experimental/traffic_monitor/config/config.go
>   traffic_monitor/experimental/traffic_monitor/deliveryservice/stat.go
>   traffic_monitor/experimental/traffic_monitor/deliveryservicedata/stat.go
>   traffic_monitor/experimental/traffic_monitor/enum/enum.go
>   traffic_monitor/experimental/traffic_monitor/health/cache_health.go
>   traffic_monitor/experimental/traffic_monitor/manager/
> cacheavailablestatus.go
>   traffic_monitor/experimental/traffic_monitor/manager/datarequest.go
>   traffic_monitor/experimental/traffic_monitor/manager/dsstats.go
>   traffic_monitor/experimental/traffic_monitor/manager/events.go
>   traffic_monitor/experimental/traffic_monitor/manager/healthresult.go
>   traffic_monitor/experimental/traffic_monitor/manager/lastkbpsstats.go
>   traffic_monitor/experimental/traffic_monitor/manager/manager.go
>   traffic_monitor/experimental/traffic_monitor/manager/monitorconfig.go
>   traffic_monitor/experimental/traffic_monitor/manager/opsconfig.go
>   traffic_monitor/experimental/traffic_monitor/manager/peer.go
>   traffic_monitor/experimental/traffic_monitor/manager/polledcaches.go
>   traffic_monitor/experimental/traffic_monitor/manager/stathistory.go
>   traffic_monitor/experimental/traffic_monitor/manager/uintman.go
>   traffic_monitor/experimental/traffic_monitor/peer/crstates.go
>   traffic_monitor/experimental/traffic_monitor/peer/crstates.json
>   traffic_monitor/experimental/traffic_monitor/peer/peer.go
>   traffic_monitor/experimental/traffic_monitor/peer/peer_test.go
>   

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC2

[David Neuman]

If I remember correctly, the RPMs were included as a convenience.  I am ok
with not including them, if someone wants an RPM they are easy enough to
build with the build script.

On Thu, Dec 1, 2016 at 1:40 PM, Dan Kirkwood  wrote:

> I'd also love to ditch the RPMs,but I'll abstain from voting since
> it directly impacts me immediately (less work for me!).
>
> Would anyone else like to weigh in on this?
>
> Dan
>
> On Thu, Dec 1, 2016 at 12:52 PM, Leif Hedstrom  wrote:
> >
> >> On Dec 1, 2016, at 12:46 PM, Phil Sorber  wrote:
> >>
> >> http://www.apache.org/dev/release-signing.html#basic-facts
> >>
> >> Missing checksums for the artifacts.
> >>
> >> And for the record, I am still not liking the RPM's as release
> artifacts,
> >> but I'll let the IPMC weigh in on that.
> >
> >
> > If I had a vote, now that you have the tar-ball, I’d ditch all he RPMs.
> If someone needs the RPMs, make a Makefile target such that someone can
> produce those source RPMs (shouldn’t they be .srpm) from the tar-ball.
> >
> > Cheers,
> >
> > — Leif
> >
>

Re: Proposed change to Deliverservice API

[David Neuman]

Fair enough.  I agree we should use natural keys.  To me the ID thing is
something internal to the DB that a client should not have to worry about.
I can update the Traffic Ops client to support using IDs and keep the API
as-is.

On Wed, Nov 30, 2016 at 8:26 AM, Jan van Doorn  wrote:

> Agree with Jeremey. And we can't just slip in a change to 2.0 that does
> part of this.
>
> I'm -1 on neuman's change, at least for 2.0.
>
> Cheers,
> JvD
>
>
>
> > On Nov 30, 2016, at 08:23, Jeremy Mitchell 
> wrote:
> >
> > Let's look at an example of using ID's versus names for POSTS (creates)
> >
> > Here is the region table. A region belongs to a division.
> >
> > mysql> desc region;
> > +--+-+--+-+-
> --+-+
> > | Field| Type| Null | Key | Default   | Extra
> >|
> > +--+-+--+-+-
> --+-+
> > | id   | int(11) | NO   | PRI | NULL  |
> > auto_increment  |
> > | name | varchar(45) | NO   | UNI | NULL  |
> >|
> > | division | int(11) | NO   | MUL | NULL  |
> >|
> > | last_updated | timestamp   | YES  | | CURRENT_TIMESTAMP | on update
> > CURRENT_TIMESTAMP |
> > +--+-+--+-+-
> --+-+
> > 4 rows in set (0.01 sec)
> >
> > Currently, if you want to create a region, you have to provide a division
> > "id" (as opposed to a division name)
> >
> > POST /api/version/regions
> >
> > {
> > name: "myregion",
> > division: 2
> > }
> >
> > This allows the json to go directly into the table with one insert query.
> >
> > if we use a division name instead, like this
> >
> > {
> > name: "myregion",
> > division: "central"
> > }
> >
> > then 2 queries have to happen on the server side. 1 query to fetch the
> > division id for "central" and then the insert query to create the region.
> >
> > To do this right, imo, the ID for the central division WOULD be "central"
> > instead of the number 2 - and this is why natural keys make a lot of
> sense.
> > So rather than changing the api to accept cdn name, profile name, and
> type
> > name, continue to send thru the ids and we need to make the effort to get
> > to natural keys.
> >
> > my 2 cents
> >
> > On Wed, Nov 30, 2016 at 7:53 AM, Dave Neuman  wrote:
> >
> >> Thanks Derek, it's actually already done, but then it dawned on me that
> it
> >> might break others, which is why I posted.
> >>
> >> On Wed, Nov 30, 2016 at 7:51 AM, Gelinas, Derek <
> derek_geli...@comcast.com
> >>>
> >> wrote:
> >>
> >>> I've already got a bit of code you can use for just that if you like.
> >>> Doing the same for the config file lookups.
> >>>
>  On Nov 30, 2016, at 9:50 AM, Dave Neuman  wrote:
> 
>  Hey all,
>  I have been working on creating some integration tests for the Traffic
> >>> Ops
>  client in the psql-rebase branch and fixing any bugs in Traffic Ops
> >> along
>  the way.
>  One thing I would like to change is to have the DeliveryService.create
> >>> and
>  Deliveryservice.update in the Traffic Ops API accept cdn name, profile
>  name, and type name instead of cdn ID, profile ID, and type ID.  I
> >>> usually
>  don't like to have clients worry about IDs, I think it should be
> >> handled
> >>> on
>  the server side.  I don't know who all is using the Deliveryservice
> >>> create
>  and update APIs, if anyone, so I thought I would make the suggestion
> >> here
>  and see if anyone is opposed?
>  This change would be in a 2.x version of Traffic Ops.
> 
>  Thanks,
>  Dave
> >>>
> >>
>
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[David Neuman]

I think we need to include a source tarball that contains the project name
and "incubating" (e.g. traffic_control_incubating_1.8.0_source.tar.gz).
We can also include the RPMs but we should note that they are for
convenience only and therefore they shouldnt need incubating in the name.

On Wed, Nov 9, 2016 at 9:13 AM, Dan Kirkwood  wrote:

> Thanks,  Eric..
>
> I'll get the signatures in there, too and look into astats..
> Suggestions on the form of the package name?  e.g.
>
> traffic_ops-incubator-1.8.0-RC1-..x86_64.rpm ?
>
> -dan
>
> On Tue, Nov 8, 2016 at 6:46 PM, Eric Friedrich (efriedri)
>  wrote:
> > Hey Dan-
> >   I haven’t looked at the RPMs yet, but I think we also need to put up a
> package for astats.
> >
> > A few other things:
> >   - Package name should have “incubating” in it
> >   - Need signatures directly on the release packages (i.e. 1 detached
> sig per RPM/SRPM), see these:
> > https://www.apache.org/dev/release-publishing.html#valid
> > https://www.apache.org/dev/release-signing.html#basics
> >
> >
> > On Nov 8, 2016, at 5:38 PM, Dan Kirkwood  o...@gmail.com>> wrote:
> >
> > Hi Leif,   we are aware of that and want to get to that point.   We've
> > traditionally been Centos-based, and the rpm building is already
> > implemented.  That's intended as a nicety to make testing the RC
> > easier..   I, for one,  would love to eliminate building rpm's...
> >
> > Dan
> >
> > On Tue, Nov 8, 2016 at 3:32 PM, Leif Hedstrom > wrote:
> >
> > On Nov 8, 2016, at 3:27 PM, Dan Kirkwood  g...@apache.org>> wrote:
> >
> > Hello All,
> >
> > I've prepared a release for v1.8.0 (RC1)
> >
> > Changes since 1.7.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1
> >
> > This corresponds to git:
> > Hash: bebf63eedce2d3912752c65b0d52d739f820e0ac
> > Tag: RELEASE-1.8.0-RC1
> >
> >
> > Hmmm, quick question: Why RPMs? That seems pretty restrictive, in that
> someone could not download / test / look at any of this without having an
> OS distro that supports RPM… It’d be preferable (IMO at least) to have
> source artifacts as regular tar-balls (gzip / bzip2’d).
> >
> > Cheers,
> >
> > — Leif
> >
> >
>

Re: [jira] [Commented] (TC-28) API response structure should be hierarchical instead of flat

[David Neuman]

API 1.3!!!

On Fri, Nov 4, 2016 at 3:41 PM, Jeremy Mitchell 
wrote:

> what i should have done has rolled api/1.3
>
> on monday, i'll get api/1.2 back to where it's always been and move this
> new structure into api/1.3
>
> Jeremy
>
> On Fri, Nov 4, 2016 at 3:11 PM, ASF GitHub Bot (JIRA) 
> wrote:
>
> >
> > [ https://issues.apache.org/jira/browse/TC-28?page=com.
> > atlassian.jira.plugin.system.issuetabpanels:comment-
> > tabpanel=15637694#comment-15637694 ]
> >
> > ASF GitHub Bot commented on TC-28:
> > --
> >
> > Github user mitchell852 closed the pull request at:
> >
> > https://github.com/apache/incubator-trafficcontrol/pull/48
> >
> >
> > > API response structure should be hierarchical instead of flat
> > > -
> > >
> > > Key: TC-28
> > > URL: https://issues.apache.org/jira/browse/TC-28
> > > Project: Traffic Control
> > >  Issue Type: Improvement
> > >  Components: Traffic Ops API
> > >Affects Versions: 1.8.0
> > >Reporter: Jeremy Mitchell
> > >Priority: Minor
> > > Fix For: 1.8.0
> > >
> > >
> > > I created a handful of api endpoints in 1.8 with a flat response
> > structure like:
> > > {
> > > "response": [
> > > {
> > > "asn": "23",
> > > "cachegroupId": "69",
> > > "cachegroupName": "Foo_Cachegroup",
> > > "id": "60",
> > > "lastUpdated": "2016-10-13 12:31:43"
> > > }
> > > ]
> > > }
> > > Although this is fine, it makes it more difficult to test when using
> > structures derived from the database. This structure is more friendly.
> > > {
> > > "response": [
> > > {
> > > "asn": "23",
> > > "cachegroup": {
> > > "id": "69",
> > > "name": "Aberdeen_17802B_Ciscos"
> > > },
> > > "id": "60",
> > > "lastUpdated": "2016-10-13 12:31:43"
> > > }
> > > ]
> > > }
> > > This nested structure needs to be applied to api endpoints related to
> > asn, cachegroup, deliveryservice, phys_location, region, server and user.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
>

Re: Moving in to the Apache Incubator!

[David Neuman]

Thanks Jan, this is great news!  Are we going to keep the slack instance
around?

On Tue, Oct 4, 2016 at 5:21 PM, Jan van Doorn  wrote:

> As most of you know, we have been working in the back ground to move
> Traffic Control in to the Apache Incubator. All legal i's and t's are
> dotted and crossed now, so we're going to start the move.
>
> First, email lists. In Apache it's only official if it happened on the
> email list. So it's OK to discuss stuff in person or via phone/chat/video
> conferencing, and even to get consensus there, but it's not decided until
> it was discussed on the list. If it is a major feature or change, we
> probably want to do a [VOTE] thread.
>
> We have these lists for anyone to join:
>
> iss...@trafficcontrol.incubator.apache.org
> us...@trafficcontrol.incubator.apache.org
> dev@trafficcontrol.incubator.apache.org
> comm...@trafficcontrol.incubator.apache.org
>
>
> You can subscribe to those by sending an email to -subscribe@
> trafficcontrol.incubator.apache.org and following the instructions in the
> email response.
>
> If you want to see everything going on, just send one email to these
> addresses:
>
> issues-subscr...@trafficcontrol.incubator.apache.org
> users-subscr...@trafficcontrol.incubator.apache.org
> dev-subscr...@trafficcontrol.incubator.apache.org
> commits-subscr...@trafficcontrol.incubator.apache.org
>
> and reply to the responses.
>
> For more info on lists and subscribing, please see: http://apache.org/
> foundation/mailinglists.html
>
> I propose that in the next few months we keep an eye on the Google Groups
> as well, and if questions pop up there, we ask the OP to repost on the
> apache list. The website will be updated soon to reflect the new Apache
> status and lists.
>
> Soon we will also move the source code into the Apache git repo, and the
> issues to an Apache JIRA instance; more on the new processes that go along
> with that as we do these moves.
>
> Best Regards,
> JvD
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "traffic_control-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to traffic_control-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to traffic_control-discuss@
> googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/traffic_control-discuss/9E443A12-0C51-41C7-944A-
> C3F8E0E877C4%40knutsel.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>