<div dir="ltr">In a different thread I had another possible suggestion - its probably more appropriate for this one. [1]<div><br></div>It would also be helpful to give the project a way to prefer certain infra providers for certain jobs. <div><br></div><div>For the most part Fort Neubla is terrible at CPU bound long running jobs... I wish I could make it better, but I cannot. </div><div><br></div><div>Is there a method we could come up with that would allow us to exploit certain traits of a certain provider? Maybe like some additional metadata that say what the certain provider is best at doing? </div><div><br></div><div>For example highly IO bound jobs work like gangbusters on FN because the underlying storage is very fast, but CPU bound jobs do the direct opposite. </div><div><br></div><div>Thoughts? ~/DonnyD<div><br></div><div><br></div><div>1. <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009592.html">http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009592.html</a></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 23, 2019 at 11:14 AM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Sep 23, 2019, at 8:03 AM, Donny Davis wrote:<br>
> *These are only observations, so please keep in mind I am only trying <br>
> to get to the bottom of efficiency with our limited resources.*<br>
> Please feel free to correct my understanding <br>
> <br>
> We have some core projects which many other projects depend on - Nova, <br>
> Glance, Keystone, Neutron, Cinder. etc<br>
> In the CI it's equal access for any project. <br>
> If feature A in non-core project depends on feature B in core project - <br>
> why is feature B not prioritized ?<br>
<br>
The priority queuing happens per "gate queue". The integrated gate (nova, cinder, keystone, etc) has one queue, Tripleo has another, OSA has one and so on. We do this so that important work can happen across disparate efforts.<br>
<br>
What this means is if Nova and the rest of the integrated gate has a set of priority changes they should stop approving other changes while they work to merge those priority items. I have suggested that OpenStack needs an "air traffic controller" to help coordinate these efforts particularly around feature freeze time (I suggested it to both the QA team and release team). Any queue could use one if they wanted to.<br>
<br>
All that to say you can do this today, but it requires humans to work together and communicate what their goals are then give the CI system the correct information to act on these changes in the desired manner.<br>
<br>
> <br>
> Can we solve this issue by breaking apart the current equal access <br>
> structure into something more granular?<br>
> <br>
> I understand that improving job efficiencies will likely result in more <br>
> smaller jobs, but will that actually solve issue at the gate come this <br>
> time in the cycle...every release? (as I am sure it comes up every time)<br>
> More smaller jobs will result in more jobs - If the job time is cut in <br>
> half, but the # of jobs is doubled we will probably still have the same <br>
> issue.<br>
> <br>
> We have limited resources and without more providers coming online I <br>
> fear this issue is only going to get worse as time goes on if we do <br>
> nothing.<br>
> <br>
> ~/DonnyD<br>
> <br>
<br>
</blockquote></div>