Open Stack

This is awesome news!

If I understand correctly, your description of "multiple changes" describes cases where a single change depends on multiple changes. My question is related to one-to-one dependencies in the form A -> B -> C.

I'm assuming that this is supported as well in the case where, for example, A and C are in one repository and B is in another repository, yes?

Thanks,

-amrith

| -----Original Message-----
| From: James E. Blair [mailto:corvus at inaugust.com]
| Sent: Tuesday, February 10, 2015 5:26 PM
| To: OpenStack Development Mailing List
| Cc: openstack-infra at lists.openstack.org
| Subject: [openstack-dev] Cross-Repo Dependencies in Zuul
| 
| Hi,
| 
| We have added support for cross-repo dependencies (CRD) in Zuul.  The
| important bits:
| 
| * To use them, include "Depends-On: <gerrit-change-id>" in the footer of
|   your commit message.  Use the full Change-ID ('I' + 40 characters).
| 
| * These are one-way dependencies only -- do not create a cycle.
| 
| * This is what all the grey dots and lines are in the check pipeline.
| 
| Cross-Repo Dependencies Explained
| =================================
| 
| There are two behaviors that might go by the name "cross-repo
| dependencies".  We call them one-way and multi-way.
| 
| Multi-way CRD allow for bidirectional links between changes.  For
| instance, A depends on B and B depends on A.  The theory there is that
| both would be tested together and merged as a unit.  This is _not_ what we
| have implemented in Zuul.  Discussions over the past two years have
| revealed that this type of behavior could cause problems for continuous
| deploments as it means that two components must be upgraded
| simultaneously.  Not supporting this behavior is a choice we have made.
| 
| One-way CRD behaves like a directed acyclic graph (DAG), like git itself,
| to indicate a one-way dependency relationship between changes in different
| git repos.  Change A may depend on B, but B may not depend on A.  This is
| what we have implemented in Zuul.
| 
| Gate Pipeline
| =============
| 
| When Zuul sees CRD changes, it serializes them in the usual manner when
| enqueuing them into a pipeline.  This means that if change A depends on B,
| then when they are added to the gate pipeline, B will appear first and A
| will follow.  If tests for B fail, both B and A will be removed from the
| pipeline, and it will not be possible for A to merge until B does.
| 
| Note that if changes with CRD do not share a change queue (such as the
| "integrated gate" then Zuul is unable to enqueue them together, and the
| first will be required to merge before the second is enqueued.
| 
| Check Pipeline
| ==============
| 
| When changes are enqueued into the check pipeline, all of the related
| dependencies (both normal git-dependencies that come from parent commits
| as well as CRD changes) appear in a dependency graph, as in gate.  This
| means that even in the check pipeline, your change will be tested with its
| dependency.  So changes that were previously unable to be fully tested
| until a related change landed in a different repo may now be tested
| together from the start.
| 
| All of the changes are still independent (so you will note that the whole
| pipeline does not share a graph as in gate), but for each change tested,
| all of its dependencies are visually connected to it, and they are used to
| construct the git references that Zuul uses when testing.
| When looking at this graph on the status page, you will note that the
| dependencies show up as grey dots, while the actual change tested shows up
| as red or green.  This is to indicate that the grey changes are only there
| to establish dependencies.  Even if one of the dependencies is also being
| tested, it will show up as a grey dot when used as a dependency, but
| separately and additionally will appear as its own red or green dot for
| its test.
| 
| (If you don't see grey dots on the status page, reload the page to get the
| latest version.)
| 
| Multiple Changes
| ================
| 
| A Gerrit change ID may refer to multiple changes (on multiple branches of
| the same project, or even multiple projects).  In these cases, Zuul will
| treat all of the changes with that change ID as dependencies.  So if you
| say that a tempest change Depends-On a change ID that has changes in nova
| master and nova stable/juno, then when testing the tempest change, both
| nova changes will be applied, and when deciding whether the tempest change
| can merge, both changes must merge ahead of it.
| 
| A change may depend on more than one Gerrit change ID as well.  So it is
| possible for a change in tempest to depend on a change in devstack and a
| change in nova.  Simply add more "Depends-On:" lines to the footer.
| 
| Cycles
| ======
| 
| If a cycle is created by use of CRD, Zuul will abort its work very early.
| There will be no message in Gerrit and no changes that are part of the
| cycle will be enqueued into any pipeline.  This is to protect Zuul from
| infinite loops.  I hope that we can improve this to at least leave a
| message in Gerrit in the future.  But in the meantime, please be cognizant
| of this and do not create dependency cycles with Depends-On lines.
| 
| Examples
| ========
| 
| The following two infra changes have been tested together because of the
| Depends-On: line in the commit message of the first:
| 
|   https://review.openstack.org/#/c/152508/
|   https://review.openstack.org/#/c/152504/
| 
| In fact, you can see earlier test results failing until it was rechecked
| after CRD went into production (around 2015-02-10 15:20 UTC).
| 
| This devstack change depended on a grenade change:
| 
|   https://review.openstack.org/#/c/154575/
|   https://review.openstack.org/#/c/153702/
| 
| And with CRD, was able to be tested in check together as well as being
| enqueued into the gate at the same time as its dependency.
| 
| Note that in this example, the Gerrit change ID that 154575 depends on is
| actually associated with two changes on two separate branches.  In cases
| such as this, Zuul treats all instances as dependencies (so both changes
| would be tested together, and both must merge before 154575 may).
| 
| Further Questions
| =================
| 
| This is a fairly substantial new feature, and we may still have a bit to
| learn about it.
| 
| If you have any further questions, feel free to ask here or in the
| #openstack-infra channel on Freenode.
| 
| We will update the infra manual soon to reflect this change.
| 
| -Jim
| 
| __________________________________________________________________________
| OpenStack Development Mailing List (not for usage questions)
| Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev