Open Stack

On 15 February 2016 at 15:02, David Caro <dcaro at redhat.com> wrote:
> On 02/15 09:48, Thanh Ha wrote:
>> Bumping since I feel this is an important discussion. Darragh, Wayne, any
>> thoughts on this one?

Sorry only catching up now. Had started a draft response via my phone
over the weekend :-\

>> On 8 February 2016 at 10:46, Thanh Ha <thanh.ha at linuxfoundation.org> wrote:
>>
>> > Hi Everyone,

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

Have encountered this with the hipchat plugin XML, so aware of how
annoying it can be. Ultimately I think the code for the newer version
of plugins was modified to use defaults for the new settings in the
future since it was just too surprising in usage.


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

Might want to ping the Jenkins dev mailing list first to get the full
set of rules about how Jenkins updates job configuration, because this
occurs in some cases and not in others. I suspect it's to do with the
parent tag type, so if it's a simple data container like a list, the
contents are placed with exactly as defined by the XML, but if it's a
custom tag it is either merged, or depends on how the plugin/code
wishes to handle the changes.

Still a good idea to know exactly what the rules are.


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

Be willing to treat 'disabled' as a special case here, as for most
other XML tags the current behaviour of remove yaml setting and it
keeps the original value stored is quite a surprising behaviour.

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

JJB already retrieves basic job information from the remote jenkins
before updating, so in theory it would be possible to allow special
handling of the disabled XML tag by checking if the job is disabled or
not in the information returned (assuming we don't discard all of the
extra info).

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

The deeper you go in the various plugin settings the more complex this
becomes. At worst you end up needing to define everything explicitly
for each job via different sets of defaults, thus removing the benefit
of 'optionals' anyway. Probably also requires deep merging of defaults
to work correctly in order to be usable without being onerous.

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

> --
> David Caro

Think it all comes down to the following:
* Need to understand what exactly is happening within Jenkins with
regard to XML updating, clearly not just taking the XML given and
changing to match that, more likely some kind of merge is going on.
* Is the sort of workflow described by David limited to the disabled
tag, or useful elsewhere? If limited I think we should handle
'disabled' as a special case.
* If the decision is to change behaviour going forward, initially
needs to only apply to new settings being added and have a way of
converting existing code while matching existing behaviour via some
setting.

Expect we'll have to support existing use of optionals for at least
one major release for the current modules whether we decide to switch
the behaviour for the future or not. So the change identified will
have to keep that in consideration.

-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"