Open Stack

On 03/04/2016 03:23 PM, Emilien Macchi wrote:
> That's not the name of any Summit's talk, it's just an e-mail I wanted
> to write for a long time.
>
> It is an attempt to expose facts or things I've heard a lot; and bring
> constructive thoughts about why it's challenging to contribute in
> TripleO project.

hi Emilien,

thanks for bringing this up, it's not an easy topic and yet of most 
crucial. As a core contributors I feel, to some extent, responsible for 
the current status of things and I think it's time for us to reflect 
more about what we can, individually, do.

I have some ideas but I want to start by commenting to your points.

> 1/ "I don't review this patch, we don't have CI coverage."
>
> One thing I've noticed in TripleO is that a very few people are involved
> in CI work.
> In my opinion, CI system is more critical than any feature in a product.
> Developing Software without tests is a bit like http://goo.gl/OlgFRc
> All people - specially core - in the project should be involved in CI
> work. If you are TripleO core and you don't contribute on CI, you might
> ask yourself why.

Agreed, we need more 'eyes' on out CI to cope with both the infra and 
the inavoidable failures due to changes/bugs in the puppet modules or 
openstack itself.

But there is more hiding behind this problem ... we already have quite a 
number of optional and even pluggable features in TripleO and we're even 
designing an interface to make this easier; testing them all isn't going 
to happen. So we'll always hit something we don't have coverage for.

Let's have a conversation on how we can improve coverage at the summit! 
Maybe we can make simply make our CI scenarios more variegated/complex 
in the attempt to touch more features?

> 2/ "I don't review this patch, CI is broken."
>
> Another thing I've noticed in TripleO is that when CI is broken, again,
> a very few people are actually working on fixing failures.
> My experience over the last years taught me to stop my daily work when
> CI is broken and fix it asap.

Agreed. More eyes and more coverage to increase its dependability.

> 3/ "I don't review it, because this feature / code is not my area".
>
> My first though is "Aren't we supposed to be engineers and learn new areas?"
> My second though is that I think we have a problem with TripleO Heat
> Templates.
> THT or TripleO Heat Templates's code is 80% of Puppet / Hiera. If
> TripleO core say "I'm not familiar with Puppet", we have a problem here,
> isn't?
> Maybe should we split this repository? Or revisit the list of people who
> can +2 patches on THT.

Not sure here, I find that manifests and templates are pretty much 
"meant to go together" so I am worried that a split could solve some 
problems but also cause others.

This said, let's be honest, an effective patch for THT requires a good 
understanding of many different problems which can be TripleO specific 
(eg. implications on upgrades), tooling specific (eg. Heat/Puppet), 
OpenStack specific (eg. cooperation with other, optional, features) so I 
have myself skipped changes when I didn't feel comfortable with it.

But one problem which I think is more recently slowing reviews and which 
is somewhat concause of 3) is that we're not dealing too well with code 
duplication in the yamls and with conditional logic in the manifests.

Maybe we could stop and think a together about new HOT functionalities 
which could help us? Interesting for the summit as well?

> 4/ Patches are stalled. Most of the time.
>
> Over the last 12 months, I've pushed a lot of patches in TripleO and one
> thing I've noticed is that if I don't ping people, my patch got no
> review. And I have to rebase it, every week, because the interface
> changed. I got +2, cool ! Oh, merge conflict. Rebasing. Waiting for +2
> again... and so on..
>
> I personally spent 20% of my time to review code, every day.
> I wrote a blog post about how I'm doing review, with Gertty:
> http://my1.fr/blog/reviewing-puppet-openstack-patches/
> I suggest TripleO folks to spend more time on reviews, for some reasons:
>
> * decreasing frustration from contributors
> * accelerate development process
> * teach new contributors to work on TripleO, and eventually scale-up the
> core team. It's a time investment, but worth it.

I'm inclined to think that this is a bit of a consequence of 1), 2) and 
3) together.

> In Puppet team, we have weekly triage sessions and it's pretty helpful.

Right. I think we experimented with something like this before but it 
was probably perceived as an emergency measure so we put it on a side 
after a while.

I remember we had a list of 'hot reviews' which we would review during 
the weekly meetings. But it isn't trivial to understand which type of 
review is considered hot. What is the purpose of the puppet team 
triaging? To find old reviews? Mergeable reviews? To dropping stale 
reviews? To speed up bug fixes? To get attention on features?

> 5/ Most of the tests are run... manually.
>
> How many times I've heard "I've tested this patch locally, and it does
> not work so -1".
>
> The only test we do in current CI is a ping to an instance. Seriously?
> Most of OpenStack CIs (Fuel included), run Tempest, for testing APIs and
> real scenarios. And we run a ping.
> That's similar to 1/ but I wanted to raise it too.

I'd say a consequence of 1) as well

> If we don't change our way to work on TripleO, people will be more
> frustrated and reduce contributions at some point.
> I hope from here we can have a open and constructive discussion to try
> to improve the TripleO project.

me too so let me add my idea as the 6th point

5/ Documentation isn't great

We did some good things, we have a repo with usable doc and a website to 
point people to, but the docs honestly are a bit confusing and even lack 
documentation about quite some features for end users.

Maybe we can start some minor restructuring of the docs, splitting them 
into a 'quickstart' guide and a 'feature-complete' guide and ask people 
to submit together with a feature the matching documentation in the 
'feature-complete' guide?
-- 
Giulio Fidente
GPG KEY: 08D733BA