Open Stack

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?
>
> Thanh
>
> [1] https://review.openstack.org/261620/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160215/b6ee89a4/attachment.html>