[Starlingx-discuss] upstream -infra queue setup might need tweaking to handle cross-project dependencies
Hi all, Recently we had an issue where https://review.openstack.org/#/c/578414/ was given +W before https://review.openstack.org/#/c/578413/ (which it was dependent on and was in another project) was merged. This caused https://review.openstack.org/#/c/578414/ to get "stuck" requiring a core to remove the workflow approval and re-add it, which "woke up" the process and got it merged. Talking with the folks on #openstack-infra, they said that the problem was that the two projects don't share a gate queue. In that case you can't approve a change with "depends-on" until the depended-on change has merged. The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr... This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. Chris
On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen <chris.friesen@windriver.com> wrote:
The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr...
Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532
This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense.
It think totally makes sense here... dt -- Dean Troyer dtroyer@gmail.com
On 06/27/2018 01:12 PM, Dean Troyer wrote:
On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen <chris.friesen@windriver.com> wrote:
The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr...
Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532
Looks reasonable, but I'm no expert here. Chris
Agreed, I don't think we can function without it. Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention? If the depended on review is failed or abandoned, can the blocked review by automatically dequeued? Demoted to W0? Ideally with a notification? Scott On 18-06-27 03:12 PM, Dean Troyer wrote:
The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr... Dang, I forgot this bit when setting up the jobs, so something like
On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen <chris.friesen@windriver.com> wrote: this? https://review.openstack.org/578532
This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. It think totally makes sense here...
dt
I believe the concern is related to this config in Zuul and we need to take advantage of this feature. Cross Project Testing When your projects are closely coupled together, you want to make sure changes entering the gate are going to be tested with the version of other projects currently enqueued in the gate (since they will eventually be merged and might introduce breaking features). Such relationships can be defined in Zuul configuration by placing projects in a shared queue within a dependent pipeline. Whenever changes for any project enter a pipeline with such a shared queue, they are tested together, such that the commits for the changes ahead in the queue are automatically present in the jobs for the changes behind them. https://zuul-ci.org/docs/zuul/user/gating.html On Jun 27, 2018, at 14:31, Scott Little <scott.little@windriver.com<mailto:scott.little@windriver.com>> wrote: Agreed, I don't think we can function without it. Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention? If the depended on review is failed or abandoned, can the blocked review by automatically dequeued? Demoted to W0? Ideally with a notification? Scott On 18-06-27 03:12 PM, Dean Troyer wrote: On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen <chris.friesen@windriver.com<mailto:chris.friesen@windriver.com>> wrote: The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr... Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532 This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. It think totally makes sense here... dt _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Hi there, The best way to reach the Zuul team directly to share these types of requests is to ping their ML at zuul-discuss@lists.zuul-ci.org <mailto:zuul-discuss@lists.zuul-ci.org>. You can subscribe to it here: http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss <http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss>. You can also ping them in Freenode IRC at #zuul. Thanks, Claire
On Jun 28, 2018, at 10:50 AM, Anaya casas, Hazzim I <hazzim.i.anaya.casas@intel.com> wrote:
I believe the concern is related to this config in Zuul and we need to take advantage of this feature.
Cross Project Testing When your projects are closely coupled together, you want to make sure changes entering the gate are going to be tested with the version of other projects currently enqueued in the gate (since they will eventually be merged and might introduce breaking features).
Such relationships can be defined in Zuul configuration by placing projects in a shared queue within a dependent pipeline. Whenever changes for any project enter a pipeline with such a shared queue, they are tested together, such that the commits for the changes ahead in the queue are automatically present in the jobs for the changes behind them.
https://zuul-ci.org/docs/zuul/user/gating.html <https://zuul-ci.org/docs/zuul/user/gating.html>
On Jun 27, 2018, at 14:31, Scott Little <scott.little@windriver.com <mailto:scott.little@windriver.com>> wrote:
Agreed, I don't think we can function without it.
Is there a way to get a notification sent to reviewers of the blocking review, the one that is depended on but is not recieved it's CR+2, W+1, that this review needs urgent attention?
If the depended on review is failed or abandoned, can the blocked review by automatically dequeued? Demoted to W0? Ideally with a notification?
Scott
On 18-06-27 03:12 PM, Dean Troyer wrote:
The automated way to handle this is to have all the potentially interdependent projects share a queue by specifying a common queue name. The example given was the "integrated" queue for nova and friends, as specified at https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/pr... <https://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/projects.yaml#n108> Dang, I forgot this bit when setting up the jobs, so something like
On Wed, Jun 27, 2018 at 1:43 PM, Chris Friesen <chris.friesen@windriver.com <mailto:chris.friesen@windriver.com>> wrote: this? https://review.openstack.org/578532 <https://review.openstack.org/578532>
This does potentially introduce merge delays since it will serialize merges across all the projects that share a queue, but for tightly-coupled projects it might make sense. It think totally makes sense here...
dt
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io <mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Thu, Jun 28, 2018 at 12:26 PM, Claire Massey <claire@openstack.org> wrote:
The best way to reach the Zuul team directly to share these types of requests is to ping their ML at zuul-discuss@lists.zuul-ci.org. You can subscribe to it here: http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss. You can also ping them in Freenode IRC at #zuul.
Thanks for that reminder Claire. I would add that for things related to the operation of OpenStack's Zuul #openstack-infra on freenode is the place to be, even though there is an overlap of the People Who Know between those channels.
On 18-06-27 03:12 PM, Dean Troyer wrote: Dang, I forgot this bit when setting up the jobs, so something like this? https://review.openstack.org/578532
So to clarify a bit, this was a configuration issue, Chris talked with Jeremy and Clark in -infra, and the review above[0] puts the stx-* repos into a shared gate queue. It is working its way through the review process (it already has one +2). I don't believe anything else is required, please correct me if that is wrong. dt [0] https://review.openstack.org/578532 -- Dean Troyer dtroyer@gmail.com
participants (5)
-
Anaya casas, Hazzim I
-
Chris Friesen
-
Claire Massey
-
Dean Troyer
-
Scott Little