Open Stack

On 16 February 2016 at 10:03, Darragh Bailey <daragh.bailey at gmail.com>
wrote:

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

Agreed. I'll try to reach out to the Jenkins team and see if I can get a
statement from them about how this is supposed to work.


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

Agreed. I think we should handle it specially and making sure it's
documented. I do see it being useful for "disabled". David can you confirm
if there's other fields you believe needs to be handled specially like this
one?


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

I'm not sure how much the impact is but unless you ever purposely set an
optional setting to something previously, the optional parameter in Jenkins
is the default setting already just not explicitly. I've only ever been hit
with this issue when I set something on purpose and decide later that I no
longer want it and delete the setting, expecting it to revert to the
default.

I'm not sure how best to handle this as it is a behaviour change and would
be difficult to support 2 behaviours at the same time as it's hard to tell
which one should be used. One thought is if we're going with the
discussions from patch https://review.openstack.org/261620/

1. Put a single warning when JJB completes running that states something
like:

    ATTENTION: The behaviour of parameters marked as (optional) is
changing. In future releases if not passed they will revert to a default
setting.

2. We can add the "fail_required=False" parameter to the convert_mapping_to_xml
function as suggested

This leaves existing functionality for plugins that use the
convert_mapping_to_xml function at least to stay the same and for all new
plugins set "fail_required=True", after a few releases we can flip the
switch so that it's True by default.

3. We start converting plugins using convert_mapping_to_xml function with
the fail_required=True setting and set correct "defaults" for optional
settings

Kien is my intern for the upcoming summer intern program and I think would
be a good project for him to work on. I think this would be a good start,
and would quickly simplify the code we maintain for the various modules.

Thoughts?

Thanh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160217/c1f2c8e0/attachment.html>