Open Stack

I think I mentioned this before, but the working group has not made any binding decisions. We already identified Zuul and Nodepool as tools to learn more about. It's not clear to us yet if it makes sense for the simple use case. That will be one of the things we discuss.

We do know that Solum requires multi-tenant capability from these tools. They were designed for single-tenant use. We have not yet scoped the effort required to add that.

One thing that has could be valuable before holding the first meeting is a written briefing on these tools. Someone who understands them should help with this, or we should do some research.  I will be requesting help from a small research team to put something together, so we can study up and arrive well informed. Volunteers welcome.

--
Adrian


-------- Original message --------
From: Clint Byrum
Date:11/24/2013 10:00 AM (GMT-08:00)
To: openstack-dev
Subject: Re: [openstack-dev] [Solum] git-Integration working group

Excerpts from Adrian Otto's message of 2013-11-22 18:51:16 -0800:
> 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.
>

Zuul and nodepool are things to optimize large scale testing. git-review
and gerrit, on the other hand, are the frontend that it sounds like
this trivial "just a push" process would try to replace. I don't think
it is wise to ignore the success of those two pieces of the OpenStack
infrastructure. If what you're doing is only ever going to be a simple
push, so be it. However, I doubt that it will remain so simple.

Is there some reason _not_ to just consume these as-is?

> >> 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.
>

We struggled with this in Ubuntu as well. Ultimately, our fine friends at
Google have created what seems to be one of the most intuitive distributed
collaboration tools the world has ever seen. I think Monty is right,
and that we should strive to use the tools the rest of OpenStack uses
whenever possible, and we should strive to be 100% self hosted.

However, I do think G+ has enough benefit at times to deal with the fact
that it is not free and we can't really host our own.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/f0a49888/attachment.html>