Open Stack

Hi Dmitry,

> I'm not sure why removing of *_ssh drivers from master should
> necessary break stable/mitaka, where these drivers are present. Could
> you elaborate?

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.

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.

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.

On Thu, Mar 2, 2017 at 12:39 PM, Dmitry Tantsur <dtantsur at redhat.com> wrote:

> On 03/01/2017 08:19 PM, Jay Faulkner wrote:
>
>>
>> On Mar 1, 2017, at 11:15 AM, Pavlo Shchelokovskyy <
>>> pshchelokovskyy at mirantis.com> wrote:
>>>
>>> Greetings ironicers,
>>>
>>> I'd like to discuss the state of the gates in ironic and other related
>>> projects for stable/mitaka branch.
>>>
>>> Today while making some test patches to old branches I discovered the
>>> following problems:
>>>
>>> python-ironicclient/stable/mitaka
>>> 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).
>>> I've proposed a patch that copies current way of dealing with upper
>>> constraints in tox envs [0], gates are passing.
>>>
>>> ironic/stable/mitaka
>>> 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.
>>> This highlights a question whether we should propose virtualbmc to upper
>>> constraints too to avoid such problems in the future.
>>> Meanwhile a quick fix would be to hard-code the supported virtualbmc
>>> version in the ironic's devstack plugin for mitaka release.
>>> 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.
>>>
>>> I did not test other projects yet.
>>>
>>>
>> 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.
>>
>
> Oh, fun.
>
> 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..


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:

- docs job - need to be disabled for ironic-lib/mitaka in project-config

- 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
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]
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)
This is already kind of tested with this layered depends-on patch [2] -
those ipmitool jobs are passing

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

[0] https://review.openstack.org/#/c/440348/
[1] https://review.openstack.org/#/c/440559/
[2] https://review.openstack.org/#/c/440562/

Cheers,


>
>
>> -
>> Jay Faulkner
>> OSIC
>>
>> 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.
>>>
>>> [0] https://review.openstack.org/#/c/439742/
>>> [1] https://releases.openstack.org/#release-series
>>>
>>> Cheers,
>>> Dr. Pavlo Shchelokovskyy
>>> Senior Software Engineer
>>> Mirantis Inc
>>> www.mirantis.com
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.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:unsubscrib
>> e
>> 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
>


Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170302/2c621d9f/attachment.html>