Open Stack

Hi,

Bit slow in catching up with email

On 30 June 2015 at 16:44, Wayne Warren <wayne at puppetlabs.com> wrote:

> On Mon, Jun 29, 2015 at 11:00 AM, James E. Blair <corvus at inaugust.com>
> wrote:
> > Hi,
> >
> > Jenkins Job builder is one of our more widely used projects.  It has
> > served us extremely well and a lot of other projects have found it to be
> > very useful.  Many of us are delighted and very proud of this.
> >
> > Recently I have proposed substantial changes to Zuul that I hope will,
> > through the process of simplification, mean that we will eventually no
> > longer need to use JJB in the OpenStack project.  However, I believe the
> > project will continue to be useful for many others.  Meanwhile, others
> > within the JJB community have started proposing major changes to JJB as
> > well.  I wanted to talk about how development might proceed in order to
> > provide minimal disruption for everyone.
>

Would be interested in learning more about the proposed Zuul changes, would
you mind pointing me towards some of the discussions. I'm assuming that
anyone else interested in the internals of JJB's parsing/expansion would
like to see if anything can be learnt from what you are doing with Zuul.

> First, I think JJB should continue to at least maintain (and perhaps
> > enhance) the current use case and syntax we are using in the OpenStack
> > project infrastructure.  If major changes are to happen to JJB, I do not
> > anticipate that we will want to make use of them in OpenStack, so we
> > will be a good use case to ensure that we do not break compatibility for
> > JJB's existing user base.
>
> +1
>
> We should take this one step further and be careful even in cases
> where project-config isn't affected by changes. Some of the changes
> being discussed in https://review.openstack.org/#/c/194497/ would
> definitely have an adverse effect on the configuration I currently
> manage.
>

I would be hopeful that we can put any breaking changes behind config
options at least until ready to issue a new major release, ideally with the
ability to revert to the old behaviour via the config option.


> Having said that, if the Infrastructure Council, including the current
> > JJB cores, feel that the proposed major changes to JJB are desirable, it
> > will approve the proposed specs, and those changes can proceed.  If the
> > changes need to break backwards compatibility, we can create a feature
> > branch for that work (or a stable branch) so that we can continue to
> > support the current 1.0 syntax (however, if we can evolve JJB in one
> > branch, all the better).
>
> What about API-specific changes that don't affect DSL or command line
> behavior?
>
> Initially I was thinking that would happen on a feature branch but I'm
> not sure how beneficial that would be at this point.
>

The current API changes proposed, if that's all that change, won't impact
existing usage provided it's via the command line. So should be safe there
if we can implement them behind some config options.


> > Finally, assuming that we do accept the Zuulv3 spec and stop using JJB
> > ourselves, I would expect us to remove JJB from the list of official
> > OpenStack infrastructure projects, but owing to our responsibility to
> > the community that has built up around it and our desire for its
> > continued success, continue hosting development in OpenStack's project
> > infrastructure as long as we are able and the future JJB development
> > team desires.
>
> +1, I'd like to help maintain this however I can.
>

 Plan to keep helping here as well :)

>
> > I hope that this sounds like a clear plan that benefits everyone.
> >
> > Thanks,
> >
> > Jim
>


-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150706/bd2a0ee8/attachment.html>