Open Stack

On 02/17/2016 08:30 AM, Dmitry Tantsur wrote:
> On 02/17/2016 02:22 PM, John Trowbridge wrote:
>>
>>
>> On 02/17/2016 06:27 AM, Dmitry Tantsur wrote:
>>> Hi everyone!
>>>
>>> Yesterday on the Ironic midcycle we agreed that we would like to remove
>>> support for the old bash ramdisk from our code and gate. This, however,
>>> pose a problem, since we still support Kilo and Liberty. Meaning:
>>>
>>> 1. We can't remove gate jobs completely, as they still run on
>>> Kilo/Liberty.
>>> 2. Then we should continue to run our job on DIB, as DIB does not have
>>> stable branches.
>>> 3. Then we can't remove support from Ironic master as well, as it would
>>> break DIB job :(
>>>
>>> I see the following options:
>>>
>>> 1. Wait for Kilo end-of-life (April?) before removing jobs and code.
>>> This means that the old ramdisk will essentially be supported in Mitaka,
>>> but we'll remove gating on stable/liberty and stable/mitaka very soon.
>>> Pros: it will happen soon. Cons: in theory we do support the old ramdisk
>>> on Liberty, so removing gates will end this support prematurely.
>>>
>>> 2. Wait for Liberty end-of-life. This means that the old ramdisk will
>>> essentially be supported in Mitaka and Newton. We should somehow
>>> communicate that it's not official and can be dropped at any moment
>>> during stable branches life time. Pros: we don't drop support of the
>>> bash ramdisk on any branch where we promised to support it. Cons: people
>>> might assume we still support the old ramdisk on Mitaka/Newton; it will
>>> also take a lot of time.
>>>
>>> 3. Do it now, recommend Kilo users to switch to IPA too. Pros: it
>>> happens now, no confusing around old ramdisk support in Mitaka and
>>> later. Cons: probably most Kilo users (us included) are using the bash
>>> ramdisk, meaning we can potentially break them when landing changes on
>>> stable/kilo.
>>>
>>
>> I think if we were to do this, then we need to backport LIO support in
>> IPA to liberty and kilo. While the bash ramdisk is not awesome to
>> troubleshoot, tgtd is not great either, and the bash ramdisk has
>> supported LIO since Kilo. However, there is not stable/kilo branch in
>> IPA, so that backport is impossible. I have not looked at how hard the
>> stable/liberty backport would be, but I imagine not very.
>>
>>> 4. Upper-cap DIB in stable/{kilo,liberty} to the current release, then
>>> remove gates from Ironic master and DIB, leaving them on Kilo and
>>> Liberty. Pros: we can remove old ramdisk support right now. Cons: DIB
>>> bug fixes won't affect kilo and liberty any more.
>>>
>>> 5. The same as #4, but only on Kilo.
>>>
>>> As gate on stable/kilo is not working right now, and end-of-life is
>>> quickly approaching, I see number 3 as a pretty viable option anyway. We
>>> probably won't land any more changes on Kilo, so no use in keeping gates
>>> on it. Liberty is still a concern though, as the old ramdisk was only
>>> deprecated in Liberty.
>>>
>>> What do you all think? Did I miss any options?
>>
>> My favorite option would be 5 with backport of LIO support to liberty
>> (since backport to kilo is not possible). That is the only benefit of
>> the current bash ramdisk over the liberty/kilo IPA ramdisk. This is not
>> just for RHEL, but RHEL derivatives like CentOS which the RDO distro is
>> based on. (technically tgt can still be installed from EPEL, but there
>> is a reason it is not included in the base repos)
> 
> Oh, that's a good catch, IPA is usable on RHEL starting with Mitaka... I
> wonder if having stable branches for IPA was a good idea at all,
> especially provided that our gate is using git master on all branches.
> 

Interesting, I did not know that master is used for all gates. Maybe RDO
should just build liberty IPA from master. That would solve my only
concern for 3.

>>
>> Other than that, I think 4 is the next best option.
>>>
>>> Cheers,
>>> Dmitry
>>>
>>> __________________________________________________________________________
>>>
>>> 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