I can meet Thursday this week. Thanks, Narayan
On Tue, Nov 18, 2014 at 9:30 AM, Joshua Blatt <bla...@yahoo-inc.com.invalid> wrote: > Hi guys, > Sorry I've been slow setting this up, but before this slips away from us, > is anyone up for a meeting this week? Say Thursday sometime between 11am > and 4pm? > We could do this in person and I'm happy to host a meeting at the Yahoo > office in Sunnyvale, but if transit time makes it too difficult, I think a > phone call would work well too. Brian, Narayan, Cynthia, anyone else? > Thanks, > Josh > > > On Tuesday, November 4, 2014 3:09 PM, Cynthia Gu > <czhen...@linkedin.com.INVALID> wrote: > > > Brian, > > Just some thoughts on collaboration. Most of the contributors are local is > definite something advantage we can take. Since it’s a framework, we > probably need some initial meetings/phone calls to come up with a robust > easy-to-use framework. After that, we can start to implement test cases > individually. > > Cynthia > > On 11/4/14, 10:54 AM, "Narayan Balasubramanian (நாராயண் )" > <bv.nara...@gmail.com> wrote: > > >Brian, > > > >Agree with Josh. You have captured the requirements well. > > > >AFAICT, most of the contributors are local - LinkedIn, Apple and Yahoo. > >Phone call, irc is all good. We can even meet to nail this. > > > >Thanks, > >Narayan > > > > > >On Tue, Nov 4, 2014 at 10:01 AM, Brian Geffon <bri...@apache.org> wrote: > > > >> Hi All, thanks for your patience I know many people are eager to start > >> pooling resources to make this happen. (Thanks Susan for helping with > >>notes > >> during the summit) > >> > >> To briefly summarize what was discussed at the summit, we have an > >>existing > >> framework called TSQA which is based on bash, while this is a nice start > >> it's not really what we need. Josh Blatt hacked together a prototype in > >> NodeJS, but I think the consensus was that the tooling and existing code > >> for Python would result it in being a better language choice, it seemed > >>to > >> be a more-or-less unanimous agreement (were there any objections to > >>using > >> Python?). > >> > >> With the language defined, we outlined the following high level > >> requirements: > >> - It must be very easy to write simple tests (ie. basic http get -> > >>proxy > >> -> simple http origin). > >> - It must be expressive enough to handle complex test cases (ie > >>testing > >> an ESI plugin or advanced networking cases such as sending a FIN > >>randomly). > >> - Such a framework MUST allow for integration testing plugins. > >> - We must be able to bootstrap trafficserver with relevant configs and > >> plugins. > >> - We must have a port manager that is shared between each component of > >> the integration test. > >> - We would punt on multiple OS support to start in favor of developing > >> something more generally useful to start. However, at some point in the > >> future it would be nice to have. Thus design decisions shouldn't be > >>linux > >> specific with the end goal of supporting multiple OSes. > >> - This framework will run in our existing CI environment, thus > >>existing > >> testing frameworks for generating reports suitable for Jenkins is a > >>must. > >> > >> Other issues raised during this session were: > >> - Using such a framework for perf testing, most people agreed this > >>should > >> be considered separately from this testing framework. > >> - We should investigate what other proxies are using before > >>development > >> begins to determine if we can reuse/share components if the goals of our > >> framework aligns with an existing framework. > >> - The following wiki page exists related to QA: > >> https://cwiki.apache.org/confluence/display/TS/Quality+Assurance > >> > >> Please feel free to respond if I left anything out or if I in anyway > >> misstated the discussions at the summit. > >> > >> Now moving along to the fun part. Several people have expressed > >>interest in > >> this project, which is awesome, but let's all coordinate. Let's work > >> together and make something great that can really benefit the entire > >> community. Does anyone have suggestions for how we can coordinate and/or > >> deal with task distribution? Obviously Jira should be used for tasks, > >>but > >> should we do regular IRC check-ins and summarize those discussions on > >>the > >> mailing list? Ideas? > >> > >> Brian > >> > > > > >
