Lago jobs migration to jenkins.phx.ovirt.org

[David Caro Estevez]

On 04/04 11:49, Eyal Edri wrote:
> On Mon, Apr 4, 2016 at 10:38 AM, David Caro Estevez <dcaro at redhat.com>
> wrote:
> 
> > On 04/03 20:27, Nadav Goldin wrote:
> > > Hey David,
> > > as part of the migration to jenkins.phx.ovirt.org,I want to advance with
> > > the Lago jobs. I already migrated
> > > infra-puppet/infra-docs/ovirt-node/appliance/imgbased jobs, and so far
> > they
> > > seem all to work. As far as I understand the Lago jobs are pretty
> > > independent so it should be rather simple. Currently there are 3 slaves
> > > configured (fc23, el7, fc21).
> >
> >
> > There are only 3 fc23 slaves, having one less, duplicates the check run
> > time,
> > and having only one, triplicates it, can you create new slaves instead of
> > moving them from the old jenkins? (lago is not the only one using them, so
> > migrating all of them is not an option)
> >
> 
> Is it possible to add new slaves with the current state of pxe not working?
> The ideal will be to have all new servers installed with the pxe fixed so
> we can deploy many more slaves.
> This way we can just add lots of slaves to the new jenkins.

We already have a template for fc23, it's just creating a new slave from that
template (can be done from foreman too, faster than installing from scratch).

> 
> 
> >
> >
> > >
> > > At the fist stage(until we finish the migration)
> > > jenkins_master_deploy-configs_merged is not running, so we could control
> > > which jobs get migrated. So if a patch to the jenkins yaml will be
> > > introduced during the migration process it will have to be re-run
> > manually.
> > >
> > > After migrating I'll disable the lago jobs in jenkins.ovirt.org, so
> > even if
> > > JJB runs we will have only one jenkins running the CI checks.
> >
> > Don't allow both to run anything at the same time, that will lead to
> > confusion
> > and branches being deleted at strange times on the github repo, if they
> > run on
> > one jenkins master, run them there only.
> >
> > >
> > > One more question is if there are any other jobs which are dependent on
> > the
> > > Lago jobs(like the publishers which are dependent on all build_artifacts
> > on
> > > ovirt-node/appliance/node)
> >
> > Lago is self-contained, anything lago needs (check-build-deploy) is tagged
> > as
> > lago*, any other job that uses lago, get's it from the repos.
> >
> > >
> > > As far as I understand the only thing needed for migration is updating
> > the
> > > github api tokens and running JJB with *lago*.
> >
> > And disabling the jobs on the other jenkins.
> > The github configuration is not trivial though, the api token is valid only
> > once and for a specific url. Also you have to configure the github hooks to
> > point to the new jenkins (or it will not get any events), that is done at
> > the
> > github page, under project configuration.
> >
> > >
> > > What do you think?
> > >
> > >
> > > Thanks
> > >
> > > Nadav.
> >
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> > --
> > David Caro
> >
> > Red Hat S.L.
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> >
> > Tel.: +420 532 294 605
> > Email: dcaro at redhat.com
> > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > Web: www.redhat.com
> > RHT Global #: 82-62605
> >
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> >
> 
> 
> -- 
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)

> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra


-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160404/f958d1f1/attachment.sig>