<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
So did I understand that properly. There will be possibility to create real multi-node tests like with 3-4 nodes?
<div class=""><br class="">
</div>
<div class="">Cheers,<br class="">
<div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class="">Lubosz</div>
</div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Feb 28, 2017, at 7:13 PM, joehuang <<a href="mailto:joehuang@huawei.com" class="">joehuang@huawei.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">So cool! Look forward to multi-node jobs as first class<br class="">
<br class="">
Best Regards<br class="">
Chaoyi Huang (joehuang)<br class="">
<br class="">
________________________________________<br class="">
From: Monty Taylor [<a href="mailto:mordred@inaugust.com" class="">mordred@inaugust.com</a>]<br class="">
Sent: 01 March 2017 7:26<br class="">
To: OpenStack Development Mailing List (not for usage questions)<br class="">
Subject: [openstack-dev] Zuul v3 - What's Coming: What to expect with the       Zuul v3 Rollout<br class="">
<br class="">
Hi everybody!<br class="">
<br class="">
This content can also be found at<br class="">
<a href="http://inaugust.com/posts/whats-coming-zuulv3.html" class="">http://inaugust.com/posts/whats-coming-zuulv3.html</a> - but I've pasted it<br class="">
in here directly because I know that some folks don't like clicking links.<br class="">
<br class="">
tl;dr - At last week's OpenStack PTG, the OpenStack Infra team ran the<br class="">
first Zuul v3 job, so it's time to start getting everybody ready for<br class="">
what's coming<br class="">
<br class="">
**Don't Panic!** Awesome changes are coming, but you are NOT on the hook<br class="">
for rewriting all of your project's gate jobs or anything crazy like<br class="">
that. Now grab a seat by the fire, pour yourself a drink while I spin a<br class="">
yarn about days gone by and days yet to come.<br class="">
<br class="">
First, some background<br class="">
<br class="">
The OpenStack Infra team has been hard at work for quite a while on a<br class="">
new version of Zuul (where by 'quite some time' I mean that Jim Blair<br class="">
and I had our first Zuul v3 design whiteboarding session in 2014). As<br class="">
you might be able to guess given the amount of time, there are some big<br class="">
things coming that will have a real and visible impact on the OpenStack<br class="">
community and beyond. Since we have a running Zuul v3 now [1], it seemed<br class="">
like the time to start getting folks up to speed on what to expect.<br class="">
<br class="">
There is other deep-dive information on architecture and rationale if<br class="">
you're interested[2], but for now we'll focus on what's relevant for end<br class="">
users. We're also going to start sending out a bi-weekly "Status of Zuul<br class="">
v3" email to the <a href="mailto:openstack-dev@lists.openstack.org" class="">openstack-dev@lists.openstack.org</a> mailing list ... so<br class="">
stay tuned!<br class="">
<br class="">
**Important Note** This post includes some code snippets - but v3 is<br class="">
still a work in progress. We know of at least one breaking change that<br class="">
is coming to the config format, so please treat this not as a tutorial,<br class="">
but as a conceptual overview. Syntax is subject to change.<br class="">
<br class="">
The Big Ticket Items<br class="">
<br class="">
While there are a bunch of changes behind the scenes, there are a<br class="">
reasonably tractable number of user-facing differences.<br class="">
<br class="">
* Self-testing In-Repo Job Config<br class="">
* Ansible Job Content<br class="">
* First-class Multi-node Jobs<br class="">
* Improved Job Reuse<br class="">
* Support for non-OpenStack Code and Node Systems<br class="">
* and Much, Much More<br class="">
<br class="">
Self-testing In-Repo Job Config<br class="">
<br class="">
This is probably the biggest deal. There are a lot of OpenStack Devs<br class="">
(around 2k in Ocata) and a lot of repositories (1689) There a lot fewer<br class="">
folks on the project-config-core team who are the ones who review all of<br class="">
the job config changes (please everyone thank Andreas Jaeger next time<br class="">
you see him). That's not awesome.<br class="">
<br class="">
Self-testing in-repo job config is awesome.<br class="">
<br class="">
Many systems out there these days have an in-repo job config system.<br class="">
Travis CI has had it since day one, and Jenkins has recently added<br class="">
support for a Jenkinsfile inside of git repos. With Zuul v3, we'll have<br class="">
it too.<br class="">
<br class="">
Once we roll out v3 to everyone, as a supplement to jobs defined in our<br class="">
central config repositories, each project will be able to add a<br class="">
zuul.yaml file to their own repo:<br class="">
<br class="">
<br class="">
- job:<br class="">
   name: my_awesome_job<br class="">
   nodes:<br class="">
     - name: controller<br class="">
       label: centos-7<br class="">
<br class="">
- project:<br class="">
   name: openstack/awesome_project<br class="">
   check:<br class="">
     jobs:<br class="">
       - my_awesome_job<br class="">
<br class="">
It's a small file, but there is a lot going on, so let's unpack it.<br class="">
<br class="">
First we define a job to run. It's named my_awesome_job and it needs one<br class="">
node. That node will be named controller and will be based on the<br class="">
centos-7 base node in nodepool.<br class="">
<br class="">
In the next section, we say that we want to run that job in the check<br class="">
pipeline, which in OpenStack is defined as the jobs that run when<br class="">
patchsets are proposed.<br class="">
<br class="">
And it's also self-testing!<br class="">
<br class="">
Everyone knows the fun game of writing a patch to the test jobs, getting<br class="">
it approved, then hoping it works once it starts running. With Zuul v3<br class="">
in-repo jobs, if there is a change to job definitions in a proposed<br class="">
patch, that patch will be tested with those changes applied. And since<br class="">
it's Zuul, Depends-On footers are honored as well - so iteration on<br class="">
getting a test job right becomes just like iterating on any other patch<br class="">
or sequence of patches.<br class="">
<br class="">
Ansible Job Content<br class="">
<br class="">
The job my_awesome_job isn't very useful if it doesn't define any<br class="">
content. That's done in the repo as well, in playbooks/my_awesome_job.yaml:<br class="">
<br class="">
<br class="">
- hosts: controller<br class="">
 tasks:<br class="">
   - name: Run make tests<br class="">
     shell: make distcheck<br class="">
<br class="">
As previously mentioned, the job content is now defined in Ansible<br class="">
rather than using our Jenkins Job Builder tool. This playbook is going<br class="">
to run a tasks on a host called controller which you may remember we<br class="">
requested in the job definition. On that host, it will run make<br class="">
distcheck. Pretty much anything you can do in Ansible, you can do in a<br class="">
Zuul job now, and the playbooks should also be re-usable outside of a<br class="">
testing context.<br class="">
<br class="">
First Class Multi-Node Jobs<br class="">
<br class="">
The previous example was for running a job on a node. What if you want<br class="">
to do multi-node?<br class="">
<br class="">
<br class="">
- job:<br class="">
   name: my_awesome_job<br class="">
   nodes:<br class="">
     - name: controller<br class="">
       label: ubuntu-xenial<br class="">
     - name: compute<br class="">
       label: centos-7<br class="">
<br class="">
- project:<br class="">
   name: openstack/awesome_project<br class="">
   check:<br class="">
     jobs:<br class="">
       - my_awesome_job<br class="">
<br class="">
As you may have surmised, nodes is a list, so you can have more than<br class="">
one. Then, since Ansible is naturally mutli-node aware, you use that to<br class="">
write the multi-node content:<br class="">
<br class="">
<br class="">
- hosts: controller<br class="">
 tasks:<br class="">
   - name: Install Keystone<br class="">
     shell: pip install {{ zuul.git_root }}/openstack/keystone<br class="">
- hosts: compute<br class="">
 tasks:<br class="">
   - name: Install Nova<br class="">
     shell: pip install {{ zuul.git_root }}/openstack/nova<br class="">
- hosts: *<br class="">
 tasks:<br class="">
   - name: Install CloudKitty<br class="">
     shell: pip install {{ zuul.git_root }}/openstack/cloudkitty<br class="">
<br class="">
That will install Keystone on controller, Nova on compute and CloudKitty<br class="">
on both.<br class="">
<br class="">
Improved Job Reuse<br class="">
<br class="">
In our current system, because of some details about how Jenkins works<br class="">
and the fact that our CI system used to be based on Jenkins, we have a<br class="">
ton of templated jobs that lead both to magically long job names and a<br class="">
bunch of cargo culting of job definitions.<br class="">
<br class="">
In the new system, a lot of the duplication goes away. So instead of<br class="">
having gate-nova-python27 and gate-swift-python27 and<br class="">
gate-keystone-python27, there will just be a job called "python27" and<br class="">
each of the projects can use it. Similarly, for more complex job content<br class="">
like devstack-gate, since Ansible is a fully-fledged system on its own<br class="">
that was designed for modularity and re-use, we can compose things into<br class="">
roles that take parameters and can be reused without copy/paste.<br class="">
<br class="">
(ssssh! In fact, the python27 job will almost certainly be a job that<br class="">
uses an extremely small playbook that itself uses a role called tox. But<br class="">
also, the tox role, the python27 playbook and the python27 job<br class="">
definition will all be things we define centrally in a standard library<br class="">
of pieces, so as a user of the system you should be able to just choose<br class="">
to run "python27" and not worry about it - unless you want to dig in and<br class="">
learn more.)<br class="">
<br class="">
Support for non-OpenStack Code and Node Systems<br class="">
<br class="">
Zuul was originally written to support the OpenStack project, but since<br class="">
then we've grown more people who have interest in running Zuul. Since we<br class="">
wrote it the first time to solve our problems of extremely massive<br class="">
scale, we didn't put a ton of effort into making it easily consumable<br class="">
elsewhere. That hasn't stopped people, and there are tons of Zuul<br class="">
installations out there ... but that doesn't mean life is easy for those<br class="">
folks. With Zuul v3 we've also been explicitly focused on making it much<br class="">
more easily reconsumable.<br class="">
<br class="">
Part of supporting friends in other communities means embracing support<br class="">
of tools that OpenStack does not use. The fine folks at Gooddata wrote a<br class="">
set of patches adding support for Github which they have been using for<br class="">
a while. We'll be landing those, which should allow us to add jobs to<br class="">
the system that check things like "will this pull request to pip break<br class="">
devstack". There is also work from the CentOS community via a tool<br class="">
called linch-pin that we're looking at incorporating into Nodepool that<br class="">
should allow creating build nodes on any system Ansible knows how to<br class="">
talk to. Those features are intended to follow quickly on after we get<br class="">
OpenStack migrated.<br class="">
<br class="">
What's Next?<br class="">
<br class="">
1) Zuul on Zuul<br class="">
2) Infra Repos<br class="">
3) Job conversion Script<br class="">
4) OpenStack Migration<br class="">
<br class="">
We currently have a Zuul v3 running against changes to the Zuul repo.<br class="">
We're using to iterate on job content and other features. There is a<br class="">
change coming to the job definition syntax to allow job dependencies to<br class="">
be a graph instead of just a tree which will be fairly invasive, so<br class="">
we're keeping the affected surface area small until that's ready.<br class="">
<br class="">
Once we're happy with how things are running, we'll move the rest of the<br class="">
Infra repos over, probably in chunks. Although Infra test jobs are<br class="">
typically a bit different than the jobs in the rest of OpenStack, we do<br class="">
have enough representative examples that we should be able to work out<br class="">
the kinks before we throw things at other folks. (shade and nodepool<br class="">
both do integration testing on devstack-gate jobs, for instance)<br class="">
<br class="">
While we work on Infra migration, we'll be developing a conversion<br class="">
script to convert the existing jobs. A good portion of that will be<br class="">
fully automatable. For instance, mapping everyone's<br class="">
gate-{project}-python27 to a reference to the python27 job is easy for a<br class="">
computer to do. However, there's still a ton of snowflake jobs that<br class="">
we'll likely wind up just converting the content of as is and then<br class="">
iterating on refactoring to be more efficient or improved over time.<br class="">
<br class="">
Then the Big Day will arrive. When the conversion script is as good as<br class="">
we can get it and we're satisfied with stability of the job language,<br class="">
security and scalability, there will be a Big Bang cutover of all of the<br class="">
rest of OpenStack. If all goes well, most developers should mostly just<br class="">
notice that a bunch of job names got shorter and that it's a user named<br class="">
Zuul commenting on patches. Folks who have patches to project-config<br class="">
in-flight at that time will need to rework patches, but the conversion<br class="">
script should hopefully make that a minimal burden.<br class="">
<br class="">
and Much, Much More<br class="">
<br class="">
There are far too many new and exciting things in Zuul v3 to cover in a<br class="">
single post, and many of the topics (such as Ansible Jobs, or Job<br class="">
Inheritance and Reuse) are deep topics we can dive in to over time. The<br class="">
long and short of it is that Zuul v3 is coming soon to an OpenStack<br class="">
Infra near you, so expect more and more communication about what that<br class="">
means over the next few months.<br class="">
<br class="">
Notes<br class="">
<br class="">
[1] OpenStack is not running Zuul v3 in production at the moment. We<br class="">
have an instance running and only responding to events from the Zuul v3<br class="">
repo. As of the time of this writing, OpenStack is still running 2.5 in<br class="">
production. Believe me - when we hit production, you'll know it.<br class="">
<br class="">
[2] Links to deeper information:<br class="">
* "There is no Jenkins, only Zuul" post about Zuul 2.5<br class="">
  <a href="http://amo-probos.org/post/18" class="">http://amo-probos.org/post/18</a><br class="">
* Jim Blair's Zuul v3 Talk from OpenStack Summit Barcelona<br class="">
  <a href="https://www.youtube.com/watch?v=R4EmE1QEvNU" class="">https://www.youtube.com/watch?v=R4EmE1QEvNU</a><br class="">
* Zuul v3 Spec<br class="">
  <a href="https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html" class="">https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html</a><br class="">
* Pre-PTG Zuul v3 Conceptual Deep Dive<br class="">
<br class="">
<a href="http://lists.openstack.org/pipermail/openstack-infra/2017-February/005131.html" class="">http://lists.openstack.org/pipermail/openstack-infra/2017-February/005131.html</a><br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>