Infrastructure

For ceph-volume tests, we would need public vagrant boxes for the relevant versions of RHEL in addition to entitlements. There isn't a vagrant box for libvirt/virtualbox at the moment for RHEL

1. Do we agree that RHEL support upstream is useful

Yes it would be very useful, particularly for Red Hat's public betas of RHEL, because these are beyond what CentOS has.

2. What needs to be done (maybe Red Hat support) to enable license availability?

I've asked the Entitlement team internally.

3. What will this require from sepia, images etc. and teuthology support standpoint?

David and Vasu might know more here?

Related chat from IRC

(09:08:33 AM) yuriw: ktdreyer: re: http://tracker.ceph.com/issues/23070 and BTW thanks for commenting.  If I ask hypothetical , say we added RHEL to upstream and want to test downstream RPM bits/releases, do you see this as complete impossibility ?
(09:08:48 AM) yuriw: gmeno ^
(09:09:00 AM) ktdreyer: yuriw: it is quite possible and a great idea IMHO
(09:09:09 AM) yuriw: vasu ^
(09:09:27 AM) yuriw: really ?  vasu said you'd kill me for asking this :)
(09:09:59 AM) yuriw: what would it take?
(09:10:01 AM) ktdreyer: lol
(09:11:03 AM) yuriw: dgalloway: ^
(09:11:51 AM) yuriw: clacroix: ^
(09:12:54 AM) dgalloway: i want to see what the entitlements team replies to ken
(09:13:51 AM) dgalloway: i already have a satellite server set up.  it's just a matter of changing a few things in ceph-cm-ansible and capturing some RHEL images as far as i'm concerned.
(09:13:56 AM) yuriw: do we have to compel them to ? :) 
(09:14:14 AM) ktdreyer: by the way the email I sent to the entitlement team was http://post-office.corp.redhat.com/archives/entitlement-team-list/2018-February/msg00060.html 
(09:14:30 AM) ktdreyer: I did not realize you have satellite already set up dgalloway
(09:14:52 AM) dgalloway: it seemed like the most secure way to lock down access to packages
(09:14:58 AM) ktdreyer: yeah, that's great news
(09:15:12 AM) dgalloway: or at least limiting access to 4-5 repos instead of all $hundreds
(09:15:13 AM) ktdreyer: I think we could just go ahead then
(09:15:44 AM) dgalloway: k.  it's on my to-do list
(09:15:53 AM) yuriw: just to clarify - per sage we are adding RHEL and keeping centos 
(09:16:02 AM) ktdreyer: ok
(09:18:11 AM) sage: hmm?
(09:18:41 AM) yuriw: we are talking about adding RHEL in sepia 
(09:18:47 AM) sage: to be clear: i don't object to rhel (if it doesn't blow up the amount of lab maint work), but i also don't see a huge need for it. 
(09:19:19 AM) sage: i don't see any rhel pain that comes from upstream testing on centos (tho that doesn't mean it doesn't exist)
(09:20:42 AM) yuriw: my hope is it will simply downstream/upstream troubleshooting, could allow downstream testing earlier etc. ktdreyer what else?
(09:21:11 AM) ktdreyer: it will be really handy when RHEL 8.0 Beta ships :)
(09:21:34 AM) ktdreyer: the RHEL team also ships public betas of each of the 7.y point releases
(09:21:40 AM) ktdreyer: so I think there's a 7.5 beta out now
(09:21:47 AM) yuriw: good point 
(09:21:52 AM) ktdreyer: that stuff does not go to CentOS until months later
(09:22:53 AM) hklein is now known as hklein_afk
(09:23:07 AM) yuriw: I think we also had some kernel pain related to not having RHEL
(09:24:05 AM) yuriw: I recall batrick saying that we run multimds on testing kernel and we would not have to do so if we had RHEL
(09:32:10 AM) pdonnell: yuriw: ok

Yes, I think if we had RHEL in sepia then we could do testing of cephfs kernel client on the distro kernel. Our testing on the latest kernel could be shielding us from bugs that exist on RHEL which could be caught by our qa suite.