Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul
On 06/20/2016 06:47 AM, Marek Zawadzki wrote: > Are 3d party CIs affected by this change and if yes how? > What's the recommendation for newly created 3rd party CIs - should they > use new zuul only or it's fine to use existing (and tested) jenkins+zuul > configuration? 3rd party should not be affected. Gerrit event stream and reporting interface remain the same. People should continue using jenkins+zuul as they currently do. We'll have a full zuul v3 release coming in a few months where we'll start suggesting 3rd party folks migrate - but even then it'll be an option as you decide you'd like to. > Second question - if jobs are to be launched by zuul+ansible, how will > the worker host be chosen, by ansible-launcher? (normally as I > understand Jenkins master takes care of deciding which hosts are free to > run jobs) > Are there any specs about way of managing workers (adding/removing, > setting # of executors)? Yes, ansible-launcher takes care of this. We haven't spent too much time on more advanced worker management for this release, that should also come in zuul v3. For right now we're just managing ansible-launcher nodes as we did jenkins masters before. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul
On Mon, Jun 20, 2016 at 01:47:24PM +0200, Marek Zawadzki wrote: > Are 3d party CIs affected by this change and if yes how? > What's the recommendation for newly created 3rd party CIs - should they use > new zuul only or it's fine to use existing (and tested) jenkins+zuul > configuration? > 3rd party CI should not be affected by recent changes. As there interface to our CI system is gerrit (review.openstack.org). Zuulv25 is really only meant to be consumed by openstack-infra as a stepping stone to zuulv3. At this time I would not recommend people update their CI systems to consume it. > Second question - if jobs are to be launched by zuul+ansible, how will the > worker host be chosen, by ansible-launcher? (normally as I understand > Jenkins master takes care of deciding which hosts are free to run jobs) > Are there any specs about way of managing workers (adding/removing, setting > # of executors)? > This was and still is controlled by nodepool[1]. Even when we used jenkins, nodepool was responsible for creating our jenkins slaves. Under zuulv25, this is still the case except they are called zuul workers now. [1] http://docs.openstack.org/infra/nodepool/ > Thank you. > > -marek > > -- > Marek Zawadzki > Mirantis Containerized Control Plane Team > > > ___ > OpenStack-Infra mailing list > openstack-in...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul
Are 3d party CIs affected by this change and if yes how? What's the recommendation for newly created 3rd party CIs - should they use new zuul only or it's fine to use existing (and tested) jenkins+zuul configuration? Second question - if jobs are to be launched by zuul+ansible, how will the worker host be chosen, by ansible-launcher? (normally as I understand Jenkins master takes care of deciding which hosts are free to run jobs) Are there any specs about way of managing workers (adding/removing, setting # of executors)? Thank you. -marek -- Marek Zawadzki Mirantis Containerized Control Plane Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul
On 2016-06-17 01:48:08 +0200 (+0200), Thomas Goirand wrote: > What will be the faith of jenkins job builder then? It is already used > by lots of people, including some Debian folks. Will it be maintained? Jenkins Job Builder is very actively maintained by contributors and reviewers from many organizations beyond OpenStack, and will continue to have a happy home hosted within our infrastructure for as long as its caretakers would like. Note that with the current Zuul implementation, even though the OpenStack upstream CI is not using Jenkins any longer, we're still using JJB as a library within Zuul because we need to be able to parse our current massive set of job configurations. Also, Zuul 2.x continues to support using Jenkins as a worker (it just now also supports using its own Ansible-based launcher too). -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] There is no Jenkins, only Zuul
On 2016-06-16 16:15:34 -0700 (-0700), Joshua Harlow wrote: [...] > Is the goal/idea that there would be something like a > '.travis.yml' (file or directory) that would contain the job > configuration (and any special jobs or commands or tasks) in the > project repository that zuul would then use and do things with > (thus becoming more distributed, and self-configurable and more > like travis CI than what previously existed)? [...] That's one of the primary design goals for Zuul v3. See the third paragraph at http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html#tenants for a bit about it (and please help us implement if you find this interesting!). Not that it's particularly attempting to replicate features from other job management systems, but we do want projects to have the freedom to take more control over some of their job definitions without needing our already overworked reviewers on every tweak. Also this makes changes to many of those jobs self-testing, so less job breakage and fewer iterations on the configuration. Note that Zuul v2(.5) is still relying solely on central job configuration in the openstack-infra/project-config repo, the above is purely in reference to aspects of the v3 redesign. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
