Open Stack

Any comment?

Cheers,
S

On Sat, Mar 5, 2016 at 11:03 AM, Adam Young <ayoung at redhat.com> wrote:
> On 03/04/2016 09:23 AM, 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.
>
>
> OK...so what is the state of Tripleo CI?  My experience with Tripleo has
> shown that it is quite resource intesive, far more so than, say, Keystone,
> and so I could see that being the gating factor.
>
>
> In order for me to be able to get into Tripleo coding, I needed a new
> machine, with 32 Gb of Ram, separate from my everyday work machine.  Not a
> killer outlay, but enough to hold me up until I got the HW allocated.
>
> If we could split up the testing undercloud vs. overcloud, it might be more
> feasable.  I see no fundamental reason that the majority of the Overcloud
> development and testing could not be done on top of a non-ironic based
> OpenStack deployment.
>
> That leaves just the undercloud, which could, possibly, also run onto top of
> an existing OpenStack deployment for much of the development.
>
> A true end to end run of Tripleo with HA requires a lot:  3 Physical
> machines plus a little overhead for the Overcloud.  But this is what is
> really needed.  Ideally, on multiple vendors' systems, so that we identify
> some aspect of the Hardware variation.
>
>
>
>
> 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.
>
>
> Puppet and Heat are black boxes to me still.  I don't clearly understand how
> they fit together.
>
> I think we need to start depuppetifying Tripleo. I know we have a lot of
> sunk costs in to it, but we went with Puppet because it was all we had, not
> that it well matched the problem set.
>
> I'd recommend a freeze on all new Puppet development, and start doing all
> new features in Ansible. Fully acknowledging the havoc this will wreak,  I
> think it is important strategically.   It is really hard to swap between two
> languages, and the rest of OpenStack in Python.  Switching to Ruby is hard.
>
> All of our Client support is in Python.
>
> The number of people that know Puppet that actively contribute to OpenStack
> is small. The number of real Ruby experts is smaller.
>
>
>
> 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.
>
> I am more than happy to review anything Keystone related, but again, I
> struggle with Puppet.
>
> Not really knowing Heat as well makes it even tougher. We need a better
> overall orientation guide if people are going to come up to speed quicker.
>
>
>
>
> 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..
>
> Same is true on Keystone.  There is just a lot to get done on this project.
> All these projects.
>
>
> 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:
>
>
> Nice of you to write that up.
>
> * 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.
>
> Again, testing is expensive; if I am testing a patch, my one and only
> development system can't be used for development.  If we can find a way top
> make things lighter, we can get more done.
>
>
>
>
> 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:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Email:
shinobu at linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource