Open Stack

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.