Open Stack

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.

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