Microserver

[Walt Karas <wk...@verizonmedia.com.INVALID>]

For testing, should we replace the Microserver with a dedicated instance of
traffic_server that we populate with PUSH requests?  It would be one less
thing to maintain.

Re: Microserver

[Alan Carroll <so...@verizonmedia.com.INVALID>]

Well, there would be two instances of ATS running, one as the "server" and
another as the test object. I think the bigger problem is that your testing
is much less reliable, since errors could get dropped between the two
instances of the same software, or be hard to track down. You get better
results with different code bases interacting, because the error tend to be
different. Is the micro server maintenance that much of a burden? As far as
I know, it's mostly been about performance tweaks rather than normal
maintenance.

On Thu, Apr 25, 2019 at 8:21 AM Miles Libbey <ml...@apache.org> wrote:

> Hi Walt-
> Since ATS is a proxy cache, this would prevent testing of proxying,
> revalidation, and even many initial cache writes (chunked encoding,
> read-while-write...).
>
> miles
>
> On Wed, Apr 24, 2019 at 11:01 PM Walt Karas
> <wk...@verizonmedia.com.invalid> wrote:
> >
> > For testing, should we replace the Microserver with a dedicated instance
> of
> > traffic_server that we populate with PUSH requests?  It would be one less
> > thing to maintain.
>

Re: Microserver

[Miles Libbey <ml...@apache.org>]

Hi Walt-
Since ATS is a proxy cache, this would prevent testing of proxying,
revalidation, and even many initial cache writes (chunked encoding,
read-while-write...).

miles

On Wed, Apr 24, 2019 at 11:01 PM Walt Karas
<wk...@verizonmedia.com.invalid> wrote:
>
> For testing, should we replace the Microserver with a dedicated instance of
> traffic_server that we populate with PUSH requests?  It would be one less
> thing to maintain.

Re: Microserver

[Kees Spoelstra <ks...@we-amp.com>]

The codebase of the microserver is easier to debug and less volatile than
ATS, you'd want the codebase on that side to be reliable.
We should also worry about subtly changing behaviour of the ATS origin
which would break the tests not so subtly I guess.
Making the origin a moving target might not be a good idea...

On Thu, 25 Apr 2019 at 16:35, Walt Karas <wk...@verizonmedia.com.invalid>
wrote:

> It seems unlikely that an error in one trafficserver instance would correct
> an error in the other.
>
> On Thu, Apr 25, 2019 at 9:21 AM Jason Kenny <jk...@verizonmedia.com>
> wrote:
>
> > No,
> >
> > The issue here is that if trafficserver is broken we test with broken
> > trafficserver that could result in everything passing.
> >
> >
> >
> > On Wed, Apr 24, 2019 at 10:02 AM Walt Karas
> > <wk...@verizonmedia.com.invalid> wrote:
> >
> >> For testing, should we replace the Microserver with a dedicated instance
> >> of
> >> traffic_server that we populate with PUSH requests?  It would be one
> less
> >> thing to maintain.
> >>
> >
>

Re: Microserver

[Walt Karas <wk...@verizonmedia.com.INVALID>]

It seems unlikely that an error in one trafficserver instance would correct
an error in the other.

On Thu, Apr 25, 2019 at 9:21 AM Jason Kenny <jk...@verizonmedia.com> wrote:

> No,
>
> The issue here is that if trafficserver is broken we test with broken
> trafficserver that could result in everything passing.
>
>
>
> On Wed, Apr 24, 2019 at 10:02 AM Walt Karas
> <wk...@verizonmedia.com.invalid> wrote:
>
>> For testing, should we replace the Microserver with a dedicated instance
>> of
>> traffic_server that we populate with PUSH requests?  It would be one less
>> thing to maintain.
>>
>