[openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis
Chris Friesen
chris.friesen at windriver.com
Mon Aug 13 19:10:37 UTC 2018
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
More information about the OpenStack-dev
mailing list