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.ma...@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.
__________________________________________________________________________
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
