Open Stack

On Sun, Mar 19, 2017 at 06:54:27PM +0200, Sagi Shnaidman wrote:
> Hi, Paul
> I would say that real worthwhile try starts from "normal" priority, because
> we want to run promotion jobs more *often*, not more *rarely* which happens
> with low priority.
> In addition the initial idea in the first mail was running them each after
> other almost, not once a day like it happens now or with "low" priority.
> 
As I've said, my main reluctance is is how the gate will react if we create a
new pipeline with the same priority as our check pipeline.  I would much rather
since on caution, default to 'low', see how things react for a day / week /
month, then see what it would like like a normal.  I want us to be caution about
adding a new pipeline, as it dynamically changes how our existing pipelines
function.

Further more, this is actually a capacity issue for tripleo-test-cloud-rh1,
there currently too many jobs running for the amount of hardware. If these jobs
were running on our donated clouds, we could get away with a low priority
periodic pipeline.

Now, allow me to propose another solution.

RDO project has their own version of zuul, which has the ability to do periodic
pipelines.  Since tripleo-test-cloud-rh2 is still around, and has OVB ability, I
would suggest configuring this promoting pipeline within RDO, as to not affect
the capacity of tripleo-test-cloud-rh1.  This now means, you can continuously
enqueue jobs at a rate of 4 hours, priority shouldn't matter as you are the only
jobs running on tripleo-test-cloud-rh2, resulting in faster promotions.

This also make sense, as packaging is done in RDO, and you are triggering Centos
CI things as a result.

> Thanks
> 
> On Wed, Mar 15, 2017 at 11:16 PM, Paul Belanger <pabelanger at redhat.com>
> wrote:
> 
> > On Wed, Mar 15, 2017 at 03:42:32PM -0500, Ben Nemec wrote:
> > >
> > >
> > > On 03/13/2017 02:29 PM, Sagi Shnaidman wrote:
> > > > Hi, all
> > > >
> > > > I submitted a change: https://review.openstack.org/#/c/443964/
> > > > but seems like it reached a point which requires an additional
> > discussion.
> > > >
> > > > I had a few proposals, it's increasing period to 12 hours instead of 4
> > > > for start, and to leave it in regular periodic *low* precedence.
> > > > I think we can start from 12 hours period to see how it goes, although
> > I
> > > > don't think that 4 only jobs will increase load on OVB cloud, it's
> > > > completely negligible comparing to current OVB capacity and load.
> > > > But making its precedence as "low" IMHO completely removes any sense
> > > > from this pipeline to be, because we already run experimental-tripleo
> > > > pipeline which this priority and it could reach timeouts like 7-14
> > > > hours. So let's assume we ran periodic job, it's queued to run now 12 +
> > > > "low queue length" - about 20 and more hours. It's even worse than
> > usual
> > > > periodic job and definitely makes this change useless.
> > > > I'd like to notice as well that those periodic jobs unlike "usual"
> > > > periodic are used for repository promotion and their value are equal or
> > > > higher than check jobs, so it needs to run with "normal" or even "high"
> > > > precedence.
> > >
> > > Yeah, it makes no sense from an OVB perspective to add these as low
> > priority
> > > jobs.  Once in a while we've managed to chew through the entire
> > experimental
> > > queue during the day, but with the containers job added it's very
> > unlikely
> > > that's going to happen anymore.  Right now we have a 4.5 hour wait time
> > just
> > > for the check queue, then there's two hours of experimental jobs queued
> > up
> > > behind that.  All of which means if we started a low priority periodic
> > job
> > > right now it probably wouldn't run until about midnight my time, which I
> > > think is when the regular periodic jobs run now.
> > >
> > Lets just give it a try? A 12 hour periodic job with low priority. There is
> > nothing saying we cannot iterate on this after a few days / weeks / months.
> >
> > > >
> > > > Thanks
> > > >
> > > >
> > > > On Thu, Mar 9, 2017 at 10:06 PM, Wesley Hayutin <whayutin at redhat.com
> > > > <mailto:whayutin at redhat.com>> wrote:
> > > >
> > > >
> > > >
> > > >     On Wed, Mar 8, 2017 at 1:29 PM, Jeremy Stanley <fungi at yuggoth.org
> > > >     <mailto:fungi at yuggoth.org>> wrote:
> > > >
> > > >         On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:
> > > >         > The TripleO team would like to initiate a conversation about
> > the
> > > >         > possibility of creating a new pipeline in Openstack Infra to
> > allow
> > > >         > a set of jobs to run periodically every four hours
> > > >         [...]
> > > >
> > > >         The request doesn't strike me as contentious/controversial.
> > Why not
> > > >         just propose your addition to the zuul/layout.yaml file in the
> > > >         openstack-infra/project-config repo and hash out any resulting
> > > >         concerns via code review?
> > > >         --
> > > >         Jeremy Stanley
> > > >
> > > >
> > > >     Sounds good to me.
> > > >     We thought it would be nice to walk through it in an email first :)
> > > >
> > > >     Thanks
> > > >
> > > >
> > > >         ____________________________________________________________
> > ______________
> > > >         OpenStack Development Mailing List (not for usage questions)
> > > >         Unsubscribe:
> > > >         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > >         <http://OpenStack-dev-request@lists.openstack.org?subject:
> > unsubscribe>
> > > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/
> > openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/
> > openstack-dev>
> > > >
> > > >
> > > >
> > > >     ____________________________________________________________
> > ______________
> > > >     OpenStack Development Mailing List (not for usage questions)
> > > >     Unsubscribe:
> > > >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > >     <http://OpenStack-dev-request@lists.openstack.org?subject:
> > unsubscribe>
> > > >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > > >     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards
> > > > Sagi Shnaidman
> > > >
> > > >
> > > > ____________________________________________________________
> > ______________
> > > > 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
> > > >
> > >
> > > ____________________________________________________________
> > ______________
> > > 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
> >
> > __________________________________________________________________________
> > 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
> >
> 
> 
> 
> -- 
> Best regards
> Sagi Shnaidman

> __________________________________________________________________________
> 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