--qLni7iB6Dl8qUSwk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 04/04 11:49, Eyal Edri wrote:
On Mon, Apr 4, 2016 at 10:38 AM, David Caro Estevez
<dcaro(a)redhat.com>
wrote:
=20
> On 04/03 20:27, Nadav Goldin wrote:
> > Hey David,
> > as part of the migration to jenkins.phx.ovirt.org,I want to advance w=
ith
> > 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 slav=
es
> > 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)
>
=20
Is it possible to add new slaves with the current state of pxe not workin=
g?
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 th=
at
template (can be done from foreman too, faster than installing from scratch=
).
=20
=20
>
>
> >
> > At the fist stage(until we finish the migration)
> > jenkins_master_deploy-configs_merged is not running, so we could cont=
rol
> > 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_artifa=
cts
> on
> > ovirt-node/appliance/node)
>
> Lago is self-contained, anything lago needs (check-build-deploy) is tag=
ged
> 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 hook=
s 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(a)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(a)redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web:
www.redhat.com
> RHT Global #: 82-62605
>
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/infra
>
>
=20
=20
--=20
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
=20
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web:
www.redhat.com
RHT Global #: 82-62605
--qLni7iB6Dl8qUSwk
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJXAitQAAoJEEBxx+HSYmnDf+gH/0Ne8j0VPyxvn0PcFSxz4luD
lQBNKg+WD25dXY55Ly9XKBzxoONAYWKwbY8jB392rnPFMZUK5hoq/cky1jmHP23L
SHGTKFLMhtBne1RzE5u1hVQV266kTS0CKwPAGVwgdGHKV+VGT7C/4y/bZWNlGR+c
ZaYj2ekHjDyIHwfh1wFPODvEfUcnp2FrsOPE2fEJWZPQvI5m4ORdPUjqBE7k3aAS
1JudRfInFWGxsdwzi2X18+M816MApWJTYrzew1BltJFrIyOfAXOHvBvy8/H1Ansy
2n2a6qKzitx78N9niJynonqUNNAe2j/IrmB0sQ63Nfr2Z2HCeRCxy1PUKCXWG20=
=HLFa
-----END PGP SIGNATURE-----
--qLni7iB6Dl8qUSwk--