Open Stack

While I agree with some (not all) of the sentiment below I'm not sure I
want to spend the time debating this rather broad set of topics in this
email thread. I'm not sure we'd actually ever see the end of it if we
did. Nor can the upstream TripleO team control all the forces at play
here.

So rather than this... Would it be reasonable to ask that we take this
a step further and split things out into concrete ideas to improve
these areas? Perhaps each in its own spec or email thread so that we
can reach clear conclusions to each problem... a step at a time.

A couple of things to set the record straight:

On the CI issues.... We actually have some really good ideas on the
table to solve some of these CI problems including architectural
changes like "split stack" ideas which could allow parts of our
overcloud CI to run on normal cloud instances, auto-promoting package
repositories based on nightly periodic jobs, caching our image builds,
etc. Some of these things will open the door to new features like the
ability to run more test suites (which we haven't done yet due to the
long wall time associated with our CI at this point).

There are reasons for TripleO CI, why it exists, why we have put so
much effort into keeping it running over the years. Yes our tests take
a long time to run, and yes we have some things we still do manually,
but we do catch a lot of issues and breakages in both our own and other
OpenStack projects. And while our core team often disagrees on things I
think we do agree that continuing to expand upstream CI coverage on
major features is key to digging out of the hole we are in. 

As for the rest of it I think a lot of it has to do with doing the best
we can with limited upstream resources. To me the real problem driving
a majority of the issues you describe below is simply trying to land X
number of features upstream by a given date with little to no CI
coverage. The sooner we take the time and discipline to stop this the
better.

Dan


On Fri, 2016-03-04 at 09:23 -0500, 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.
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> 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.
> 
> In Puppet team, we have weekly triage sessions and it's pretty
> helpful.
> 
> 
> 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.
> 
> 
> 
> 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.
> 
> Thank you for reading so far.
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev