<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 5, 2016 at 10:31 AM, Giulio Fidente <span dir="ltr"><<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 03/04/2016 03:23 PM, Emilien Macchi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's not the name of any Summit's talk, it's just an e-mail I wanted<br>
to write for a long time.<br>
<br>
It is an attempt to expose facts or things I've heard a lot; and bring<br>
constructive thoughts about why it's challenging to contribute in<br>
TripleO project.<br>
</blockquote>
<br></span>
hi Emilien,<br>
<br>
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.<br>
<br>
I have some ideas but I want to start by commenting to your points.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
1/ "I don't review this patch, we don't have CI coverage."<br>
<br>
One thing I've noticed in TripleO is that a very few people are involved<br>
in CI work.<br>
In my opinion, CI system is more critical than any feature in a product.<br>
Developing Software without tests is a bit like <a href="http://goo.gl/OlgFRc" rel="noreferrer" target="_blank">http://goo.gl/OlgFRc</a><br>
All people - specially core - in the project should be involved in CI<br>
work. If you are TripleO core and you don't contribute on CI, you might<br>
ask yourself why.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2/ "I don't review this patch, CI is broken."<br>
<br>
Another thing I've noticed in TripleO is that when CI is broken, again,<br>
a very few people are actually working on fixing failures.<br>
My experience over the last years taught me to stop my daily work when<br>
CI is broken and fix it asap.<br>
</blockquote>
<br></span>
Agreed. More eyes and more coverage to increase its dependability.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3/ "I don't review it, because this feature / code is not my area".<br>
<br>
My first though is "Aren't we supposed to be engineers and learn new areas?"<br>
My second though is that I think we have a problem with TripleO Heat<br>
Templates.<br>
THT or TripleO Heat Templates's code is 80% of Puppet / Hiera. If<br>
TripleO core say "I'm not familiar with Puppet", we have a problem here,<br>
isn't?<br>
Maybe should we split this repository? Or revisit the list of people who<br>
can +2 patches on THT.<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>This is pretty much what I proposed last week (<a href="https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests">https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests</a>) and I noticed Dan approved the blueprint yesterday (cheers). It's definitely going to cause problems in that THT defines the data interface and puppet-tripleo is going to have to keep up with that interface in lock-step in some cases so be prepared to deal with that as a patch author. This isn't really any different to non-tripleo puppet module situations where a change to the repo holding hiera data will be tied to changes in modules.</div><div><br></div><div>Ideally I'd like to incrementally decouple the puppet-tripleo profiles from the data heat provides but for the first cut they'll be joined at the hip.</div><div><br></div><div>So given a new home (puppet-tripleo) for a large portion of the code (starting with overcloud controller and controller_pacemaker), hopefully this paves the way for giving those who know puppet well the opportunity to take on responsibility for the manifests without necessarily being intimately familiar with the rest of the system, which I guess helps with Emilien's original concern that there's a skill split across the tooling lines.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
Maybe we could stop and think a together about new HOT functionalities which could help us? Interesting for the summit as well?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4/ Patches are stalled. Most of the time.<br>
<br>
Over the last 12 months, I've pushed a lot of patches in TripleO and one<br>
thing I've noticed is that if I don't ping people, my patch got no<br>
review. And I have to rebase it, every week, because the interface<br>
changed. I got +2, cool ! Oh, merge conflict. Rebasing. Waiting for +2<br>
again... and so on..<br>
<br>
I personally spent 20% of my time to review code, every day.<br>
I wrote a blog post about how I'm doing review, with Gertty:<br>
<a href="http://my1.fr/blog/reviewing-puppet-openstack-patches/" rel="noreferrer" target="_blank">http://my1.fr/blog/reviewing-puppet-openstack-patches/</a><br>
I suggest TripleO folks to spend more time on reviews, for some reasons:<br>
<br>
* decreasing frustration from contributors<br>
* accelerate development process<br>
* teach new contributors to work on TripleO, and eventually scale-up the<br>
core team. It's a time investment, but worth it.<br>
</blockquote>
<br></span>
I'm inclined to think that this is a bit of a consequence of 1), 2) and 3) together.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In Puppet team, we have weekly triage sessions and it's pretty helpful.<br>
</blockquote>
<br></span>
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.<br>
<br>
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?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
5/ Most of the tests are run... manually.<br>
<br>
How many times I've heard "I've tested this patch locally, and it does<br>
not work so -1".<br>
<br>
The only test we do in current CI is a ping to an instance. Seriously?<br>
Most of OpenStack CIs (Fuel included), run Tempest, for testing APIs and<br>
real scenarios. And we run a ping.<br>
That's similar to 1/ but I wanted to raise it too.<br>
</blockquote>
<br></span>
I'd say a consequence of 1) as well<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If we don't change our way to work on TripleO, people will be more<br>
frustrated and reduce contributions at some point.<br>
I hope from here we can have a open and constructive discussion to try<br>
to improve the TripleO project.<br>
</blockquote>
<br></span>
me too so let me add my idea as the 6th point<br>
<br>
5/ Documentation isn't great<br>
<br>
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.<br>
<br>
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?<span><font color="#888888"><br>
-- <br>
Giulio Fidente<br>
GPG KEY: 08D733BA</font></span><div><div><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>