Hi,

On 18.05.2017 11:28, Valentine Sinitsyn wrote:
Hi Ananth,

On 17.05.2017 11:21, Ananth Suryanarayana wrote:
On Wed, May 17, 2017 at 11:18:49AM +0500, Valentine Sinitsyn wrote:
Hi Ananth,

On 17.05.2017 11:00, Ananth Suryanarayana wrote:
Hi,

On Wed, May 17, 2017 at 10:50:38AM +0500, Valentine Sinitsyn wrote:
Hi,

Those are valid points. I'd add a few more, if you don't mind:

1. Code quality (esp. in master branch)
I've encountered undefined macros in vrouter-dpdk and shell
escaping issues
in dkms scripts at the very least. Sure, this is trivial to fix,
yet it
makes me think that either no one tried to compile those components
besides
me (as this fails immediately) or I do something awfully wrong.
Which brings
us to the second point:

2. Public CI, maybe via Travis/Github badge
This is to make sure the code works at least in some environment,
so I can
figure out what's wrong with mine. Aside issues mentioned above,
BGP stress
test is failing now as well, and there is no way to figure out is
it my
fault or the thing is currently broken.
I can certainly help out with bgp_stress_test failure. It is part of
our
regular CI and is run for every commit applicable. May be it is not
working
under some specific set of parameters that you are using with ? May
I request
for more details regarding this ?
Thank you for the help. Above, I've used BGP stress test mainly to
illustrate my points, yet it of course would be good to fix this
particular
issue as well. I tried it some time ago; will do it again and come
back with
results and details to you shortly.

Thanks. I look forward to hearing from you.
OK, I re-ran the test (src/bgp:bgp_stress_test_suite), on another (more
powerful) box this time. No test failed, yet some time out.
bgp_stress_test2 seems to time out randomly: you can have it passed on
one run and timed out on another. I'm not 100% sure, but failed tests I
was getting previously (on less powerful box) were likely OOM aborts.
For timeouts, I'm using settings shown at [a], that is, 3000 seconds.

So, in the nutshell:
1. Tests are likely not broken, which is good;
2. Another +1 for public CI which make it straightforward to see that
tests are not broken.
I overlooked the fact there is already some CI on https://jenkins.opencontrail.org/ Sorry for that.

Valentine

3. Maybe outline hardware requirements and running time expectations for
stress test.  The public CI can also serve as a reference environment
here. This is of course a nit compared to rather general issues the
topic starter raised.

a. https://github.com/Juniper/contrail-controller/wiki/BGP-Stress-Testing

Thanks,
Valentine


Regards
Ananth


_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org

Reply via email to