checksums and
> signature, but the email still mentions md5 and sha1 checksums -- only
> sha512 checksum and pgp signature are there. I think the correct files are
> provided and the email is incorrect.
>
> -dan
>
> On Fri, May 11, 2018 at 12:22 PM Robert Butts <r...@apache.org>
Hello All,
I've prepared a release for v2.2.0-RC6
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:
At the summit, I presented a plan for automated change integrity (the
"snapshot-queue" problem).
The technical spec is on the wiki at:
https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity
Solving the "snapshot-queue" problem is just one of
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:
awlin
>
> On Thu, Apr 26, 2018 at 12:27 PM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
> >>client methods take the Foo struct as input rather than the FooNullable
> > struct, so it's impossible to create a request with null fields
> >
> > It's a leg
>client methods take the Foo struct as input rather than the FooNullable
struct, so it's impossible to create a request with null fields
It's a legacy artifact. You're right, it's a serious limitation, it's just
never been a priority to fix.
The client is a public interface to the API, we can't
@weifensh We're hoping to have most of the API endpoints, not including ATS
config files, in the next month or so. I'm currently working on
`deliveryservices`, and @dylanvoltz is on `servers`, the two biggest, and
they're both mostly done. They should be code-complete by the end of next
week, and
> +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 <r...@apache.or
Technically, adding new routes does not break old stuff right so i
> don't
> > > think that warrants a major version roll.
> > >
> > > While we're on the subject, what does everyone think if we took this
> one
> > > step further and made routes
ll conform to SemVer for the same major
version, e.g. 1.3.
On Wed, Apr 4, 2018 at 4:12 PM, Robert Butts <robert.o.bu...@gmail.com>
wrote:
> You're right, in our code today, we don't use raw major versions
> (/api/1/foo) in our API, and our clients have hard-coded minor versions.
>
&
s route at all and
> would require
> new dev work to support, or maybe I am misunderstanding you?
>
> On 4/4/18, 3:49 PM, "Robert Butts" <robert.o.bu...@gmail.com> wrote:
>
> >Technically, adding new routes does not break old stuff right so i
> don't
>
update
> DELETE /foos <-- takes in an array of foos to delete
>
> in this scenario, query params only pertain to the GET. The POST, PUT and
> DELETE rely on the contents of the request json...
>
> Jeremy
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Apr 4
That document doesn't mention versions, 1.2 vs 1.3 vs 2.0.
Just to clarify, changing to query parameters breaks compatibility with 1.2
and older, so new APIs in that format have to be a new major version, i.e.
2.0, per Semantic Versioning, right?
On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell
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:
@nbaoping
> So I suggest the change to the current TM to be like:
> 1) Separate the current polling of cache servers into two different
pollings, one for the keep alive, the other for the stat query.
The Golang Monitor already does this. We call it the "health" and "stat"
polls in the code. The
Hello All,
I've prepared a release for v2.2.0-RC3
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:
rves a longer dev@ email.
> >
> > I will oversimplify: we are extending TC to support multiple IPv4 (or
> > multiple IPv6) addresses per edge cache (across 1 or more NICs).
> >
> > Assume all addresses are reachable from the TM.
> >
> > —Eric
> >
> &
When you say different interfaces, do you mean IPv4 versus IPv6? Or
something else?
If you mean IPv4 vs IPv6, we have a PR for that from Dylan Volz
https://github.com/apache/incubator-trafficcontrol/pull/1627
I'm hoping to get to it early next week, just haven't found the time to
review and test
Ah, thanks for the clarification.
Ok, the 2.0.0 RPMs have been removed from dist, and the webpage links
updated to archive.apache.org.
On Mon, Mar 19, 2018 at 5:48 PM, sebb <seb...@gmail.com> wrote:
> On 19 March 2018 at 19:01, Robert Butts <robert.o.bu...@gmail.com> wrote:
>
Hello Incubator PMC,
The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 2.2-incubating. We now
kindly request that the Incubator PMC members review and vote on this
incubator release.
The VOTE RESULT is here:
gt; - Upgraded Traffic Stats (2.2.0.d7e588 -> 2.2.0.6ea850) CentOS 6
> > - Upgraded Traffic Ops ORT
> > - mid cache "report" and "badass" mode seem to work correctly
> > - edge cache "report" and "badass" mode seem to work correctly
> &g
Hello All,
I've prepared a release for v2.2.0-RC2
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:
-1 on "DS requests" long-term, post real Self Service, because there's no
need, it's unnecessary complexity.
More complexity means more code to maintain, more bugs. More complexity to
maintain in the database. It's also more UI complexity, which means more
tenants have to learn, more to get
Hello All,
I've prepared a release for v2.2.0-RC1
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:
Hello All,
I've prepared a release for v2.2.0-RC0
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:
Just a reminder, the 2.2 Release is scheduled for next Monday, February 12
Open Pull Requests:
1769 Monitor Stats Format Plugin For Delivery Service Names
1768 Add Traffic Monitor Plugin System for Cache Stats Formats
1844 DeepCachingType -- "NEVER" is now default
1825 updated docs to add some
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
this from happening?
Are there any features that can be wrapped up and go into this version?
Any other comments or suggestions?
Thanks,
Robert Butts
t;type".
> So yes, given that the host in the stat is the origin, a single word is a
> valid domain, hence it is not possible to auto-detect it.
>
> I believe that adding a parameter to the server profile is the way to do
> this.
>
> Thanks !
>
> Oren.
>
> On
Traffic Control needs. Which we're looking into doing, rather than
maintaining a completely separate fork. But, as above, it may be difficult
to extend either to have the DS Name. Hopefully I'm wrong.
On Tue, Jan 2, 2018 at 9:35 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:
> >
t; astats/stats_over_http, and I am sure there are several other features
> > would be nice to have as well, but I don't think we should be muddying
> the
> > waters with that right now.
> >
> >
> > On Wed, Dec 27, 2017 at 12:24 PM, Robert Butts <robert.o.bu...@gmail.co
I'd be +1 if we extend Astats/stats_over_http to have the DS name.
It's easy to extend the Monitor to get the name from a field, if it's
available. And it should be faster than the current method. But, Astats
doesn't currently support it, and in fact, I don't believe ATS has a good
way to
AM, Dave Neuman <neu...@apache.org> wrote:
> I merged it, you need to do a backport to 2.1 as well.
>
> On Tue, Dec 19, 2017 at 9:16 AM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
>
> > PR updating the license:
> > https://github.com/apache/incubator-traff
; forever. I encourage you to contribute to the thread on the legal
> mailing
> >>> list to make your case or at least get an understanding of their
> >>> requirements. The ASF does tend to lean toward conservative
> interpretations.
> >>>
>
+1 This is immensely valuable, thanks for putting all this work in to fix
our Trafficcontrol license pains! Sorry about the slow response, looks like
this is a classic case of Lazy Consensus.
>a particular emphasis on whether vendoring is a suitable solution for
executables instead of libraries.
but didn't find it
> > with a quick search. Is it possible it's provided by an rpm we could
> > list as a dependency rather than including in our source?
> >
> > -dan
> >
> > On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts <robert.o.bu...@gmail.com
> <mailto
I'd really like to keep this, or replace it with a similar file from
another source. Which I'd be willing to investigate, if necessary.
Having a good blacklist of most-common passwords specifically puts Traffic
Ops in compliance with NIST SP 800-63B.
I also don't understand the objections, the
follow this link:
> > >
> > > https://github.com/apache/incubator-trafficcontrol/
> > > pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+milestone%3A2.2.0
> > >
> > > -Dew
> > >
> > > On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek &
+1 on a "changelog" label. Seems like that would make it a lot easier for
the person writing it up. Easier to skip things like code maintenance that
have no interface effect.
On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson
wrote:
> Another idea would be to include a new
If the field only applies to some DS types, it should be in its own table.
Then it can be NOT NULL in that table, ideally with a constraint requiring
the DS to be a type it applies to. You wanted to reduce the columns in the
`deliveryservice` table, right? Here's your chance :)
On Wed, Nov 15,
Seconded. Definitely +1 if you can do that migration in SQL. I think it's
possible, but not easy. CTEs/With should help. But I wouldn't be -1 on (2)
if you decide (1) isn't feasible.
On Thu, Sep 14, 2017 at 10:20 AM, Jan van Doorn wrote:
> The go migration is my fault…. I
I am a pretty big -1 on sqlx. Those PRs are extremely deceptive.
Those lines are entirely unnecessary.
I have created an example PR at https://github.com/apache/incu
bator-trafficcontrol/pull/1165
The relevant commits are
https://github.com/apache/incubator-trafficcontrol/pull/1165
+1
> 1. Github * Has very little in the way of organizational options
I view Github's simplicity as a plus. Jira has a steep learning curve, and
is discouraging to potential new committers. Every separate tool we have
(issues, wiki, docs) are more obstacles to new people. Github's built-ins
+1
A new requirement is a breaking change, needs to be a new major version, or
a default value that doesn't break existing usage.
On Tue, Aug 15, 2017 at 8:40 AM, Dewayne Richardson
wrote:
> This is a tough one because the obvious ways of breaking an API are "URL
> format
over time the extreme pain of Carton will disappear as well, as for
>> "downloadwebdeps" will also disappear because of Jeremy's new TO UI v2.
>> So, really it'll be a small postinstall wrapper that basically sets up the
>> database (with a default admin user) and minimal
ving to a
non-perl alternative. From an administrator's perspective, anything that
helps me avoid perl module dependency tangles is a win.
__Jason
On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts <robert.o.bu...@gmail.com>
wrote:
I'd like to propose a plan for rewriting Traffic Ops in Go
DAP?
> My
> > > understanding is we created LDAP access to allow external users in to
> see
> > > our TO Graphs. Now that graphs are in Graphana is the need for LDAP
> > still
> > > needed? If we require anyone using TO or the TO API to be in th
rity issue entirely.
> >
> > I also wonder if we shouldn't try to leverage transitioning our user
> > management to Postgres. Postgres has many options for authentication
> (as I
> > mentioned at the Summit), which would allow for more flexibility at TO
> > inst
> Is there an option to entirely block someone from even basic TO access
despite authenticating with LDAP?
Other than disabling LDAP? No. I wouldn't object to adding a config, but I
don't know when I'd be able to find the time. The current version allows
entire read-only access, so this PR isn't
We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627 to
change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops
database to view non-sensitive information, like graphs and total CDN
bandwidth.
To be clear, users will still be able to authenticate with LDAP, as
+1
IMO Github issues, wiki, etc are much, much easier to use than Atlassian
tools.
On Wed, May 17, 2017 at 8:51 AM, Dave Neuman wrote:
> While at ApaceCon, a few of us attended a talk about navigating the
> incubator where we were informed that "full" Github is now available
roxy
> > > auth,
> > > > and make things better than today, where we have the same problem
> that
> > if
> > > > the TO mojo app is compromised, everything is compromised.
> > > >
> > > > If we always route to TO, we don't un
uffer from the same
> issues.
> >
> > I suggest we sit down together at the Summit and decide where to go with
> this..
> >
> > -dan
> >
> > On Mon, May 1, 2017 at 10:37 AM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
> >> +1 on Vendoring. I d
+1 on Vendoring. I don't see a difference if it's 375,000 lines or
10,000,000 lines. What does it matter if it's 375k lines in someone else's
repo or our own? It does matter from a security standpoint. It means we're
now vulnerable if their repo is compromised. We shouldn't be pulling
_anything_
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 <robert.
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.
+1 on Semantic Versioning.
-1 on breaking the existing API again. There's no point versioning if we
make breaking changes without changing the version.
On Fri, Mar 31, 2017 at 2:42 PM, Amir Yeshurun wrote:
> +1 for choosing a versioning philosophy
>
> On Mon, Mar 27, 2017 at
Also -1 on requiring, +1 on recommending. I've worked in environments where
every commit or PR required a case, and it sounds good, but in practice it
often discourages things like code maintenance and fixing technical debt.
> Maybe issue / mailing list discussion required for new features and
Ok, I don't know how much you know, so, sorry if I'm telling you things you
already know, but here goes.
> currently trying to connect a non ATS cache to Traffic Control.
So, Traffic Control involves configuring caches, polling those caches to
determine if they're 'healthy', and routing requests
GitHub user robert-butts opened a pull request:
https://github.com/apache/incubator-trafficcontrol/pull/10
Traffic Monitor 2.0 Improvements
Adds config for server read and write timeouts.
Removes duplicate common API data.
Fixes numerous Linter issues.
You can
60 matches
Mail list logo