Open Stack

On Thu, Feb 15, 2018 at 1:43 AM, Andrea Frittoli
<andrea.frittoli at gmail.com> wrote:
>
>
> On Wed, Feb 14, 2018 at 4:05 PM James E. Blair <corvus at inaugust.com> wrote:
>>
>> Andrea Frittoli <andrea.frittoli at gmail.com> writes:
>>
>> >> That has no irrelevant-files matches, and so matches everything.  If
>> >> you
>> >> drop the use of that template, it will work as expected.  Or, if you
>> >> can
>> >> say with some certainty that nova's irrelevant-files set is not
>> >> over-broad, you could move the irrelevant-files from nova's invocation
>> >> into the template, or even the job, and drop nova's individual
>> >> invocation.
>> >>
>> > I don't think projects in the integrated gate should remove themselves
>> > from the
>> > template, it really helps keeping consistency.
>> >
>> > The pattern I've seen is that most projects repeat the same list of
>> > irrelevant files
>> > over and over again in all of their integration tests, It would be handy
>> > in
>> > future to
>> > be able to set irrelevant-files on a template when it's consumed.
>> > So we could have shared irrelevant files defined in the template, and
>> > custom ones
>> > added by each project when consuming the template. I don't this is is
>> > possible today.
>> > Does it sound like a reasonable feature request?
>>
>> A template may specify many jobs, so if we added something like that
>> feature, what would the project-pipeline template application's
>> irrelevant files apply to?  All of the jobs in the template?  We could
>> do that.
>
>
> That's what I was thinking about,
>
>>
>> But it only takes one exception for this approach to fall
>> short, and while a lot of irrelevant-files stanzas for a project are
>> similar, I don't think having exceptions will be unusual.  The only way
>> to handle exceptions like that is to specify them with jobs, and we're
>> back in the same situation.
>>
>> Also, combining irrelevant-files is very difficult to think about.
>> Because it's two inverse matches, combining them ends up being the
>> intersection, not the union.  So if we implemented this, I don't think
>> we should have any irrelevant-files in the template, only on template
>> application.
>>
>> I still tend to think that irrelevant-files are almost invariably
>> project-specific, so we should avoid using them in templates and job
>> definitions (unless absolutely certain they are universally applicable),
>> and we should only define them in one place -- in the project-pipeline
>> definition for individual jobs.
>
>
> I agree with your concerns, but the problem is that the current
> implementation
> renders job templates rather useless. Each project has to re-add each job in
> a
> template in its pipeline content definition to be able to apply irrelevant
> files, and
> that will turn stale if a template is modified.
>
> With the migration to zuulv3 native jobs there is a lot of job renaming and
> adding/
> removing jobs going on, so for instance if a job is removed what used to be
> a setting
> irrelevant files may become running an extra job.
>
> I don't really have a solution for this, but perhaps someone has an idea?

I am in favor of idea of not defining the irrelevant_files in base job
definition or template and have them defined by project in
project-pipeline only. This solve most of the issue even that can ask
each project to define the common irrelevant_files.

With that, should we keep the Template limited to system one only
which are mentioned here [1] ? i mean no 'integrate-gate' etc
template.

..1 https://docs.openstack.org/infra/manual/zuulv3.html#what-to-convert

-gmann

>
> Andrea Frittoli (andreaf)
>
>>
>> -Jim
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>