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

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&focusedCommentId=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: [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 mailto:dang
> 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  zw...@apache.org>> wrote:
> >
> > On Nov 8, 2016, at 3:27 PM, Dan Kirkwood mailto:dan
> 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: Help the poor RMs

[David Neuman]

I actually don't think we can do milestones, labels, or assignees in github
anymore. We lost that when we moved to the incubator github.  :(
But we should mark Jiras accordingly and open a Jira for a PR whenever it
makes sense.

On Fri, Nov 11, 2016 at 2:01 PM, Leif Hedstrom  wrote:

> Please make an effort to mark GitHub PRs (and Jiras) with relevant
> information. In Github, you have Milestones (versions), Labels (components
> etc.) as well as assignee you can use. You can also add PRs to the
> projects, to help with back ports etc.
>
> Same with Jira, at a minimum add the appropriate version information,
> Components etc.
>
> Don’t expect someone else will do this for you  :-).
>
> — 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-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: [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
>   traffic_monitor/experimental/traffic_monitor/srvhttp/srvhttp.go

Re: Apache license in source files

[David Neuman]

+1 and sorry for merging a PR without. I will make sure all files have them
before merging in the future.

On Mon, Dec 5, 2016 at 15:48 Dan Kirkwood  wrote:

> Hi all.. We haven't really established a process for this,  but to
> keep in compliance with Apache license guidelines,  each source file
> should have the Apache license comment -- normally at the head of the
> file, but I think that's somewhat flexible.
>
> Still going thru files adding them,  but when any new files get added,
> they really should have that header in them already.
>
> What do you all think of establishing a guideline that any PR is not
> merged until the license is present in each source file added?
>
> -dan
>

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&op=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-RC4

[David Neuman]

I just gave a +1 without really explaining the testing I did, so here is a
list of what I did...
- upgrade all components (TS requires influxdb 1.0 or greater, fyi)
- validate ORT output on and Edge and Mid against 1.7 version, validate no
unexpected changes
- end to end curls and digs against TR
- validate HTTPS functionality for TR
- Validate ORT (1.8.0 RC4 is running in production for us)

On Sun, Dec 18, 2016 at 8:58 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> +1 (binding)
>
> I checked the following:
> - Clean build from source
> - PGP signature, MD5/SHA1 Sums
> - DISCLAIMER
> - NOTICE
> - LICENSE
> - incubator in name
>
> —Eric
>
>
> > On Dec 16, 2016, at 11:55 AM, Dan Kirkwood  wrote:
> >
> > Hi all.. We've decided to extend the voting until end-of-day
> > Monday,  December 19 to allow for more participation.If you have
> > voted on a previous RC,  please be sure to vote again.
> >
> > The more information we get on what has been tried,  the better,   so
> > if you see problems or not,  please share!
> >
> > Thanks..  Dan
> >
> > On Tue, Dec 13, 2016 at 11:23 AM, Dan Kirkwood 
> wrote:
> >> I have no control over the mentors :-)Yes -- since you chimed in,
> >> I'm happy to wait for your input..
> >>
> >> -Dan
> >>
> >> On Tue, Dec 13, 2016 at 10:50 AM, Leif Hedstrom 
> wrote:
> >>>
> >>>> On Dec 13, 2016, at 7:47 AM, Dan Kirkwood  wrote:
> >>>>
> >>>> So that makes us +1 overall,  since you're the only vote :-)
> >>>
> >>>
> >>> Eeep. Where are the mentor votes? :)
> >>>
> >>> I’m traveling and in meetings this week, but if you are extending the
> vote deadling, I can try to take a look tomorrow morning.
> >>>
> >>> Cheers,
> >>>
> >>> — leif
> >>>
> >>>>
> >>>> On Tue, Dec 13, 2016 at 8:45 AM, David Neuman <
> david.neuma...@gmail.com> wrote:
> >>>>> 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&op=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-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: Traffic Ops Dev environment - postgresql installation

[David Neuman]

First of all, it looks like your documentation is to our old site, you will
want to use http://trafficcontrol.apache.org/docs/latest/index.html in the
future.
If you don't have docker and docker-compose on your VM (it would need to be
centos 7.x or above), we should be able to get it working with a "normal"
postgres install; I would start by taking a look at the scripts that are in
`/traffic_control/traffic_ops/app/db/pg-migration`.  Maybe @dangogh is
familiar enough with the process that he can provide a quick how-to?

On Mon, Jan 23, 2017 at 5:14 PM, Nir Sopher  wrote:

> Thank you Dave&Dan,
>
> The pg-migration document assumes I am working in a Docker environment.
> Currently I am working on a VM on which I manually installed the software
> requirement list
>  traffic_ops.html?#software-requirements>
> .
> Is there a specification that will allow me to bring up such a Docker? Am I
> practically required t have one in order to work on traffic-ops?
>
> I tried to configure the postgres myself, but with no success so far.
> Anyway, as I'm practically utilizing my dev environment for the first time,
> it may be counter productive to work on an unstable branch.
>
> 10x,
> Nir
>
>
>
>
> Nir
>
> On Tue, Jan 24, 2017 at 12:56 AM, Dan Kirkwood  wrote:
>
> > The postgresql version is still quite experimental right now.   If you
> > are feeling adventurous,  we appreciate the help in testing it,  but
> > you may want to use 1.7.x or 1.8.x with mysql until we have the
> > postgresql branch (master) more stable.   The master branch will not
> > work with mysql at all.
> >
> > -Dan
> >
> > On Mon, Jan 23, 2017 at 2:50 PM, Dave Neuman  wrote:
> > > I am certainly not the expert here, but I would start by taking a look
> at
> > > the README.md file in traffic_control/traffic_ops/app/db/pg-migration.
> > You
> > > can use that to migrate from mysql to postgres using docker-compose.
> > >
> > > —Dave
> > >
> > >
> > > On Mon, Jan 23, 2017 at 2:44 PM, Nir Sopher  wrote:
> > >
> > >> Hi,
> > >>
> > >> I am trying to create a new Traffic-Ops dev environment setup,
> following
> > >> the instructions in the developer guide.
> > >> I encountered however several failures on the way, related to the
> > movement
> > >> toward postgresql. I therefore installed the relevant postgresql RPMs.
> > >>
> > >> I got to the point I have to initilize the values in the postgresql
> > server
> > >> in order for the "./db/admin.pl --env=development setup" command to
> > run.
> > >>
> > >> Should I follow the instructions in "experimental/server/README.md"?
> > >> Is there a way to deactivate the postgresql server and continue to
> work
> > >> with mysql until postgresql moves out from "experimental" phase?
> > >>
> > >> 10x,
> > >> Nir
> > >>
> >
>

Re: Debugging TO in a local (dev) environment

[David Neuman]

You should be able to just run it like this:
/usr/local/bin/node
/git/apache/incubator-trafficcontrol/traffic_monitor/etc/ats_sim.js
https:///CRConfig-Snapshots//CRConfig.json

​

On Sun, Jan 29, 2017 at 8:57 AM, Amir Yeshurun  wrote:

> Hi Dave,
>
> Can you elaborate on how to run the ats_sim.js script?
> I tried to run it as a stand alone script, using the node command line, but
> the requests against TO are unauthorized, as it does not handle login.
>
> Thanks
> /amiry
>
> On Fri, Jan 27, 2017 at 6:17 PM Dave Neuman  wrote:
>
> > +1, we have some internal tools floating around to do some of that, but
> > nothing available publicly (or ready for public consumption).  I would
> > definitely be in favor of adding some of those things to the project.
> >
> > On Fri, Jan 27, 2017 at 6:25 AM, Amir Yeshurun  wrote:
> >
> > > Thanks a lot, Dave,
> > >
> > > I'd like to consider investing in such testing tools.
> > >
> > > In addition to cache simulation, we can create clients simulation, to
> > debug
> > > request routing path. A Traffic Monitor mock, to debug motioning path
> > > without caches,
> > > and maybe more.
> > >
> > > I would be glad to hear any insights about this.
> > >
> > > Thanks
> > > /amiry
> > >
> > > On Thu, Jan 26, 2017 at 7:10 PM Dave Neuman  wrote:
> > >
> > > > Hey Amiry,
> > > > Unfortunately we do not have a mock version of Traffic Monitor to use
> > for
> > > > testing.  We do, however, have an ATS simulator here:
> > > >
> > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > master/traffic_monitor/etc/ats_sim.js
> > > > which you can use with a Traffic Monitor to simulate traffic monitor
> > > > polling caches and sending responses.
> > > > Hopefully that helps.
> > > >
> > > > Thanks,
> > > > Dave
> > > >
> > > > On Thu, Jan 26, 2017 at 7:37 AM, Amir Yeshurun 
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I'm running a local instance of TO, and debugging the CDN health
> API
> > > > route
> > > > > /api/1.2/cdns/health
> > > > >
> > > > > In order to report the CDN health, TO need to read cache status
> from
> > > > > Traffic Monitor, which in turn, has to collect status from the
> > caches.
> > > > >
> > > > > I am looking for a way to create a dev setup on which I can debug
> > such
> > > > use
> > > > > cases, without having to run numerous monitors and caches.
> > > > >
> > > > > Does the unit/integration test framework provides infrastructure to
> > > mock
> > > > > Traffic Monitor responses?
> > > > >
> > > > > Are there other kind of mocks that can mimic Traffic Monitor
> > responses?
> > > > >
> > > > > I'd appreciate any tips and practices.
> > > > >
> > > > > Thanks
> > > > > /amiry
> > > > >
> > > >
> > >
> >
>

Re: Github PR suggestion

[David Neuman]

I am -1 on it being "required" however,  I am ok with saying we prefer it.


On Wed, Feb 15, 2017 at 20:04 Jeremy Mitchell  wrote:

> Should we require a Jira issue for each PR? I don't think it's a bad idea
> personally. And if we do require a Jira issue, it would be nice imo to see
> each PR entitled like "[TC-XXX] - fixes blah blah"
>
> Jeremy
>
> On Tue, Feb 14, 2017 at 2:16 PM, Leif Hedstrom  wrote:
>
> > Hi all,
> >
> > since we now have a process which lets us create Github PRs, without
> first
> > filing a bug report / issue, I’ve come to find that it’s many times
> > difficult to know what “issue” a particular PR is addressing. So, I would
> > like to suggest that we all make an effort to put more Description text
> in
> > Github PRs, which do not have a Github Issue filed already.
> >
> > I’m also writing up a little bit of this into the CONTRIBUTING.md.
> >
> > Thanks,
> >
> > — Leif
> >
> >
>

Re: Access Control Model

[David Neuman]

>From what I understand, LDAP is not the issue, it is the fact that we give
everyone read-only by default and read-only users can get sensitive
information.  I think we want to keep LDAP but not allow read-only?

On Fri, Feb 24, 2017 at 2:31 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Do you have a suggested replacement for SSO?
>
> —Eric
>
> > On Feb 24, 2017, at 4:26 PM, Dewayne Richardson 
> wrote:
> >
> > re: Dave on LDAP
> >
> > LDAP should be avoided as we are now finding that it's not a preferrable
> > way of logging in based upon Security Concerns.  If needed for some
> reason
> > down the road we should consider it as a separate Micro Service that can
> be
> > "bolted" on.
> >
> > -Dew
> >
> > On Wed, Feb 22, 2017 at 10:33 AM, Jeremy Mitchell  >
> > wrote:
> >
> >> +1 on Dave's question. ldap is an edge case that we probably have to
> >> account for. so with this new approach, 2 things are checked - your role
> >> (what you can do) and your tenancy (scope of what you can do).
> >>
> >> first one - role:
> >>
> >> we'll need to think how ldap authenticated users (that don't have an
> actual
> >> row in the users table) are automatically assigned a role. Maybe the
> roles
> >> table is seeded with 2 roles like this: (remember, a role is a grouping
> of
> >> "capabilities" (or apis) )
> >>
> >> admin
> >> - GET /api/ds
> >> - GET /api/ds/:id
> >> - PUT /api/ds/:id
> >> - POST /api/ds
> >> - DELETE  /api/ds/:id
> >> - everything other api that TO supports
> >>
> >> read-only
> >> - GET /api/ds
> >> - GET /api/ds/:id
> >> - every other GET api that TO supports (but make sure only GETs that are
> >> reads. we have some GETs that do more than reading :) )
> >>
> >> ^^ maybe these 2 roles are "seeded" in the roles table. so out of the
> box,
> >> you get 2 roles and that 2nd role is very important because
> >> ldap-authenticated users (with no user in the users table) get that
> role...
> >>
> >> 2nd one - tenancy:
> >>
> >> how do we assign tenancy to these ldap-authenticated-has-no-user-row
> >> users?
> >> i would probably suggest they get assigned "root tenant" which is the
> >> parent of all tenants thus eliminating scoping altogether.
> >>
> >> to summarize, i'd suggest ldap-authenticated users (with no user entry
> in
> >> the user table) get:
> >>
> >> - the seeded read-only role
> >> - the root tenant
> >>
> >> And one more thought regarding roles. I mentioned 2 seeded roles (admin
> and
> >> R/O) but IMO an admin should be able to create N number of roles / api
> >> combinations. For example, maybe I have a someone that wants access to
> one
> >> and only one API, i could create the "john_role" that contains that one
> api
> >> and assign that role to john. My point is, the roles table could be
> >> dynamicwhoever administers TO can set up the roles as they see fit..
> >>
> >> Jeremy
> >>
> >> On Wed, Feb 22, 2017 at 9:11 AM, Eric Friedrich (efriedri) <
> >> efrie...@cisco.com> wrote:
> >>
> >>> Will the introduction of the new Access Control Service (and API)
> require
> >>> two new HTTP API calls for every call from the user to the API?
> >>>
> >>> I’d also like to second two of Hank’s requests below for #3 and #4.
> >>>
> >>> —Eric
> >>>
>  On Feb 22, 2017, at 9:03 AM, Hank Beatty  wrote:
> 
>  Hi Naama,
> 
>  I like the idea of making Access Control hierarchical.
> 
>  I came up with some questions I thought we might think about:
> 
>  1. Do the tenants become the equivalent of the "groups" we are using
> >>> today?
> 
>  2. In your example, can there be children of 'Company C'?
> 
>  3. Some of the APIs currently allow for 'token' authentication but,
> the
> >>> UI portion was never implemented (AFAIK). I would like to see the
> 'token'
> >>> authentication added so that scripts don't have to be run with
> user/pass.
> 
>  4. I would like to see more than a single "root" user (perhaps a group
> >>> that one could assign users).
> 
>  Thanks,
>  Hank
> 
>  On 02/21/2017 03:32 PM, Naama Shoresh wrote:
> > Hi,
> >
> > We've been considering the subject of authorization within TO, and
> >> have
> > phrased a concept we'd like to share and get some feedback about.
> > You can find it in the wiki
> >  >>> action?pageId=68715910>,
> > and also written below, for ease of use.
> > Your comments and insights are most welcome.
> >
> > =
> >
> > The access control model concept is constructed of two dimensions:
> > capabilities & data.
> > 1. CapabilitiesCheck if a user is allowed to perform an operation
> >
> > APIs are grouped to roles, and each user is assigned a set of roles
> >>> which
> > implies his allowed APIs.
> >
> > Example:
> >
> > API  | Role
> > 

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: 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: 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 our discussion, that doesn’t
> > seem
> > >> to be o

Re: API GW route configuration

[David Neuman]

+1 on keeping in on the mailing list

On Fri, May 12, 2017 at 7:52 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Can we please keep the discussion on the dev@ list? Apache rules and all.
>
> “If it didn’t happen on the email list, it didn’t happen”
>
>
> On 5/12/17, 9:50 AM, "Amir Yeshurun"  wrote:
>
> Moving discussion to the wiki page. Commented on Jeremy's notes
>
> On Fri, May 12, 2017 at 7:41 AM Shmulik Asafi 
> wrote:
>
> > Regarding sharing signing key with other services raised by Eric -
> notice
> > jwt support asymmetric keys. I.e. only the auth server has the
> private key
> > and other services have a public key.
> >
> > Also, there's another solution for "global invalidation" besides
> switching
> > keys, and that is setting a threshold for token issue date. Whenever
> > there's an attack or whatever and we want to invalidate all tokens
> we just
> > need to set the threshold for 'now' thus forcing all users to issue
> a new
> > token.
> > I think this is more reasonable and scalable than switching keys.
> >
> > On 12 May 2017 05:15, "Jeremy Mitchell" 
> wrote:
> >
> > > Here was the image I was trying to attach:
> > >
> > > https://cwiki.apache.org/confluence/display/TC/API+Gateway
> > >
> > > Jeremy
> > >
> > > On Thu, May 11, 2017 at 2:14 PM, Amir Yeshurun 
> wrote:
> > >
> > > > Hi Jeremy,
> > > > Note that attachments seems to be stripped off on this list and
> the
> > image
> > > > is unavailable.
> > > >
> > > > Your assumptions are correct. We need to figure out the easiest
> > topology
> > > > for UI routes to bypass the GW. Please reattach the picture so
> we can
> > get
> > > > more specific.
> > > >
> > > > Thanks
> > > > /amiry
> > > >
> > > >
> > > >
> > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > > >
> > > > > What is of utmost importance to me is the ability to ease into
> this.
> > We
> > > > > have a TO UI right now that needs to be unaffected by the API
> gateway
> > > in
> > > > my
> > > > > opinion. Granted the old UI might go away at some point but
> until
> > that
> > > > time
> > > > > it needs to function as-is.
> > > > >
> > > > > To me, the simplest approach is to key off request URL.
> anything that
> > > > > starts with /api gets api gateway treatment, the rest passes on
> > > > > thru...Here's a fancy picture to communicate what I envision...
> > > > >
> > > > > [image: Inline image 1]
> > > > >
> > > > > I'm assuming all requests (endpoints) go thru the api gateway
> but
> > maybe
> > > > > i'm wrong in that assumption. Anyhow, i guess my point is the
> UI
> > should
> > > > > continue to work with the mojo cookie and "api" calls should
> use the
> > > jwt
> > > > > token...however, the UI also uses api endpoints so not sure
> how that
> > > > would
> > > > > work...
> > > > >
> > > > > If it's too difficult for the api gateway to support UI and API
> > routes,
> > > > we
> > > > > could always wait until the new UI (which leverages the API) is
> > > > complete...
> > > > >
> > > > > Jeremy
> > > > >
> > > > > On Thu, May 11, 2017 at 10:23 AM, Chris Lemmons <
> alfic...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> > invalidate ALL tokens by changing the token signing key
> > > > >>
> > > > >> Interesting idea. That does mean that the signing key has to
> be
> > > > retrieved
> > > > >> every time from the authentication authority, or it'd be
> subject to
> > > the
> > > > >> exact same set of attacks. But a nearly-constant rarely
> changing key
> > > > could
> > > > >> be communicated very efficiently, I suspect. And if the
> > authentication
> > > > >> system is a web API, it can even use Modified-Since to 304
> 99% of
> > the
> > > > time
> > > > >> for maximum efficiency.
> > > > >>
> > > > >> It does have the downside that key-invalidation events are
> fairly
> > > > >> significant. You'd need to invalidate the keys whenever
> someone's
> > > access
> > > > >> was reduced or removed. As the number of accounts in the
> system
> > > > increases,
> > > > >> that might not wind up being as infrequent as one might hope.
> It's
> > > easy
> > > > to
> > > > >> implement, though.
> > > > >>
> > > > >> On Thu, May 11, 2017 at 10:12 AM Jeremy Mitchell <
> > > mitchell...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Regarding the TTL on the JWT token. a 5 minute TTL seems
> silly.
> > > What's
> > > > >> the
> > > > >> > point? Unless we get into refresh tokens but that sounds
> like
> > > > >> oauth...blah.
> > > > >> >
> > > > >

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: LDAP Access

[David Neuman]

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

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: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC4)

[David Neuman]

Those docs also say 1.8-dev on the top. I think we should get them up to
date before we release.
​

On Wed, Jun 7, 2017 at 12:44 PM, Hank Beatty  wrote:

> Do we care if the documentation is up to date before we cut a release?
> Especially since this requires postgresql 9.6 and that is not mentioned on
> the install page.
>
> http://trafficcontrol.apache.org/docs/2.0.x/admin/traffic_ops_install.html
>
>
> On 06/05/2017 02:16 PM, Eric Friedrich (efriedri) wrote:
>
>> Hello All,
>>
>> I've prepared the next candidate release for incubator-trafficcontrol
>> v2.0.0 (RC4)
>>
>> Changes since 1.8.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/
>> RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC4> apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...
>> RELEASE-2.0.0-RC3>
>>
>> This corresponds to git:
>> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
>> Tag: RELEASE-2.0.0-RC4
>>
>> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC4
>>
>> My code signing key is available here:
>> http://pgp.mit.edu/pks/lookup?op=get&search=0xF2200BAB9AB7BDD5
>>
>> and here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>
>> 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 md5 and sha512 checksums are provided here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC4
>>
>>
>> The vote will remain open until Thursday, June 8, 2017.
>>
>> This RC fixes some packaging issues in RC2 and RC3, there are no other
>> changes. The git tag hash is the same, but due to changes in the tarball
>> the release signatures HAVE changes.
>>
>> Thanks,
>> Eric Friedrich
>>
>>

Traffic Router Tomcat version upgrade

[David Neuman]

Hey all,
I am sending this email as an FYI, and all feedback is appreciated.

I am working on upgrading the version of tomcat used by Traffic Router from
6.0.33 to 8.5.15.  Along with the upgrade I am switching out our TLS
implementation from JSSE (java default) to OpenSSL.  After a discussion at
ApacheCon with one of the leads of the Tomcat project and a follow up on
the Tomcat mailing list [1], it looks like we should get about a 35%
increase in performance for TLS handshakes.  I have not done load testing
yet, so what our improvement actually will be is still TBD.

In order to support OpenSSL there are few new dependencies you will see in
Traffic Router.  The first is tcnative [2]; tcnative is what gives us
OpenSSL support in tomcat/Traffic Router.   Without tcnative, tomcat can
only use the JSSE provider for TLS.  The second is Bouncy Castle [3];
OpenSSL only supports private keys in pkcs8 format while Traffic Ops
creates private keys that are in pkcs1 format.  Bouncy Castle gives us a
java security Provider (BouncyCastleProvider) which can easily convert from
PKCS1 to PKCS8.  I did quite a bit of research and could not figure out how
to easily do this natively, and I did not think it was a good idea to try
to convert everything to pkcs8 at this time so BouncyCastle seemed like a
good compromise.

I am planning on making sure tcnative gets installed as part of the Traffic
Router deployment, but if you are planning on running Traffic Router
locally for development purposes, there will be some new steps to get it to
work correctly.  I will do my best to thoroughly document these steps as
part of my PR.  The Bouncy Castle provider will be loaded dynamically by
maven.

As mentioned earlier, I am mostly sending this email as an FYI so that you
are aware that there are changes being made to Traffic Router which will
have affect on a future deployment.  I hope to have these changes completed
in the next week or two, with a PR to follow.  If you are interested in
trying out the code, doing some initial testing, or just seeing what
changes have been made, the code can be found here [4] and changes here
[5].  Be forewarned, though, that this is still very much a work in
progress.

Any feedback is appreciated and questions are always welcomed.

Thanks,
Dave



[1]
https://lists.apache.org/thread.html/0f7c6d74cc496968fe869958a29adb19723215f6c135efd4a5fa935b@%3Cusers.tomcat.apache.org%3E
[2] http://tomcat.apache.org/native-doc/
[3] https://www.bouncycastle.org/java.html
[4]
https://github.com/dneuman64/incubator-trafficcontrol/tree/tr-upgrade-tomcat
[5]
https://github.com/apache/incubator-trafficcontrol/compare/master...dneuman64:tr-upgrade-tomcat?expand=1

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: Adding support for per-DeliveryService routing names

[David Neuman]

@Ryan:

“edge.” Limits our ability to use wildcard ssl certs for DNS routed
services for similar customer services which can save a lot of time, cost,
and hassle.

Can you explain more?  I don't see the need for wildcard certs when Traffic
Router returns only one FQDN for a DNS routed Deliveryservice?  If you are
talking about a "future feature" then we should worry about that then.

On Fri, Aug 4, 2017 at 8:09 AM, Durfey, Ryan 
wrote:

> Random thought on this…
>
> “edge.” Limits our ability to use wildcard ssl certs for DNS routed
> services for similar customer services which can save a lot of time, cost,
> and hassle.
> “tr.” Makes sense for HTTP 302 routed services because you can use
> wildcard certs for the server hostname that replaces the “tr.” in the
> domain.  Is it worth considering “tr.” for http routed and nothing for DNS
> routed ie. “xml-id.cdn_domain”?
>
> Ryan DurfeyM | 303-524-5099
> CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com cdn_supp...@comcast.com>
>
>
> From: Jan van Doorn 
> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Date: Friday, August 4, 2017 at 8:04 AM
> To: "dev@trafficcontrol.incubator.apache.org" <
> dev@trafficcontrol.incubator.apache.org>
> Subject: Re: Adding support for per-DeliveryService routing names
>
> Agree with Dave on
>
> [*DN] we should default the database column to "edge" for DNS and "tr" for*
> *http.  Then we don't have to do the null check.*
>
> If we do that, we can make the columns mandatory, and it makes sense
> they're not in the DS_PROFILE. Also makes it so we don't have to have a CDN
> wide setting. (and Rawlin, I think you mean to say DS_PROFILE rather than
> TR_PROFILE type to add the param to if we chose to do that?? Or was it the
> default that goes into TR_PROFILE and the override into DS_PROFILE?).
> In any case - if we make the columns NOT NULL and default them to "tr" and
> "edge", I'm +1 on columns in the deliveryservice table.
>
> Cheers,
> JvD
>
> On Fri, Aug 4, 2017 at 7:12 AM Eric Friedrich (efriedri) <
> efrie...@cisco.com>
> wrote:
>
> Hey Rawlin-
>Zhilin has also been working on a very similar feature which was
> proposed on this mailer last month:
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f
> 3897da37ef5b24ac452a17cabb@%3Cdev.trafficcontrol.apache.org%3E
> <
> https://lists.apache.org/thread.html/51d7ed1ae65a3697c39edd00236e6f
> 3897da37ef5b24ac452a17cabb@
> >
>
> Can you please work him to ensure we don’t duplicate work and that if both
> solutions are needed they will work together?
>
> On Aug 3, 2017, at 3:57 PM, Peters, Rawlin  mailto:rawlin_pet...@comcast.com>
> >
> wrote:
>
> Sorry, Outlook converted my numbered list poorly. I’ve corrected the
> numbering (items 1-3) below.
>
> On 8/3/17, 1:52 PM, "Peters, Rawlin"  rawlin_pet...@comcast.com> rawlin_pet...@comcast.com>> wrote:
>
> Hello All,
>
> I’ve been working on adding support for configurable per-CDN and
> per-DeliveryService routing names [1] (what are currently
> hardcoded/defaulted to ‘edge’ and ‘tr’ for DNS and HTTP Delivery Services,
> respectively), and I have a few things to propose.
>
>
>   1.  Add a column to the CDN table for the DNS and HTTP routing names.
>
>
>
> I’ve currently been working off the assumption that per-CDN routing
> names would be configurable by adding ‘http.routing.name’ and ‘
> dns.routing.name’ parameters to a profile of type TR_PROFILE using the
> ‘CRConfig.json’ config file. To me this seems like bad UX because the user
> has to click through multiple steps and fill in multiple fields in the UI
> just to change the CDN’s routing names. It also requires joining a few
> different tables in the DB just to find the parameters per-CDN. For that
> reason, I think it would be better if ‘dns_routing_name’ and
> ‘http_routing_name’ were added as columns of the ‘cdn’ table, and changing
> them via the UI would follow the same process as choosing the CDN’s domain
> name. Because the routing names would be the CDN-wide defaults, the ‘Edit
> CDN’ window feels like the most natural place to put it.
>
>
>   2.  Values for per-DeliveryService routing names could live in one of
> a couple different areas:
>  *   New columns in the delivery_service table
>  *   Parameters in a DS Profile
>
> As the developer, my vote would be for Option A because it seems like
> it would lead to cleaner code in Traffic Ops because the routing names
> would be readily-available when handling a DeliveryService. You wouldn’t
> have to also fetch its profile then dig through it to find the routing
> names. A downside could be that adding columns to an already-overcrowded
> table isn’t ideal.
>
> Option B is less appealing to me but might have some advantages such as
> keeping the number of columns down i

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: 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: 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: 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
>

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: TC 2.2 Release - Outstanding Issues

[David Neuman]

Jeff is planning to open a PR to actually fix the leak or to update the
server.xml to use the BIO connector?

On Tue, Jan 30, 2018 at 9:39 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> Thanks Dave-
>   I’d like to keep it as a must-have in 2.2. We had a severe issue in
> production with the NIO connection when deploying 2.1. Jeff M is planning
> to open a PR to fix it in the 2.2 release.
>
> I understand the issue will be moot after upgrading to Tomcat, but the
> current 2.1 release has crippling TR scale problems out of the box and I’d
> like to avoid that with 2.2 given how small and low risk the fix is
>
> —Eric
>
> > On Jan 29, 2018, at 5:36 PM, Dave Neuman  wrote:
> >
> > Thanks Rob,
> > I think `916 [TC-197] File descriptor leak caused by NIO protocol
> > connector` should be moved to 2.3.  This issue will be resolved with the
> > upgrade to Tomcat 8.5.x.
> > I don't think we should hold up the release for `1356 Step by Step
> > installation guide for new users`.  I think it can be moved to 2.3 as
> > well.
> > I took a look at the issues in 2.3 and I am fine with what's there
> staying
> > there.
> >
> > Thanks,
> > Dave
> >
> > On Mon, Jan 29, 2018 at 11:47 AM, Robert Butts  wrote:
> >
> >> There are no `major` bugs without milestones, now.
> >>
> >> Many issues without milestones were moved from 2.1 to 2.2, and I moved
> them
> >> to 2.3 indiscriminately. We should verify they're ok to not be in 2.2.
> >>
> >> Traffic Ops
> >> --
> >> 1026 [TC-191] Steering DS API should use standard response codes as
> defined
> >> in API guidelines
> >> 913 ort does not restart ATS when it should
> >> 911 Invalid DS regex causes nasty exception and unexpected results
> Github
> >> Issue #514
> >> 905 Inactive delivery services are added to remap.config
> >> 902 api/1.2/deliveryservices/:id/routing.json hangs when Traffic
> Router is
> >> unreachable
> >> 899 IPv6 Origin Configuration Not Allowed
> >> 898 Clone DS assignments button on Server times out
> >> 896 Traffic Router statistics are not aggregated
> >> 892 GenIso can't handle concurrent requests
> >> 891 error_url required in the url_sig file
> >> 890 Should use "dest_ip" instead of "dest_domain" in "parent.config" and
> >> "cache.config" when ofqdn is ip
> >> 888 cacheurl_qstring.conf file is not generated when qstringIgnore=1 and
> >> location profile parameter is missing for edge/mid cache
> >> 885 Fix regression issues caused by TC-187
> >> 882 Deleting a DS thru the TO API should also delete all SSL keys (if
> >> applicable)
> >>
> >> Traffic Router
> >> --
> >> 914 Failed to restart tomcat in Traffic Router when failed to get SSL
> keys
> >> 907 Traffic Router requires at least one cache assigned to at least one
> DS
> >> for TLD zone generation
> >>
> >>
> >> There are 11 open issues in the 2.2 Milestone:
> >>
> >> Code
> >> --
> >> 1777 TO golang -- api/1.3/parameters?orderby=id produces an error
> >> 1620 API: Server API sets xmpp_id to null
> >> 1397 ORT tries to get ats_uid before installing trafficserver
> >> 1042 [TC-242] tm_user.username and role should be NOT NULL in the db
> >> 986 [TC-544] TR should de-dupe Reponse Headers when sending a Steering
> >> response.
> >> 916 [TC-197] File descriptor leak caused by NIO protocol connector
> >>
> >> Documentation
> >> --
> >> 1356 Step by Step installation guide for new users
> >> 1173 'Multi Site Origin Algorithm' is removed in delivery service UI in
> >> traffic_ops in TC-2.1
> >> 1135 Traffic Server administration docs are out of date
> >> 1130 cacheurl is deprecated in ATS 7.x
> >>
> >> Licensing
> >> --
> >> 1750 /traffic_ops/app/public/images/ contains non-free images
> >>
> >>
> >> Do we still feel like we can have all these fixed for a 2.2 Release in 2
> >> weeks? Say, Monday, February 12?
> >>
> >> Are there any cases moved to 2.3 that need to be moved back and done in
> >> 2.2?
> >>
> >> Thanks,
> >>
>
>

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
>
>

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 behavior of falling back to next closest CG).
> > Existing
> > >>

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, which can not exist, not be properly formatted,
> 

[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   
 * 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] 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&op=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and sha512 checksum are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC4
>
>
>
> 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 
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

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&op=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC5
>
>
> Thanks!
>