Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/11/2015 12:09 AM, Sean Dague wrote:
> On 02/10/2015 05:47 PM, Ihar Hrachyshka wrote:
>> So cool! A comment inline.
>> 
>> On 02/10/2015 11:26 PM, James E. Blair wrote:
>>> 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.
>> 
>> Though I understand your reasoning behind not providing atomic
>> merges of multiple commits, I want to say that the feature would
>> be very useful for projects that are not decoupled enough. F.e.
>> see neutron advanced services repos that are split out of main
>> neutron project but still use lots of code from neutron
>> namespace, making it hard to introduce changes into the main repo
>> without breaking advanced services for some time. The same is
>> true for decomposed plugins and mechanism drivers for neutron.
> 
> Atomic merges across git trees is a really bad idea.
> 
> If you want atomic merges, there is an easy solution, be one git
> tree.
> 
> If you are allowing folks externally to consume your code directly
> via import, then that needs to be a stable interface that has
> deprecation rules associated with it. All else is craziness.

Long term, I can't agree more. Short term, while we decouple stuff and
in the middle of the process, that's too idealistic to be true.

Though we think about stabilizing API, moving it to a separate common
library, and even spinning up advanced services into separate services
with their own REST. It will just take some time.

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU2pUvAAoJEC5aWaUY1u57+KUH/1j3Yl4fdxGJcCIy26s3otSe
DIYopsOiQ0jb2XQ9ZlJ59Kq/KsYKUnHY46Pn6ZBH+iBBbjJke/VT8RaPZ9dJbI55
seTCi/ODEz1fYoZrhlQxRVKm7H465dBYffGKjp6eNfmL6DnIjBnvFcrL2dmKdSkV
BDGmiGBXaNJ7CDBH1PEdFoHpL7zn8ToPxgaEVEU2AH9WjIyX6gO5jYpDKvMWjvJt
O99WSY3MNVkIveFIyiISswXkJK5Bieif/DFmSlWpMKETiT/vRePjKuY0GlDKqC/r
yjKAEbC63Hu3Q0HUMJPc99XZM7TKJ5+I9krFuTw9zBy/ZfxUay5aBdgVzu65j8g=
=63NO
-----END PGP SIGNATURE-----