Open Stack

On 02/15 09:48, Thanh Ha wrote:
> Bumping since I feel this is an important discussion. Darragh, Wayne, any
> thoughts on this one?
> 
> Thanks,
> 
> Thanh
> 
> On 8 February 2016 at 10:46, Thanh Ha <thanh.ha at linuxfoundation.org> wrote:
> 
> > Hi Everyone,
> >
> > I'd like to discuss the usefulness of optional parameters in JJB. We've
> > been hit by a behaviour that is in my opinion indeterministic and causes
> > confusion as well as inconvenience as a user. I was reminded by this in
> > discussions in this patch [1] but then again this weekend while we were
> > trying to move to a Zuul setup.
> >
> > It appears that if you update Jenkins with missing XML, it's behaviour
> > will be to leave the field untouched as in whatever was configured last
> > will remain the setting in Jenkins.
> >
> > So a simple step-by-step example:
> >
> > 1. Create a simple job in JJB with just job name and the setting "disabled"
> >
> > - job:
> >     name: job-name
> >     disabled: false
> >
> > 2. Look at Jenkins UI for the job. It should be in "disabled" state
> > 3. Delete the line "disabled: false" from your YAML and update the job
> > again
> > 4. Look at Jenkins UI for the job. It is still in "disabled" state.
> > 5. In the Jenkins UI enable the job
> > 6. Update the job again with JJB and notice the Job is now still "enabled"
> > this time
> >
> > So this means if we don't pass an XML setting to Jenkins it will always
> > leave the job configuration in the last state that was configured. I feel
> > like this result with JJB is indeterministic with this behaviour and
> > affects any code that does not create XML for a configuration setting if it
> > is not configured in YAML.
> >
> > We were hit again by this issue over the weekend while trying to migrate
> > our jobs over to Zuul by removing the Gerrit Trigger configurations in JJB.
> >
> > I feel like there shouldn't be optional settings in JJB but instead if a
> > user does not pass a configuration step then JJB should always set a
> > default for said setting so that the result is more deterministic. When I
> > remove a job configuration from YAML my expectation is that Jenkins will
> > revert the setting back to whatever the default state is rather than
> > Jenkins leaving the previous state.
> >
> > We could potentially resolve this via work on patch [1] if there's
> > agreement that the behaviour on the behaviour of JJB when a setting is not
> > provided in YAML. My opinion is that instead of optional all parameters
> > should have a default setting.
> >
> > Thoughts?

What happens then when you want to leave the setting with it's current value?

Let me put an example, in my team we use to leave notes in the jobs
descriptions and also manually disable/enable jobs. That is useful when
troubleshooting jobs, imagine that you have a job that cleans up the workspace
on start, and it's failing, what we do is disable the job, so it does not
cleanup the workspace and then we add a small comment in the description with a
note on who's working on the job and why (if the reason for the failure is
known).

We don't want to do so by yaml, as most probably is just one of the jobs
generated by a matrix of combinations and that means that we would have to
add a lot of boilerplate code just to be able to disable that specific
job. And the debugging is transient, not meant to last more than a few hours.

In that case, if you force jjb to send a default value all the time, that flow
would stop working.

I think that if you want to set defaults, you should do so in the default
construct instead, that also prevents that any change in the defaults on jjb
code from changing the generated xml.

> >
> > Thanh
> >
> > [1] https://review.openstack.org/261620/
> >

> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160215/6bf9474e/attachment-0001.pgp>