Open Stack

Hi all,

> > Thanks Jeremy.  I assume Chen could follow this example to add a
> > job for the HDFS driver?
> > 
> > https://review.openstack.org/#/c/188744/
> 
> That's a fine short-form answer. The longer answer is to solicit
> input from some of the people who have done similar work, so that
> mistakes can be learned from rather than repeated.
As requested, here's some input from me.

Oh well, where to start? Perhaps at the beginning ...

Openstack has quite a lot of documentation - in Wiki pages, code examples, 
and so on. Navigating all of that (well, even finding the relevant pieces) 
is not that easy - and some parts are wrong in details or contradict each 
other. Unavoidable for a project of this size, but still annoying for 
newcomers.

What I'd very much have liked to see was some big-picture overview how the 
processes and configurations work[1]. Some short description what the files 
in the project-config mean, what they are used for, etc., to get a basic 
understanding how that works _without_ needing to learn all the auxillary 
tools (of which there are quite a few - Zuul, Jenkins, Puppet, ...).

What *I* did get wrong (and this an important point to learn from!) is that 
even things like the devstack plugin name matters. This isn't written 
anywhere, but if you get it wrong then the various jobs won't match the 
generated check & gate scriptlet names anymore, and then there are some 
more hoops to jump through...[2]


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].


But let's get back to the topic - what I have learned, resp. what I did 
wrong, so that others can learn.

The quoted change number above is not enough; I've pushed a few updates 
already, so to get a more complete example it might be better to take 
a checkout and to filter by my changes:

    # git log --committer philipp.marek at linbit.com

Looking at the *combined* diff of that might be a first step. Or perhaps 
not, because of the wrong name...


Another idea that I can pass on is that as soon as you've had the first CI 
run, navigate the logfile directory to fetch the local.conf and 
tempest.conf file (which will be compressed), and to look at them. Some 
small errors might be diagnosed from there[4], without needing to spend 
time looking what goes wrong and why.


Anything else? Hmmm... yeah, the last point I can mention is that people on 
IRC (-infra, for that topic) are very helpful. If you're unlucky, they're 
stressed by other problems and won't have that much time; but generally, 
you'll receive answers quite fast.
(Unless you're in the wrong timezone. AJaeger is very helpful in the CET 
zones - but he's alone [I guess], and so it's a game of luck again. Having 
some more -infra cores distributed around the globe would be nice.)

Well - you have to know to ask the right questions, right. While sometimes 
you'll get extensive answers, in busier times you might get the *exact* 
answer to your question - whether it's helpful in the long term, or not.


Overall, it's been both more awful than expected, and at the same time more 
people help than with other Open-Source projects; I guess I'll have to stop 
here, to avoid starting a rant about another topic.


I hope that helps - at least a little bit.


Regards,

Phil


==

Ad 1: In the last 8 weeks (since starting the CI in -infra) I got some 
ideas; I'm not sure how much is correct, but if there's interest, I can try 
to put them down into a wiki (please point me to some suitable location).

Ad 2: Another thing that is not written down (but could be guessed) is that 
some lists have to be kept in alphabetical order...

Ad 3: Eg. for free if it's an Open Source project, and for a small fee like 
$200 or so for proprietary ones - that's still some major savings for the 
company, compared to spending tens of man-hours trying to get that right.
  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.
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?

Ad 4: Eg., the cinder tests multi-backend tests failed for my driver.
After looking at tempest.conf I figured out (thanks, jgriffith, for telling 
me that too) that they were *wrongly* activated - because I've had 
  -              CINDER_ENABLED_BACKENDS=,drbd:drbdmanage"
  +              CINDER_ENABLED_BACKENDS=drbd:drbdmanage"
A small comma in the setup definition - and several tests fail, instead of 
them getting skipped...

-- 
: Ing. Philipp Marek
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting                 http://www.linbit.com :

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.