On 08/07/2018 07:29 AM, Matt Riedemann wrote:
On 8/7/2018 1:10 AM, Flint WALRUS wrote:
I didn’t had time to check StarlingX code quality, how did you feel it while
you were doing your analysis?
I didn't dig into the test diffs themselves, but it was my impression that from
what I was poking around in the local git repo, there were several changes which
didn't have any test coverage.
Full disclosure, I'm on the StarlingX team.
Certainly some changes didn't have unit/functional test coverage, generally due
to the perceived cost of writing useful tests. (And when you don't have a lot
of experience writing tests this becomes a self-fulfilling prophecy.) On the
other hand, we had fairly robust periodic integration testing including
multi-node testing with physical hardware.
For the really big full stack changes (L3 CAT, CPU scaling and shared/pinned
CPUs on same host), toward the end I just started glossing over a lot of that
because it's so much code in so many places, so I can't really speak very well
to how it was written or how well it is tested (maybe WindRiver had a more
robust CI system running integration tests, I don't know).
We didn't have a per-commit CI system, though that's starting to change. We do
have a QA team running regression and targeted tests.
There were also some things which would have been caught in code review
upstream. For example, they ignore the "force" parameter for live migration so
that live migration requests always go through the scheduler. However, the
"force" parameter is only on newer microversions. Before that, if you specified
a host at all it would bypass the scheduler, but the change didn't take that
into account, so they still have gaps in some of the things they were trying to
essentially disable in the API.
Agreed, that's not up to upstream quality. In this case we made some
simplifying assumptions because our customers were expected to use the matching
modified clients and to use the "current" microversion rather than explicitly
specifying older microversions.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
