converting networking functional tests ci job

Mike Burns mburns at redhat.com
Thu Aug 22 13:45:14 UTC 2013


On 08/22/2013 09:03 AM, Giuseppe Vallarelli wrote:
> ----- Original Message -----
> | From: "Eyal Edri" <eedri at redhat.com>
> | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | Cc: "infra" ovirt.org>
> | Sent: Thursday, August 22, 2013 1:38:13 PM
> | Subject: Re: converting networking functional tests ci job
> |
> | Hi Giuseppe,
> |
> | before converting that job to run per patch,
> | can you please elaborate on the jobs's profile:
> |
> | 1. how long will it run?
>
> Right now with the current tests it takes around 8 mins,
> but I got other 5/6 patches which add more of them.
> I expect around 10/12 min but it will grow over time
> as we add more functional tests.
>

> | 2. can it run in parallel to other jobs?
>
> It can run with vdsm unit tests but not with another instance of
> functional tests.

Easy enough to do this.  There are job throttling options that let you 
only run a single instance of the job per machine.

It may be worthwhile to generate some small jenkins slaves for jobs like 
this that can be long running and cannot co-exist with multiple 
instances of itself.

>
> | 3. does it affect the slave (in terms of other jobs will fail on it..)
>
> It shouldn't affect the slave, but it's something that I experienced
> when NetworkManager was interfering with vdsm network code, basically
> we lost connection with the slave. It's something that unfortunately
> can happen.

This is somewhat concerning if the slave loses it's connection with the 
jenkins master.  We would need to monitor it closely so we can recover 
the machine asap after this type of failure

>
> | 4. how do you plan to differ between network commits and other commits?
>
> Not so long ago, if I recall correctly you proposed a tag-like mechanism
> so we can distinguish patchset that needs network functional tests
> and patchset that do not. Otherwise the other alternative might be
> to detect changes in the networking modules, if the patchset touches
> one of the network modules than this job is triggered the only downside
> is that we should keep track of the networking modules and probably
> add them manually when we create new networking modules.

It is possible to do path-based decisions for this.  Only run if the 
patch makes a change to files in /path/to/directory

>
> Thanks Giuseppe
>
> |
> | thanks,
> |
> | eyal.
> |
> | ----- Original Message -----
> | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
> | > To: "infra" ovirt.org>
> | > Sent: Thursday, August 22, 2013 2:16:01 PM
> | > Subject: converting networking functional tests ci job
> | >
> | > Hello everybody!
> | > I've been able to create a good enough jenkins job config
> | > (kudos to dcaro as well :-)) for the vdsm functional networking
> | > tests. I think that the next step is to convert this per commit
> | > job on a per patch basis. I'm available for details/help in case
> | > of need.
> | >
> | > Right now the job is running on a fedora19 vm and during the process
> | > we need to disable network manager otherwise it conflicts with
> | > vdsm networking code.
> | >
> | > Thanks a lot,
> | >
> | > Giuseppe
> | >
> | >
> | >
> | >
> | >
> | > _______________________________________________
> | > Infra mailing list
> | > Infra at ovirt.org
> | > http://lists.ovirt.org/mailman/listinfo/infra
> | >
> |
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>




More information about the Infra mailing list