Open Stack

On 16 February 2014 17:57, Jay Pipes <jaypipes at gmail.com> wrote:

> Personally, I believe having Gerrit and Jenkins as the default will turn
> more people off Solumn than attract them to it.
>
> Just because we in the OpenStack community love our gating workflow and
> think it's all groovy does not mean that view is common, wanted, or
> understood by the vast majority of users of Heroku-like solutions.

There are quite a number of such solutions; do we want to write yet
another? What makes solum special ? Is it supporting OpenStack? [If so
- I'd argue that our success elsewhere will guarantee other such
platforms support OpenStack - and e.g. OpenShift already do AFAIK].
Why are we writing Solum?

> Who is the audience here? It is not experienced developers who already
> understand things like Gerrit and Jenkins. It's developers who just want
> to simplify the process of pushing code up to some system other than
> Github or their workstation. Adding the awkwardness of Gerrit's code

If thats all, then I don't think we should be writing Solum. We should
just pick some of the existing tooling for that and say 'use that'.

> review system -- and the associated pain of trying to understand how to
> define Jenkins jobs -- is something that I don't think the *default*
> Solum experience should invite.
>
> The default experience should be a simple push code, run merge tests,

What are merge tests? How are they defined? What about that definition
makes it impossible for us to run them in Jenkins or similar? What
makes it impossible to run them before the merge?

> and deploy into the deployment unit (whatever that is called in Solum
> nowadays). There should be well-documented ways to add commit hooks into
> this workflow, but having a complex Gerrit and Jenkins gated workflow is
> just overkill for the default experience.

Even in small teams - 4-5 people - gated workflow and CI/CD is a game
changer for velocity. If your point is 'doing the sophisticated thing
OpenStack does is hard and we shouldn't try to sell people on working
hard' - I agree. But your point currently sounds like 'there's no way
we can make this stuff easy, discoverable, and straight forward, so we
should focus on something much less capable'. Perhaps thats not what
you mean?

I think there is a spectrum here. We need to aim high, or we achieve
low. We also need to deliver incrementally, and we need to provide a
-really- gentle onramp for users. Make the first basic steps easy and
simple: but thats not in any way incompatible with gating by default.

It *might* be incompatible with Jenkins and zuul: but thats a slightly
different discussion- my +1, which you replied to, was about /gating/
by default, not about the implementation thereof.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud