[openstack-dev] [Solum] git-Integration working group

Monty Taylor mordred at inaugust.com
Sun Nov 24 20:58:37 UTC 2013

On 11/22/2013 09:51 PM, Adrian Otto wrote:
> Monty,
> On Nov 22, 2013, at 6:24 PM, Monty Taylor <mordred at inaugust.com> 
> wrote:
>> On 11/22/2013 05:37 PM, Krishna Raman wrote:
>>> Hello all,
>>> I would like to kickoff the Git integration discussion. Goal of
>>> this subgroup is to go through the git-integration blueprint [1]
>>> and break it up into smaller blueprints that we can execute on.
>>> We have to consider 2 workflows: 1) For Milestone 1, pull based
>>> git workflow where user uses a public git repository (possibly on
>>> github) to trigger the build 2) For later milestones, a push
>>> based workflow where the git repository is maintained by Solum
>> Hi!
> Hi, thanks for chiming in here.
>> I'm a little disappointed that we've decided to base the initial 
>> workflow on something that is not related to the world-class
>> git-based developer tooling that the OpenStack project has already
>> produced. We have a GIANT amount of tooling in this space, and it's
>> all quite scalable. There is also the intent by 3 or 4 different
>> groups to make it more re-usable/re-consumable, including thoughts
>> in making sure that we can drive it from and have it consume heat.
> The initial work will be something pretty trivial. It's just a web
> hook on a git push. The workflow in this case is not customizable,
> and has basically no features. The intent is to iterate on this to
> make it much more compelling over time, soon after the minimum
> integration, we will put a real workflow system in place. We did
> discuss Zuul and Nodepool, and nobody had any objection to learning
> more about those. This might be a bit early in our roadmap to be
> pulling them in, but if there is an easy way to use them early in our
> development, we'd like to explore that.

A web hook on a git push seems trivial, but is not. Something has to run
the git push - and as you said, you're planning that thing to be github.
That means that, out of the gate, solum will not work without deferring
to a non-free service. Alternately, you could install one of the other
git servers, such as gitlab - but now you're engineering that.

Also, you need to have something receive the payload of the webhook.

Now - work is unavoidable, and is a good thing! But if we can avoid work
over in the corner that can't be reused elsewhere, that would be neat.

What I suggest is that you start with zuul as the engine that does
things. It's pretty good at it. AND - there is a todo list item to add a
github web hook receiver to it. If you guys added that (and I'd be happy
to point you in the right direction) then you'd have a thing out of the
gate that would be pluggable, in that it could respond to both github
and non-github type events, and you'd be giving back some functionality
to the very-git-oriented tooling of the OpenStack project.

The zuul work in question wants to be able to respond to both pull
requests and new refs landing to a branch, so I'm pretty sure it's what
you want. That's the trigger side. On the launcher side, one could
imagine writing a heat launcher, or an oslo.messaging launcher.
Currently, we use gearman for message communication with the backends
that take the action based on the incoming events. Clearly that's not
the right choice for an OpenStack service, but it's got modular triggers
for a reason. :)

Also, if you do that work, writing one that would respond to webhooks
from bitbucket is probably an additional 10 minutes of work.

>>> Devdatta has created 2 blueprints for consideration: [2] [3]
>>> I have set up a doodle to poll for a /recurring/ meeting time for
>>> this subgroup: http://doodle.com/7wypkzqe9wep3d33#table
>>> (Timezone support is enabled)
>>> Currently the plan is to try G+ hangouts to run this meetings and
>>> scribe on #solum. This will limit us to a max of 10 participants.
>>> If we have more interest, we will need to see how to change the
>>> meetings.
>> We have IRC meeting channels for meetings. They are logged - and
>> they have the benefit that they do not require non-Open Source
>> software to access. If you have them in IRC, the team from
>> OpenStack who is already working on developer workflow around git
>> can potentially participate.
>> I don't mean to be negative, but if you want to be a PaaS for
>> OpenStack, I would strongly consider not using G+ when we have IRC,
>> and I would strongly suggest engaging with the Infra projects that
>> already know how to do git-based workflow and action triggering.
> We just finished holding the Solum Community Design Workshop in San
> Francisco. We had both irc and G+ in addition to etherpad for shared
> notetaking. What we found is that that collaboration was faster and
> more effective when we used the G+ tool. The remote participants had
> a strong preference for it, and requested that we use it for the
> breakout meetings as well. The breakout design meetings will have a
> scribe who will transcribe the interaction in IRC so it will also be
> logged.

I'm less concerned with logging of it than I am with my ability to

> Please recognize that we have not yet considered an alternate point
> of view on either of these subjects yet, because one has not been
> raised until now.. I'm open to suggestions for how best to engage the
> experts on git integration so we can benefit from the expertise in
> our community.

Certainly! I wasn't assuming that G+ was picked from a negative mindset
- and I hope I didn't come across negatively in response. I'm mainly
trying to make clear:

a) Some of us are unable to touch G+
b) We've got collaboration facilities
c) If there is something they don't do that you need, we're always
wanting to make them better

What is it about G+ that makes it better than IRC?

More information about the OpenStack-dev mailing list