<div dir="ltr">Hi Dmitry,<div><br></div><div><span style="color:rgb(0,0,0);font-size:12.8px">> I'm not sure why removing of *_ssh drivers from master should</span></div><div><span style="color:rgb(0,0,0);font-size:12.8px">> necessary break stable/mitaka, where these drivers are present. Could</span></div><div><span style="color:rgb(0,0,0);font-size:12.8px">> you elaborate?</span><br></div><div><span style="color:rgb(0,0,0);font-size:12.8px"><br></span></div><div><font color="#000000"><span style="font-size:12.8px">My main concern is the following: both project-config and devstack-gate are branch-less. When removing the *_ssh drivers from tree, we have to remove them from 'enabled_drivers' list in ironic.conf too (so that conductor would not fail to start). Most our jobs are not setting enabled_drivers themselves, but use whatever devstack-gate is setting. Currently it enables either pxe_ssh+pxe_ipmitool, or agent_ssh+agent_ipmitool (depending on deploy driver starting with 'agent' or not). If we drop *_ssh from enabled_drivers in devstack-gate, then the jobs that actually use *_ssh will fail instead.</span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">AFAIU this affects only mitaka branch, so a possible way of moving forward is actually let it EOL and then continue with *_ssh drivers removal.</span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.8px">I'm also kind of wondering what the grenade job in stable/newton will test after mitaka EOL? upgrade from mitaka-eol tag to stable/newton branch? Then even that might be affected if devstack-gate + project config will not be able to set *_ssh in enabled drivers while grenade will try to use them.</span></font></div><div><font color="#000000"><span style="font-size:12.8px"><br></span></font></div><div>On Thu, Mar 2, 2017 at 12:39 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-9182447742761487008gmail-">On 03/01/2017 08:19 PM, Jay Faulkner wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Mar 1, 2017, at 11:15 AM, Pavlo Shchelokovskyy <<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>> wrote:<br>
<br>
Greetings ironicers,<br>
<br>
I'd like to discuss the state of the gates in ironic and other related projects for stable/mitaka branch.<br>
<br>
Today while making some test patches to old branches I discovered the following problems:<br>
<br>
python-ironicclient/stable/mit<wbr>aka<br>
All unit-test-like jobs are broken due to not handling upper constraints. Because of it a newer than actually supported python-openstackclient is installed, which already lacks some modules python-ironicclient tries to import (these were moved to osc-lib).<br>
I've proposed a patch that copies current way of dealing with upper constraints in tox envs [0], gates are passing.<br>
<br>
ironic/stable/mitaka<br>
While not actually being gated on, using virtualbmc+ipmitool drivers is broken. The reason is again related to upper constraints as what happens is old enough version of pyghmi (from mitaka upper constraints) is installed with most recent virtualbmc (not in upper constraints), and those versions are incompatible.<br>
This highlights a question whether we should propose virtualbmc to upper constraints too to avoid such problems in the future.<br>
Meanwhile a quick fix would be to hard-code the supported virtualbmc version in the ironic's devstack plugin for mitaka release.<br>
Although not strictly supported for Mitaka release, I'd like that functionality to be working on stable/mitaka gates to test for upcoming removal of *_ssh drivers.<br>
<br>
I did not test other projects yet.<br>
<br>
</blockquote>
<br>
I can attest jobs are broken for stable/mitaka on ironic-lib as well — our jobs build docs unconditionally, and ironic-lib had no docs in Mitaka.<br>
</blockquote>
<br></span>
Oh, fun.<br>
<br>
Well, the docs job is easy to exclude. But we seem to have virtualbmc-based jobs there. As I already wrote in another message, I'm not even sure they're supposed to work..</blockquote><div><br></div><div>Yes, the ironic-lib:mitaka is kind of completely broken currently :( There are several pieces that need to be fixed to get it back to healthy state (even if only to leave it healthy for EOL). Luckily (or not?), most of the fixes go thru other projects, so it is doable without one giant squashed commit:</div><div><br></div><div>- docs job - need to be disabled for ironic-lib/mitaka in project-config</div><div><br></div><div>- gate-tempest-dsvm-ironic-lib-* - two of them are gating, so they must be fixed. they are affected by that very virtualbmc+pyghmi incompatibility. The fix would be to</div><div>1) introduce virtualbmc to requirements:master and cherry-pick that (with version changes) all the way down to mitaka. patch to master is already here [0]</div><div>2) make a patch to ironic's devstack plugin master to install virtualbmc minding u-c (3 chars fix :) ) and cherry-pick that all the way down to mitaka as well (test patch to mitaka is here [1], will have to be replaced with proper cherry-pick from master)</div><div>This is already kind of tested with this layered depends-on patch [2] - those ipmitool jobs are passing</div><div><br></div><div>- ironic-lib-coverage-* - in ironic-lib:mitaka tox jobs also do not use u-c, but it seems it is not the reason of failures here, as the current "tox -recover" does not pass neither with u-c from mitaka, nor without them. I have a fix, which is again single character :) (wondering how it was working before :) ), and could be probably introduced together with a cherry-pick for u-c handling. But for it to merge, all the other jobs must be fixed beforehand.</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/440348/" target="_blank">https://review.openstack.<wbr>org/#/c/440348/</a></div><div>[1] <a href="https://review.openstack.org/#/c/440559/">https://review.openstack.org/#/c/440559/</a></div><div>[2] <a href="https://review.openstack.org/#/c/440562/" target="_blank">https://review.openstack.<wbr>org/#/c/440562/</a></div><div><br></div><div>Cheers, </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-9182447742761487008gmail-HOEnZb"><div class="gmail-m_-9182447742761487008gmail-h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-<br>
Jay Faulkner<br>
OSIC<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
With all the above, the question is should we really fix the gates for the mitaka branch now? According to OpenStack release page [1] the Mitaka release will reach end-of-life on April 10, 2017.<br>
<br>
[0] <a href="https://review.openstack.org/#/c/439742/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/439742/</a><br>
[1] <a href="https://releases.openstack.org/#release-series" rel="noreferrer" target="_blank">https://releases.openstack.org<wbr>/#release-series</a><br>
<br>
Cheers,<br>
Dr. Pavlo Shchelokovskyy<br>
Senior Software Engineer<br>
Mirantis Inc<br>
<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br class="gmail-m_-9182447742761487008gmail-Apple-interchange-newline"><br clear="all"><div><div class="gmail-m_-9182447742761487008gmail_signature"><div dir="ltr"><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a></div></div></div></div></div></div></div>