Add simulation video

Change-Id: I5dc8bfca61d536a825be11f7721ddb60e74c827b
This commit is contained in:
James E. Blair 2018-04-17 09:37:39 -07:00
parent d50e73ab2b
commit 0a213fc51a
5 changed files with 181 additions and 1 deletions

View File

@ -1 +0,0 @@
Placeholder.

BIN
media/simulation-poster.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 116 KiB

BIN
media/simulation.mp4 Normal file

Binary file not shown.

181
media/simulation.vtt Normal file
View File

@ -0,0 +1,181 @@
WEBVTT
00:00:00.000 --> 00:00:05.843
Zuul can be used to ensure that every commit
merged into a project has passed tests
00:00:05.844 --> 00:00:09.442
and the project continues to work
with its dependencies.
00:00:09.443 --> 00:00:14.402
When a change or pull request is approved
Zuul adds it to the gate pipeline.
00:00:14.403 --> 00:00:18.242
This pipeline holds changes to be merged
into their respective projects
00:00:18.243 --> 00:00:20.882
in the order in which they are going to merge.
00:00:20.883 --> 00:00:23.282
This ordering can be determined explicitly
00:00:23.283 --> 00:00:25.843
if a user adds a "Depends-On" line
to the commit message.
00:00:25.844 --> 00:00:30.003
In that case, Zuul will make sure that the
dependency is enqueued first
00:00:30.004 --> 00:00:32.551
followed by the change that depends on it.
00:00:32.552 --> 00:00:36.657
Or as in this case the order might simply be
determined by the order
00:00:36.658 --> 00:00:39.616
in which changes are approved
by the project's developers.
00:00:39.617 --> 00:00:41.290
In the example shown here
00:00:41.291 --> 00:00:44.174
developers have approved
two changes to Nova,
00:00:44.177 --> 00:00:45.700
one change to Keystone,
00:00:45.701 --> 00:00:48.094
followed by one more change to Nova.
00:00:48.097 --> 00:00:50.896
As soon as a change is enqueued
into the gate pipeline
00:00:50.897 --> 00:00:53.376
Zuul starts running jobs for that change.
00:00:53.377 --> 00:00:57.216
Each item in the pipeline represents
a future state of its project
00:00:57.217 --> 00:01:01.616
but also includes the future state
of all the projects ahead of it in the queue.
00:01:01.617 --> 00:01:05.136
So in this case, the tests which are running
on the second Nova change
00:01:05.137 --> 00:01:08.816
include the commit for that change
as well as the first.
00:01:08.817 --> 00:01:12.977
Nova and Keystone are tested together
in the integration test job
00:01:12.978 --> 00:01:15.596
so when that job runs on change #3
00:01:15.597 --> 00:01:17.836
it is testing not only the Keystone change
00:01:17.837 --> 00:01:20.156
but both Nova changes as well.
00:01:20.157 --> 00:01:24.071
Inside that test job,
it is as if all the changes ahead of it
00:01:24.072 --> 00:01:25.991
in the queue have already merged.
00:01:25.992 --> 00:01:30.631
In this way, Zuul tests the changes as they
would be merged into the git repository
00:01:30.632 --> 00:01:32.711
not simply as they were written.
00:01:32.712 --> 00:01:35.351
Zuul runs all of these tests in parallel
00:01:35.352 --> 00:01:36.951
but as soon as a job fails,
00:01:36.952 --> 00:01:39.491
the future that Zuul predicted
is no longer valid --
00:01:39.492 --> 00:01:42.051
we know that change is not going to merge.
00:01:42.052 --> 00:01:45.651
All of the tests for changes behind it
in the queue are outdated
00:01:45.652 --> 00:01:48.611
so Zuul cancels any running jobs
for those changes.
00:01:48.612 --> 00:01:52.051
Here we can see that not only has
change #4 failed
00:01:52.052 --> 00:01:54.451
but change #3 has as well.
00:01:54.452 --> 00:01:57.651
Because #3 failed and is no longer
eligible to merge
00:01:57.652 --> 00:02:01.171
Zuul has invalidated the earlier
test results for #4
00:02:01.172 --> 00:02:06.371
and has re-started jobs for #4 with only
changes #1 and #2 included this time.
00:02:06.372 --> 00:02:11.151
Change #3 stays in the queue in case
one of the changes ahead of it fails
00:02:11.152 --> 00:02:14.512
but unless that happens it will not be merged.
00:02:14.513 --> 00:02:17.472
As changes #1 and #2 complete their tests
00:02:17.473 --> 00:02:20.592
each of them is merged into
the Nova repository.
00:02:20.593 --> 00:02:21.794
Once that is complete
00:02:21.795 --> 00:02:26.914
it is safe to report the Keystone change #3
as having failed its tests
00:02:26.915 --> 00:02:30.274
Finally, the tests for Nova
change #4 are passing now
00:02:30.275 --> 00:02:33.714
confirming that the earlier problem
was due to the Keystone change
00:02:33.715 --> 00:02:37.053
Zuul merges the final Nova
change into the repository
00:02:37.054 --> 00:02:39.766
once all tests are complete.

BIN
media/simulation.webm Normal file

Binary file not shown.