Re: [OpenStack-Infra] Updating gerrit jenkins-job-builder-release group members

[Thanh Ha]

On 23 May 2018 at 03:17, Sorin Ionuț Sbârnea 
wrote:

> Hi
>
> Can someone help updating the *jenkins-job-builder-release* group on
> gerrit to add two persons to it? Apparently there is no way to raise a CR
> to update group membership, or if it is I am unaware about it.
> https://review.openstack.org/#/admin/groups/321,members
>
> Sorin Sbarnea sorin.sbar...@gmail.com
> Darragh Bailey daragh.bai...@gmail.com
>
> We are both already members of python-jenkins-release
>  but not this
> one and it would be very useful to be able to release much easier.
>
> This change would bring the two gerrit groups in-sync, which makes sense
> to me.
>
> Thanks
> Sorin Sbarnea
>

I talked to Clark and we got this resolved. The both of you should have the
ability to push tags now. Remember to be careful about what tags you push
as it's policy that tags never get deleted.

Regards,
Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Thanh Ha]

Hi Artem,

The best thing you can probably help us out with right now is to test whats
in the master branch of JJB and try to identify any issues that you run
into and report back to us. This way we can hopefully find additional major
breaking issues (like the YAML parser issue) before a full release goes
out. In the meantime until the YAML parser issue is fixed I've been using
JJB with the YAML parser patch reverted on my own test system.

https://review.openstack.org/333076

Cheers,
Thanh


On Tue, Oct 17, 2017 at 12:13 PM, Artem Panchenko <artem@panchenko.email>
wrote:

> Thank you, guys, for your replies and for providing so detailed
> information!
>
> >We've identified a bug in some of the changes we've landed
> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23openstack-
> jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have a working
> fix we should be ready to release v2.
>
> Indeed, that bug sounds like a release blocker and IMHO it definitely
> can't go into 2.0.0 (we use a lot of macroses for JJB in the company I work
> for). Unfortunately, I don't think I can help contributing or reviewing the
> code (I'm not familiar with JJB internals), but I can do some testing of
> patches. So feel free to add me to your gerrit CRs if you think you need
> that!
>
>
> Regards,
> Artem
>
> 2017-10-17 18:20 GMT+03:00 Thanh Ha <thanh...@linuxfoundation.org>:
>
>> +1 to that.
>>
>> My org is very much looking forward to the 2.0.0 release as we refuse to
>> use the master stream. I do think work needs to be done to fix the YAML
>> parser issue identified in the linked meeting and consider it blocking as
>> we use this feature heavily in our own instance.
>>
>> It's been slow but we are pushing to get 2.0.0 out the door. Definitely
>> if you want to help move things along please join the weekly meeting.
>>
>> Cheers,
>> Thanh
>>
>>
>> On Tue, Oct 17, 2017 at 9:39 AM, Darragh Bailey <daragh.bai...@gmail.com>
>> wrote:
>>
>>> Hi Artem,
>>>
>>>
>>> The delay has been caused by being consumed with other priorities. It's
>>> unfortunately, but it happens, of course any help around patch reviews and
>>> fixing up the patches in the backlog will help.
>>>
>>> If you'd like to drop into the irc chat #openstack-jjb on freenode room
>>> this Friday 17th @1400 UTC, there will be some discussion about v2 and
>>> what's left to be done. http://eavesdrop.openstack.org
>>> /#Jenkins_Job_Builder_Team_Meeting
>>>
>>> We've identified a bug in some of the changes we've landed
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%23o
>>> penstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we have
>>> a working fix we should be ready to release v2.
>>>
>>> As I'm heading to a python conference this weekend, I'm hoping there
>>> will be a hacking space and I'll try to solve both that bug and the concern
>>> around use of a global config object everywhere mentioned in
>>> https://etherpad.openstack.org/p/jjb_api_v2.0
>>>
>>>
>>> Fingers crossed we should be able to get the v2 release out in the next
>>> month, any help that you can give would be appreciated.
>>>
>>> Thanks,
>>>
>>>
>>> --
>>> Darragh Bailey
>>> "Nothing is foolproof to a sufficiently talented fool"
>>>
>>>
>>> On 17 October 2017 at 11:04, Artem Panchenko <artem@panchenko.email>
>>> wrote:
>>>
>>>> Hi folks!
>>>>
>>>> I wonder if there is a road map or some release schedule for
>>>> jenkins-job-builder project? Last time it was published on pypi/github more
>>>> than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
>>>> infra doesn't use Jenkins anymore and doesn't invest into JJB development
>>>> (please correct me if I'm wrong). Though, I see that >150 changes have been
>>>> merged to master since that time, so the project is still maintained.
>>>>
>>>> I'll appreciate If someone shares any details about when the next major
>>>> version release of JJB is going to happen.
>>>>
>>>> Thanks in advance!
>>>>
>>>> ---
>>>> Best regards,
>>>> Artem Panchenko
>>>>
>>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [jenkins-job-builder] When will jenkins-job-builder 2.0.0 be released?

[Thanh Ha]

+1 to that.

My org is very much looking forward to the 2.0.0 release as we refuse to
use the master stream. I do think work needs to be done to fix the YAML
parser issue identified in the linked meeting and consider it blocking as
we use this feature heavily in our own instance.

It's been slow but we are pushing to get 2.0.0 out the door. Definitely if
you want to help move things along please join the weekly meeting.

Cheers,
Thanh


On Tue, Oct 17, 2017 at 9:39 AM, Darragh Bailey 
wrote:

> Hi Artem,
>
>
> The delay has been caused by being consumed with other priorities. It's
> unfortunately, but it happens, of course any help around patch reviews and
> fixing up the patches in the backlog will help.
>
> If you'd like to drop into the irc chat #openstack-jjb on freenode room
> this Friday 17th @1400 UTC, there will be some discussion about v2 and
> what's left to be done. http://eavesdrop.openstack.
> org/#Jenkins_Job_Builder_Team_Meeting
>
> We've identified a bug in some of the changes we've landed
> http://eavesdrop.openstack.org/irclogs/%23openstack-jjb/%
> 23openstack-jjb.2017-10-06.log.html#t2017-10-06T14:06:18, and once we
> have a working fix we should be ready to release v2.
>
> As I'm heading to a python conference this weekend, I'm hoping there will
> be a hacking space and I'll try to solve both that bug and the concern
> around use of a global config object everywhere mentioned in
> https://etherpad.openstack.org/p/jjb_api_v2.0
>
>
> Fingers crossed we should be able to get the v2 release out in the next
> month, any help that you can give would be appreciated.
>
> Thanks,
>
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
>
> On 17 October 2017 at 11:04, Artem Panchenko 
> wrote:
>
>> Hi folks!
>>
>> I wonder if there is a road map or some release schedule for
>> jenkins-job-builder project? Last time it was published on pypi/github more
>> than 6 months ago and that was the second beta of 2.0.0. AFAIU, OpenStack
>> infra doesn't use Jenkins anymore and doesn't invest into JJB development
>> (please correct me if I'm wrong). Though, I see that >150 changes have been
>> merged to master since that time, so the project is still maintained.
>>
>> I'll appreciate If someone shares any details about when the next major
>> version release of JJB is going to happen.
>>
>> Thanks in advance!
>>
>> ---
>> Best regards,
>> Artem Panchenko
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB V2.0 planning

[Thanh Ha]

On Thu, Nov 10, 2016 at 12:07 PM, Wayne Warren <wa...@puppet.com> wrote:

> On Wed, Nov 9, 2016 at 6:41 PM, Thanh Ha <thanh...@linuxfoundation.org>
> wrote:
>
>> There's 2 patches that need one more core-review to get merged so
>> hopefully someone can take a look at them soon:
>>
>> https://review.openstack.org/336091 Improve logger output for expanding
>> templates
>> https://review.openstack.org/206178 Add view management functionality
>>
>
> Merged, looking forward trying these out in the 2.0.0 release!
>
>
>> And these patches need some reviews:
>>
>> https://review.openstack.org/395716 Add support for view-template
>>
>
> This is a feature addition that seems to me like it could just as easily
> have landed in 1.x as in 2.0.0 or for that matter 2.1, 2.2, 2.3, etc. Are
> we blocking a 2.0.0 release on this and if so is there a technical reason
> for doing that rather than focusing on merging the changes necessary for
> 2.0.0--the goal of which remember was to refactor the API for improved
> programmatic access to JJB internals, which benefits all of us even if the
> view-template feature is not included in the first 2.x release.
>

You're right this one can be added at anytime. It would be very helpful to
us if we can get it in sooner rather than later though as we rely on views
quite a bit. At least the view patch above was merged so that will get us
by if we don't have time for this one.



>
>
>> We also have 4 patches that still need work:
>>
>> https://review.openstack.org/333076 Move macro expansion into YamlParser
>>
>
> I will find time to update this per the review comments by Friday.
>
>
>> https://review.openstack.org/309735 Output additional info when
>> exceptions occur
>> https://review.openstack.org/357960 Add convenience function for plugin
>> namespace
>>
>
I'll try to take another crack at the plugin namespace one today.



> https://review.openstack.org/358019 Support explicit API and simple
>> config creation
>>
>> There's also some TODO actions in the etherpad that we need to decide if
>> we want to continue pushing for in the JJB 2.0 push.
>>
>
> I think the best forum for making a decision on these items would be here
> on the mailing list. If everyone else agrees let's start that in this
> thread.
>

+1 that makes sense to me.


Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB V2.0 planning

[Thanh Ha]

Hi Everyone,

I'd like to keep the momentum of JJB 2.0 work going as we're so close to
the finish line. This Friday we're going to continue our sprint in
#openstack-sprint for those who can make it. Wayne suggested we send a
status to the mailing list for those who can't.

To summarize some of the etherpad
https://etherpad.openstack.org/p/jjb_api_v2.0 below.

There's 2 patches that need one more core-review to get merged so hopefully
someone can take a look at them soon:

https://review.openstack.org/336091 Improve logger output for expanding
templates
https://review.openstack.org/206178 Add view management functionality

And these patches need some reviews:

https://review.openstack.org/395716 Add support for view-template

We also have 4 patches that still need work:

https://review.openstack.org/333076 Move macro expansion into YamlParser
https://review.openstack.org/309735 Output additional info when exceptions
occur
https://review.openstack.org/357960 Add convenience function for plugin
namespace
https://review.openstack.org/358019 Support explicit API and simple config
creation

There's also some TODO actions in the etherpad that we need to decide if we
want to continue pushing for in the JJB 2.0 push.

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB's use of inspect plugin info requires administrator permissions

[Thanh Ha]

I took a look at the groovy script idea. I think it might work but would be
a bit more involved than the example. It seems
Jenkins.instance.pluginManager.plugins simply prints a list of all plugins
without their details like version etc...

Regards,
Thanh

On 14 June 2016 at 20:11, Zaro  wrote:

> Thanks for the clarification Andrew.  I almost thought you guys knew
> something that upstream Jenkins didn't ; )  I am able to repro with
> ver 1.651.2.  I agree with Thanh, the correct fix is to add a new ACLs
> to jenkins security plugin to allow retrieving plugin info.  I've
> reviewed Thanh's workaround and it seems ok to me.  The other possible
> workaround you might consider is to create a user with 'Read' and
> 'RunScripts' access which would allow running a groovy script [1] to
> get the plugin info.
>
> [1]
> https://python-jenkins.readthedocs.io/en/latest/api.html#jenkins.Jenkins.run_script
>
>
> On Tue, Jun 14, 2016 at 12:44 PM, Andrew Grimberg
>  wrote:
> > On 06/14/2016 12:18 PM, Zaro wrote:
> >> ahh, jenkins.io page confused me since it says latest LTS is 1.651.3
> >>
> >>
> >> On Tue, Jun 14, 2016 at 12:13 PM, Darragh Bailey
> >>  wrote:
> >>> The 1.652.x series is an lts  release, so fixes were backported to it
> that
> >>> are not in subsequent dev releases.
> >>>
> >>> Darragh Bailey
> >>> "Nothing is foolproof to a sufficiently talented fool" - unknown
> >>>
> >>> On 14 Jun 2016 20:02, "Zaro"  wrote:
> 
>  - [ snippet ] 
> >
> > The behavior changed between 1.651.1 and 1.652.2.
> >
> > Specifically this was a security fix that came in with 1.652.2. See
> the
> > security fixes [0] that came with the release notes. Search for
> > SECURITY-250 or CVE-2016-3723.
> >
> > -Andy-
> >
> > [0]
> >
> >
> https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11
> 
>  Hmm.  I just tested with Jenkins ver 1.653 and was still able to
>  access plugin info using REST api as an anonymous user.
>  I enabled security with following settings:
>   * jenkins own db
>   * logged-in user can do anything
>   * prevent cross site request
> 
>  While not logged in I can get plugin info using
>  '/pluginManager/api/json?depth=1'
> 
>  Maybe this there's some setting you have enabled that's causing your
>  jenkins to require admin to access plugin info?
> >
> > LTS is 1.651.x. My missive about the change being between 1.651.1 and
> > 1.652.2 is incorrect. It's 1.651.1 and 1.651.2 that the security lock
> > down occurred.
> >
> > As for what we have enabled in the security system. We use the matrix
> > security setup.
> >
> > Our JJB user is granted rights inside the job category. To be specific:
> >
> > Job: Configure, Create, Delete, Discover, Read, Workspace
> > Overall: Read
> >
> > There is no configuration option for listing the plugins. You only get
> > access to it if you have Overall: Administer with the changes that came
> > in with 1.651.2 unless there's a permission knob under the covers we
> > haven't managed to figure out yet.
> >
> > -Andy-
> >
> > --
> > Andrew J Grimberg
> > Systems Administrator
> > Release Engineering Team Lead
> > The Linux Foundation
> >
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB's use of inspect plugin info requires administrator permissions

[Thanh Ha]

On 8 June 2016 at 08:51, Darragh Bailey <daragh.bai...@gmail.com> wrote:

> On 7 June 2016 at 21:35, Thanh Ha <thanh...@linuxfoundation.org> wrote:
>
>> Taking a look at the code, I realized the test command allowed spoofing
>> of the plugins_info. I thought I'd try and see what happens if we allowed
>> spoofing with the update command too and submitted this patch:
>>
>> https://review.openstack.org/326722
>>
>> I'm wondering if this could be a possible solution to the Administrator
>> permissions issue assuming that providing the plugins_info yaml file causes
>> JJB to not query the live Jenkins system for the info.
>>
>
> Definitely worth looking at, though probably worth digging in first to
> understand why the information couldn't be retrieved in case some
> documentation is needed to help users.
>

As Andy mentioned it looks like it was introduced in Jenkins 1.652.2 which
we upgraded to this past weekend so now this problem is affecting us
although not completely just yet. Luckily we do not currently use any of
the features that need plugin_info for so we're able to take advantage of
the query_plugins_info=False setting to disable it but we should definitely
find a solution to this issue.

I updated my patch:

 https://review.openstack.org/326722/

>From my testing this patch seems to work and I introduced a new command
called "generate-plugins-info" I'm not sure what the best name for it is
but it will generate a plugins_info.yaml file which can be stored somewhere
and shared with users who can then pull it in via the "update -p
plugins_info.yaml" parameter.

Regards,
Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB's use of inspect plugin info requires administrator permissions

[Thanh Ha]

Taking a look at the code, I realized the test command allowed spoofing of
the plugins_info. I thought I'd try and see what happens if we allowed
spoofing with the update command too and submitted this patch:

https://review.openstack.org/326722

I'm wondering if this could be a possible solution to the Administrator
permissions issue assuming that providing the plugins_info yaml file causes
JJB to not query the live Jenkins system for the info.

Regards,
Thanh

On 7 June 2016 at 15:34, Thanh Ha <thanh...@linuxfoundation.org> wrote:

> Hi Everyone,
>
> I've been meaning to bring this up for awhile. It seems some plugins are
> getting a bit smarter and using the "parser.registry.get_plugin_info"
> command to parse plugin versions to figure out what version of a plugin is
> installed in Jenkins.
>
> Unfortunately it's come to our attention that this feature in Jenkins
> requires the Administrator permission which can be problematic if you have
> an environment where you prefer not to give this permission out. I think
> the ideal solution is to build into Jenkins a separate permission for
> viewing plugin information. I'll try contacting Jenkins devs to see if this
> is something they can do inside Jenkins.
>
> Failing that maybe we can somehow make the plugin info optional in JJB?
> any thoughts around this topic?
>
> One of our use cases with this is that we have a sandbox instance of
> Jenkins deployed for our community to test jobs with however for obvious
> reasons we cannot give folks administrator access to this instance but
> unfortunately if someone is trying to use a plugin (such as the Slack
> plugin) that needs to inspect plugin versions jjb fails to push the job.
>
> Regards,
> Thanh
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Fwd: JJB nested template variables

[Thanh Ha]

In-line.

On 14 March 2016 at 10:53, Darragh Bailey <daragh.bai...@gmail.com> wrote:

>
> Sorry forgot use reply-all.
>
> Also slight mistake below, ignore my comment about needing to look at
> deep_format. I'm pretty certain that it's just the dimensions piece you
> want to look at. Assuming I understand your intent correctly.
>
> -- Forwarded message --
> From: Darragh Bailey <daragh.bai...@gmail.com>
> Date: 14 March 2016 at 14:51
> Subject: Re: [OpenStack-Infra] JJB nested template variables
> To: Thanh Ha <thanh...@linuxfoundation.org>
>
>
>
> Hi Thanh,
>
> On 9 Mar 2016 22:47, "Thanh Ha" <thanh...@linuxfoundation.org> wrote:
>
>> Hi Everyone,
>>
>> I'm trying to nest template variables and discovered that JJB behaves in
>> a way I didn't expect when a template variable is nested. For example:
>>
>> - project:
>> name: test
>> jobs:
>> - '{name}-verify-{value}-{jdk}'
>>
>> value:
>> - a:
>> jdk:
>> - openjdk8
>>
>> - job-template:
>> name: '{name}-verify-{value}-{jdk}'
>>
>> When jdk is nested under the value a. It generates a job with the name:
>>
>> *'test-verify-a-['\''openjdk8'\'']'*
>>
>
> Possibly we should through an exception and complain that it's not
> acceptable to have jdk resolve to a list instead of a string? Or is it you
> want to expand this to be an additional dimension upon which to generate
> more templates based on jdk being a list of possible values?
>
> I noticed that if I switch the above to:
>
>
> value:
> - a:
> jdk: openjdk8
>
> That job is expanded as: test-verify-a-openjdk8
>


That's interesting so there's a method that works. Unfortunately in my use
case I need the list.



>
>> You'll notice the name also includes extra single quotes at the beginning
>> and end of the job name itself in addition to a python list being passed
>> out in place of the jdk variable. However if you don't nest JDK and put it
>> by itself you get the expected name of *test-verify-a-openjdk8 *without
>> the extra single quotes and python list.
>>
>
> It's a little unclear what you formats you were referring to.
>

I was referring to JJB generating *'test-verify-a-['\''openjdk8'\'']'*
instead of *test-verify-a-['\''openjdk8'\'']* it seems something is also
inserting single quotes to the name when we nest a list variable.


> I'd be interested in attempting to fix this since I have a use case for
>> having job templates with nested variables. Would this be something that's
>> easy to fix or would this have some larger affect on the code base?
>>
>
>> Can someone point me to the code files related to the template name
>> scheme. I can have a poke at it and see if it's something that can be fixed.
>>
>
> I believe this involves looking at how the deep_format function works. The
> various values for jdk get stored in the dimensions variable in the
> jenkins_jobs/parser.py code see
> https://git.openstack.org/cgit/openstack-infra/jenkins-job-builder/tree/jenkins_jobs/parser.py?id=ccf682934d14f4a2395c7b9f6d463b9667b938c8#n253
>
> Assuming what you want to do is allow the template to be expanded to
> different job names based on nested variables being a list, I think the
> exact piece of code to be changed is the loop that constructs the
> dimensions that is then iterated over to generate the jobs. See
> https://git.openstack.org/cgit/openstack-infra/jenkins-job-builder/tree/jenkins_jobs/parser.py?id=ccf682934d14f4a2395c7b9f6d463b9667b938c8#n258
>
> This snippet is where you need to focus:
>
> for (k, v) in project.items():
> tmpk = '{{{0}}}'.format(k)
> if tmpk not in template_name:
> continue
> if type(v) == list:
> dimensions.append(zip([k] * len(v), v))
>
> I discovered this on the weekend too and tried to poke at it a bit. I
think adding support for deep variable expansion may be a tough problem and
may require rewriting a few things since we need to figure out which
variables are nested before we can evaluate them correctly.

I'll try to poke at this if I can find some spare cycles.

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] JJB nested template variables

[Thanh Ha]

Hi Everyone,

I'm trying to nest template variables and discovered that JJB behaves in a
way I didn't expect when a template variable is nested. For example:

- project:
name: test
jobs:
- '{name}-verify-{value}-{jdk}'

value:
- a:
jdk:
- openjdk8

- job-template:
name: '{name}-verify-{value}-{jdk}'

When jdk is nested under the value a. It generates a job with the name:

*'test-verify-a-['\''openjdk8'\'']'*

You'll notice the name also includes extra single quotes at the beginning
and end of the job name itself in addition to a python list being passed
out in place of the jdk variable. However if you don't nest JDK and put it
by itself you get the expected name of *test-verify-a-openjdk8 *without the
extra single quotes and python list.

I'd be interested in attempting to fix this since I have a use case for
having job templates with nested variables. Would this be something that's
easy to fix or would this have some larger affect on the code base?

Can someone point me to the code files related to the template name scheme.
I can have a poke at it and see if it's something that can be fixed.

Thanks,
Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB optional parameters usefulness

[Thanh Ha]

On 16 February 2016 at 10:03, Darragh Bailey 
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
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB optional parameters usefulness

[Thanh Ha]

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...@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/
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB 1.4.0 delete-all no longer deletes jobs

[Thanh Ha]

Sorry for taking so long to get back on this one. I finally found the cause
and submitted a solution via this patch [1]. It turns out the issue is with
the groovy script itself! The api it was using getProjects() doesn't
include all job types and only simple jobs such as Freestyle jobs while
ignoring job types like Maven, Matrix, folder jobs, etc... The api is also
deprecated so we probably shouldn't use it anyway.

I switched to using the getAllItems() as recommended in the getProjects()
api docs. This newer api pulls in all job types but also allows you to pass
a parameter to select a specific job type if desired. We don't need that
parameter for the delete-all command.

Regards,

Thanh

[1] https://review.openstack.org/275993

On 20 January 2016 at 10:16, Thanh Ha <thanh...@linuxfoundation.org> wrote:

> Sure thing, I'll try to find some time this week to investigate. Thanks
> for the pointer.
>
> Regards,
>
> Thanh
>
>
> On 19 January 2016 at 15:32, Darragh Bailey <daragh.bai...@gmail.com>
> wrote:
>
>> Hi Thanh,
>>
>>
>> I suspect there's an issue with the groovy script that is used in
>> place of the REST api point executing, see:
>>
>> https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/builder.py#L168-L173
>>
>> Maybe you don't have sufficient privs to execute the script, but the
>> code isn't checking the result of calling run_script() on Jenkins.
>>
>> Any chance you could try and capture the return value from those lines?
>>
>>
>> On 19 January 2016 at 18:00, Wayne Warren <wa...@puppetlabs.com> wrote:
>> > What command line flags did you pass?
>> >
>> > I don't generally use this or the 'delete' subcommand, preferring
>> > instead to use python-jenkins directly.
>> >
>> > On Sun, Jan 17, 2016 at 5:03 PM, Thanh Ha <thanh...@linuxfoundation.org>
>> wrote:
>> >> Hi Everyone,
>> >>
>> >> It seems to me that JJB 1.4.0's delete-all function has regressed and
>> no
>> >> longer performs the delete function. Instead it simply provides the
>> >> following output and exits without performing any deletes.
>> >>
>> >> Sure you want to delete *ALL* jobs from Jenkins server?
>> >> (including those not managed by Jenkins Job Builder) (Y/N): y
>> >> INFO:root:Deleting all jobs
>> >> INFO:jenkins_jobs.builder:Number of jobs to delete:  50
>> >> INFO:jenkins_jobs.builder:Cache saved
>> >>
>> >>
>> >> Has anyone else noticed this issue as well?
>> >>
>> >> I'll try to find some time to investigate which patch introduced this
>> issue
>> >> unless someone else gets to it first but thought I'd inform the team.
>> >>
>> >> Regards,
>> >>
>> >> Thanh
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB 1.4.0 delete-all no longer deletes jobs

[Thanh Ha]

No flags it's simply just a call to:

$ jenkins-jobs delete-all

Thanh

On 19 January 2016 at 13:00, Wayne Warren <wa...@puppetlabs.com> wrote:

> What command line flags did you pass?
>
> I don't generally use this or the 'delete' subcommand, preferring
> instead to use python-jenkins directly.
>
> On Sun, Jan 17, 2016 at 5:03 PM, Thanh Ha <thanh...@linuxfoundation.org>
> wrote:
> > Hi Everyone,
> >
> > It seems to me that JJB 1.4.0's delete-all function has regressed and no
> > longer performs the delete function. Instead it simply provides the
> > following output and exits without performing any deletes.
> >
> > Sure you want to delete *ALL* jobs from Jenkins server?
> > (including those not managed by Jenkins Job Builder) (Y/N): y
> > INFO:root:Deleting all jobs
> > INFO:jenkins_jobs.builder:Number of jobs to delete:  50
> > INFO:jenkins_jobs.builder:Cache saved
> >
> >
> > Has anyone else noticed this issue as well?
> >
> > I'll try to find some time to investigate which patch introduced this
> issue
> > unless someone else gets to it first but thought I'd inform the team.
> >
> > Regards,
> >
> > Thanh
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] JJB 1.4.0 delete-all no longer deletes jobs

[Thanh Ha]

Hi Everyone,

It seems to me that JJB 1.4.0's delete-all function has regressed and no
longer performs the delete function. Instead it simply provides the
following output and exits without performing any deletes.

Sure you want to delete *ALL* jobs from Jenkins server?
(including those not managed by Jenkins Job Builder) (Y/N): y
INFO:root:Deleting all jobs
INFO:jenkins_jobs.builder:Number of jobs to delete:  50
INFO:jenkins_jobs.builder:Cache saved


Has anyone else noticed this issue as well?

I'll try to find some time to investigate which patch introduced this issue
unless someone else gets to it first but thought I'd inform the team.

Regards,

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Regression in JJB 1.4.0 maximum recursion depth exceeded

[Thanh Ha]

On 9 January 2016 at 07:10, Darragh Bailey <daragh.bai...@gmail.com> wrote:

>
> Hi Thanh,
>
> On 8 Jan 2016 21:47, "Thanh Ha" <thanh...@linuxfoundation.org> wrote:
> >
> > (I truncated some of the repetitive output below)
> >
> > I just tried with the -o argument and seems like it passes. I guess it
> only affects stdout output, good to know.
> >
> > We're using python 2.7.5 in production. I did some testing today with
> Python 3.4.3 and it seems the 3.4.x stream at least doesn't run into this
> issue so I'm guessing this only affects Python 2.7.x.
>
> I wonder if it's something that occurs with earlier 2.7 releases, I
> thought I checked that behavior out on 2.7.9
>
> I'll look to check with pyenv on Monday to go over a few python versions.
>
>
Hi Darragh,

The extremely strange thing about this one is I've only been able to
reproduce it in Jenkins. So imagine having JJB installed on the same server
as your Jenkins instance or slave. If you ssh to the machine and run JJB on
the commandline it works. Create a job running on the same system and
Jenkins will see the failure in console logs.

In case it helps with reproducing. The git repo I've been using to
reproduce this error is this one:

https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder

After cloning this repo run "jenkins-jobs test -r jjb/".

Regards,

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Regression in JJB 1.4.0 maximum recursion depth exceeded

[Thanh Ha]

On 11 January 2016 at 11:03, Thanh Ha <thanh...@linuxfoundation.org> wrote:

> On 9 January 2016 at 07:10, Darragh Bailey <daragh.bai...@gmail.com>
> wrote:
>
>> On 8 Jan 2016 21:47, "Thanh Ha" <thanh...@linuxfoundation.org> wrote:
>>
>> >
>> > (I truncated some of the repetitive output below)
>> >
>> > I just tried with the -o argument and seems like it passes. I guess it
>> only affects stdout output, good to know.
>> >
>> > We're using python 2.7.5 in production. I did some testing today with
>> Python 3.4.3 and it seems the 3.4.x stream at least doesn't run into this
>> issue so I'm guessing this only affects Python 2.7.x.
>>
>> I wonder if it's something that occurs with earlier 2.7 releases, I
>> thought I checked that behavior out on 2.7.9
>>
>> I'll look to check with pyenv on Monday to go over a few python versions.
>>
>>
> Hi Darragh,
>
> The extremely strange thing about this one is I've only been able to
> reproduce it in Jenkins. So imagine having JJB installed on the same server
> as your Jenkins instance or slave. If you ssh to the machine and run JJB on
> the commandline it works. Create a job running on the same system and
> Jenkins will see the failure in console logs.
>
> In case it helps with reproducing. The git repo I've been using to
> reproduce this error is this one:
>
> https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder
>
> After cloning this repo run "jenkins-jobs test -r jjb/".
>


I just tested this with Python 2.7.9 and confirm the issue still persists
for me even with 2.7.9. You can see my test here:

https://jenkins.opendaylight.org/sandbox/job/thanh-test/7/console

Regards,

Thanh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Regression in JJB 1.4.0 maximum recursion depth exceeded

[Thanh Ha]

(I truncated some of the repetitive output below)

I just tried with the -o argument and seems like it passes. I guess it only
affects stdout output, good to know.

We're using python 2.7.5 in production. I did some testing today with
Python 3.4.3 and it seems the 3.4.x stream at least doesn't run into this
issue so I'm guessing this only affects Python 2.7.x.

Regards,

Thanh


On 8 January 2016 at 12:44, Wayne Warren <wa...@puppetlabs.com> wrote:

> Hey Thanh,
>
> Looking at that stack trace and the command that causes it, it appears
> that the object whose encoding is being accessed is "sys.stdout" [1]
>
> I would suggest trying to pass a specific "-o" argument to the "test"
> subcommand to see if the stream.encoding __getattr__ recursion happens
> there also.
>
> Also, what specific minor version of Python are you using?
>
> [1]
> https://review.openstack.org/gitweb?p=openstack-infra/jenkins-job-builder.git;a=blob;f=jenkins_jobs/cmd.py;h=efafdf05fa35f93a00633489dde160c06930641d;hb=b023d7e23f77e4de33e740dcc37af911e36fb189#l115
>
> On Thu, Jan 7, 2016 at 5:40 PM, Thanh Ha <thanh...@linuxfoundation.org>
> wrote:
> > Hi JJB Devs,
> >
> > We discovered what seems to be a regression with JJB 1.4.0 which after
> some
> > git bisecting found it was caused by this patch [1]. My Jenkins verify
> > builds are failing to pass due to python runtime error:
> >
> > RuntimeError: maximum recursion depth exceeded
> >
> > This error follows what seems to be a recursive loop of python codecs
> > __getattr__ attempts. I've pasted the full traceback below. This issue
> seems
> > to only affect the command "jenkins-jobs test --recursive /path/to/jobs"
> and
> > when as part of a Jenkins verify job. Oddly enough running "jenkins-jobs
> > update --recursive /path/to/jobs" seems to pass just fine.
> >
> > Any ideas how to fix or workaround this issue?  (This issue is
> preventing us
> > from upgrading to JJB 1.4.0)
> >
> > Thanks,
> >
> > Thanh
> >
> > [1] https://review.openstack.org/183939/
> >
> >
> > Traceback (most recent call last):
> >   File "/tmp/jjbtest/jjb/bin/jenkins-jobs", line 11, in 
> > sys.exit(main())
> >   File
> "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/cmd.py",
> > line 172, in main
> > execute(options, config)
> >   File
> "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/cmd.py",
> > line 337, in execute
> > output=options.output_dir)
> >   File
> > "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/builder.py",
> line
> > 326, in update_job
> > output = utils.wrap_stream(output)
> >   File
> "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/utils.py",
> > line 25, in wrap_stream
> > stream_enc = stream.encoding
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> > return getattr(self.stream, name)
> >   File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in
> > __getattr__
> >

[OpenStack-Infra] Regression in JJB 1.4.0 maximum recursion depth exceeded

[Thanh Ha]

Hi JJB Devs,

We discovered what seems to be a regression with JJB 1.4.0 which after some
git bisecting found it was caused by this patch [1]. My Jenkins verify
builds are failing to pass due to python runtime error:

RuntimeError: maximum recursion depth exceeded

This error follows what seems to be a recursive loop of python codecs
__getattr__ attempts. I've pasted the full traceback below. This issue
seems to only affect the command "jenkins-jobs test --recursive
/path/to/jobs" and when as part of a Jenkins verify job. Oddly enough
running "jenkins-jobs update --recursive /path/to/jobs" seems to pass just
fine.

Any ideas how to fix or workaround this issue?  (This issue is preventing
us from upgrading to JJB 1.4.0)

Thanks,

Thanh

[1] https://review.openstack.org/183939/


Traceback (most recent call last):
  File "/tmp/jjbtest/jjb/bin/jenkins-jobs", line 11, in 
sys.exit(main())
  File "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/cmd.py",
line 172, in main
execute(options, config)
  File "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/cmd.py",
line 337, in execute
output=options.output_dir)
  File "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/builder.py",
line 326, in update_job
output = utils.wrap_stream(output)
  File "/tmp/jjbtest/jjb/lib/python2.7/site-packages/jenkins_jobs/utils.py",
line 25, in wrap_stream
stream_enc = stream.encoding
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__
return getattr(self.stream, name)
  File "/tmp/jjbtest/jjb/lib64/python2.7/codecs.py", line 828, in __getattr__

Re: [OpenStack-Infra] Future JJB development

[Thanh Ha]

Thanks for posting this. My concern as a consumer of JJB is that reviewers
will lose interest in reviewing JJB patches and move on if JJB is no longer
a necessary component of OpenStack CI (I feel like we are already seeing
this today). A plan is needed to ensure that there are and will continue to
be reviewers who will be promoted and are interested in keeping this
project maintained into the future after OpenStack CI has moved on.

My hope is that OpenStack would continue to host this project and promote
additional reviewers to this project who are interested in keeping this
project going. What is the path forward for those of us who are interested
in keeping this project maintained?

Thanks,

Thanh

On 29 June 2015 at 14:00, James E. Blair cor...@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.

 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.

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

 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.

 I hope that this sounds like a clear plan that benefits everyone.

 Thanks,

 Jim

 ___
 OpenStack-Infra mailing list
 OpenStack-Infra@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra