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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
