On 06/11/2015 10:34 AM, Jeremy Stanley wrote:
On 2015-06-11 07:51:55 +0200 (+0200), Philipp Marek wrote:
[...]
I still stand by my opinion (as voiced in Vancouver) that for such
one-off things (that contributors are not likely to repeat over
and over again) it might make sense to have -infra simply *do*
them[3].
[...]
To reiterate my response from the summit, it's a neat idea but not
one the Infra team has the bandwidth to entertain at the moment. As
you've noticed we're understaffed and while we're continually trying
to grow the team it takes many months to a year or more of full-time
exposure to our current systems to bring new people up to speed to
help us run it. Also we don't actually have a holistic view of the
underlying tests being run by the jobs... for that you need to
elicit assistance from the QA team who maintain DevStack/Tempest and
did the plugin design for things like out-of-tree driver testing,
and also the project teams for the software at which these drivers
and backends are targeted.
So while I and others are happy to have our CI run jobs to test
OpenStack drivers for other free software backends, don't expect the
actual work and learning curve to necessarily be any less than
building your own CI system from scratch (just different).
It doesn't make sense to require people to learn about things they
will never use again - and the amount of time spent answering the
questions, diagnosing problems and so on is quite a bit higher
than doing it simply right the first time.
This is, I think, also a common misconception. The people who write
these jobs to run in our CI need to stick around or induct
successors to help maintain them and avoid bitrot as our systems
constantly change and evolve. I know the same goes for the drivers
themselves... if people don't keep them current with the OpenStack
software into which they're integrating, support will quickly be
dropped due to quality control concerns.
I strongly agree here. I think that the cinder community has shown that
the one of the main values of universal vendor CI is that it keeps
driver maintainers engaged with the community and aware of ongoing
development. OpenStack projects are not a static target which you can
write a driver for once and be done. We are adding new features and
making enhancements every release, and some of those changes require
drivers to evolve too. At the very least CI systems allow us to validate
that the introduction of a new feature didn't break any existing drivers.
For a pure-software based storage backend like HDFS, we can leverage the
compute resources of openstack-infra, but the development resources
still need to come from the Manila team -- the same group people
responsible for maintaining the driver and fixing bugs should have some
understanding of the automated test system because it will be finding
bugs and we'll have to reproduce failure and debug them. If nobody is
willing to do this on an ongoing basis for a backend like HDFS, then
eventually we won't be able to support it anymore. The CI requirement
just makes this fact more explicit and forces us to either commit the
resources or remove the driver rather than waiting until the driver is
horribly broken in a few years.
And if it's *that* often needed, why not write a small script
that, given a name, does the needed changes, so that only a commit
& review is needed?
[...]
Definitely something that people who have experience writing these
could collaborate on contributing. As I mentioned, the Infra team
doesn't have the complete picture, but the people who have sweated
and bled to get their drivers tested and integrated do, at least to
a greater extent than we do.
This is all to say I understand the frustration, but I don't have a
simple solution for it unfortunately.
__________________________________________________________________________
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
