On 04/04 11:49, Eyal Edri wrote: > On Mon, Apr 4, 2016 at 10:38 AM, David Caro Estevez <[email protected]> > 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 > > > [email protected] > > > 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: [email protected] > > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > _______________________________________________ > > Infra mailing list > > [email protected] > > 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 > [email protected] > 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: [email protected] IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
signature.asc
Description: PGP signature
_______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
