This vote has passed with a +6.
Thanks everyone.
Hank
On 11/20/2017 11:02 PM, Dave Neuman wrote:
Replying to the correct email this time!
+1 However....
We need to add a release note suggesting that traffic stats works best with
influxdb version < 1.3.x. As of 1.3.x InfluxDB now returns a 400 response
when the client attempts to write points that are outside of the retention
policy. When this happens, Traffic Stats seems to hold on to the "old"
points and attempts to write them again on the next POST. This causes what
is essentially a memory leak in Traffic Stats since it continues to hold
onto and tries to write stats that are outside of the retention policy.
This may or may not affect a user, depending upon which stats they are
trying to write to influxdb. For example, we write the wrap_count to
influxdb, this is a stat that does not often change within 24 hours, so we
see the memory leak with stats not written on each poll of traffic stats.
In versions < 1.3.x InfluxDB would still not write the point, but it would
accept the write request and just drop the points outside of the retention
policy on the floor.
This is fixed here:
https://github.com/apache/incubator-trafficcontrol/pull/1289and will be in
the next release of traffic control.
Also, we should note that you need to set selinux to "unenforcing" in order
to get the build to work, otherwise you fail on permissions erros. You can
do this with
`setenforce 0` as root.
Thanks,
Dave
On Mon, Nov 20, 2017 at 12:50 Dan Kirkwood <[email protected]> wrote:
+1 -- I checked signature, checksums, build, fresh install of traffic_ops.
-dan
On Wed, Nov 15, 2017 at 7:21 AM, Hank Beatty <[email protected]> wrote:
Yes, of course. How does Friday 11/17 or Monday 20/17 sound?
On 11/14/2017 04:09 PM, Dave Neuman wrote:
Hey Hank,
It looks like you have the votes you need to pass, but can you leave it
open a little longer for those of us that haven't gotten a chance to
test
yet?
Thanks,
Dave
On Tue, Nov 14, 2017 at 12:47 PM, Eric Friedrich (efriedri) <
[email protected]> wrote:
I’m +1 as well
Checked out:
- signatures/checksums (Hank is your key signed yet?)
- licenses
- build
—Eric
On Nov 14, 2017, at 2:36 PM, Nir Sopher <[email protected]> wrote:
+1
We were able to build traffic-control, install and connect OPs,
Portal-V2,
Monitor (Golang), Router and Stats.
Also got a redirect.
Note that I missed the last commit ("Change cdn.name to
cdn.domain_name
in
DeliveryServiceInfoForDomainList"), but as far as I see it could not
break
the installation.
Nir
On Tue, Nov 14, 2017 at 8:10 PM, Eric Friedrich (efriedri) <
[email protected]> wrote:
Thanks Matt-
I found another LEGAL ticket (https://issues.apache.org/
jira/browse/LEGAL-330) based on a Google version of the PATENTS file
this
time.
Looks like things are OK to use then.
—Eric
On Nov 14, 2017, at 12:50 PM, Mills, Matthew <
[email protected]
<
mailto:[email protected]>> wrote:
FYI, Go itself has the same file
https://github.com/golang/go/blob/master/PATENTS
On 11/14/17, 10:36:43 AM, "Eric Friedrich (efriedri)" <
[email protected]>
wrote:
I’ve been going through licensing for the 2.1 release and found
this
file:
./traffic_stats/vendor/golang.org/x/net/PATENTS<http://
golang.org/x/net/PATENTS>
This looks like it places some of the same restrictions that
caused
the
whole Facebook React.js and rocksDb controversy a few months ago.
Fun reading here: https://issues.apache.org/jira/browse/LEGAL-303
There’s some in depth discussion of the detailed Facebook
license, I
can’t even begin to speculate how that compares to this Google
conditional
patent grant.
We can see what the IPMC/Legal thinks or maybe just remove the
code?
—Eric
