+1
I support the goal of making Traffic Control more reliable and think this is a
step in the right direction.
In some of our other products, we’ve had good luck using a circuit breaker as
part of the retry process (https://pypi.org/project/circuitbreaker/, linked
just for algorithm but I’m n
I think this just shifts the burden from writing a changelog entry to writing a
good commit entry.
There might be fewer commit entries if we squash and merge, but I’m doubtful
that it would be as valuable as our “curated” changelogs.
> On Oct 18, 2018, at 9:40 AM, Dave Neuman wrote:
>
>
I’m good with the proposed PR.
Does this increase the likelihood that someone might get their server
parameters wrong (remap_required, reverse_proxy_enabled) etc if we don’t have a
server type match up with a profile type?
Should we consider removing the EDGE/MID server type entirely, replacin
I think some documentation/definitions would be great here as well.
Whats a TO extension vs hook vs data? Are there any examples of how they could
be used?
—Eric
> On Oct 1, 2018, at 1:44 PM, Rawlin Peters wrote:
>
> Can we get a concise README.md on how to create a custom TO plugin
> that
Would the “permissions” field be better titled as “localizationMethods” or
“localizationPolicies"? Permissions typically relates to security and access
control, so it seems a bit out of place here
Also, should we consider adding the fallback list to the allowed localization
methods/policies?
In our commercial GUI, we’ve created the “porcelain” for DS Types. I personally
find it easier to use. I don’t need to go to the docs to pick the right type
from the dropdown
Screenshot: https://cisco.box.com/s/agpflh82j6nv3wusukjdfk22cpgxbbbt
—Eric
On Jun 27, 2018, at 5:24 PM, Rawlin Peter
we
need a dynamic recovery that activates on massive mid-failure. We can’t have a
system outage while waiting for operators to triage the problem, manually make
a DS change and then push that change out to 1000 caches.
—Eric
>
> - Rawlin
>
> On Tue, Jun 26, 2018 at 8:34 PM Eric Fri
Hey Rawlin-
Remember that the proposed feature does not always bypass the mids- we
already have that with the regional DS types. This is just a failure recovery
behavior.
Conflicts with the DS type is only a small part of the major UX problem we
have today relating to Origin FQDNs. Ways we
After spending an hour modifying one of our profiles from ATS6 to ATS7, and
facing down modifying our other 10 profiles. We’ve also received some pretty
sharp feedback from customers on how long it takes to manually make the profile
configuration changes required for a new major ATS version. To
mically do
>> those config files includes at the end. Im no spec expert so Im not sure if
>> there may be a better way but recently here I worked on getting our internal
>> spec and build system to be able to do builds of ATS master and it looks
>> like starting with 8/9 s
I’ve opened a PR to produce Trafficserver and astats RPMs in the Traffic
Control build process. Previously, new users would need to create their own
build environments or ask for RPMS on Slack.
This PR will lower the barrier to entry for new users. For more involved users,
theres now a set of s
be routed to any deep cache groups, even where there is a single server,
> resulting in poor caching efficiency, and more traffic to the mids.
>Does that explain the problem sufficiently?
>~Sergey
>
>
>On 6/5/18, 7:10 PM, "Eric Friedrich (efriedri)" wrot
+1
With the caveat that we maintain an upgrade process when we start deprecating
APIs between components.
—Eric
> On Jun 7, 2018, at 2:11 PM, Dewayne Richardson wrote:
>
> +1, this will allow us to do a better job with the API's
>
> On Tue, Jun 5, 2018 at 10:03 AM Jeff Elsloo wrote:
>
>>
Should we look into creating a common “go builder” container base image that
can be shared by all of the go components?
It would be easier to keep this in a common location rather than having to keep
a bunch of Dockerfiles in sync.
—Eric
> On Jun 7, 2018, at 9:40 PM, Zelkowitz, Evan
> wro
t; In addition to what was mentioned above I think that we should including
> deprecating support for the Traffic Ops UI in 3.0. Once 3.0 is released we
> should only be using Traffic Portal as our UI.
>
> With that being said, +1 on the move to 3.0
>
> Thanks,
> Dave
>
For those of us already on Centos7, what does this mean for compatibility
between TC releases?
On Centos7, will we be able to use 3.0 with 2.x releases as is currently done
today.
If already on Centos7, What is the upgrade story from 2.2 to 3.0?
—Eric
> On Jun 5, 2018, at 12:03 PM, Jeff Elsl
Hey Sergey-
What is the problem that you are experiencing here?
I understand what you are proposing, but am not sure why this is needed. I
would find some more details very useful
Thanks,
Eric
> On Jun 5, 2018, at 5:40 PM, Dremin, Sergey wrote:
>
> We should create an extension to the d
Vote passes, new website is live
—Eric
> On May 18, 2018, at 11:06 AM, Eric Friedrich wrote:
>
> Hey-
> Based on some feedback from the incubator, we put together a new website
> that doesn’t look like its from Geocities.
>
> I’m providing links to all the pages because some of the internal l
18 matches
Mail list logo
