On Wed, May 16, 2012 at 2:32 PM, Kaleb S. KEITHLEY <[email protected]> wrote: > Three points: > 1. RHS is intended to be deployed on special purpose "appliances."
Don't confuse supported with certified. They are two different terms. Red Hat supports many configurations. Red Hat IHV/ISV partners certifies a subset of those supported configurations. I deal with this daily (sometimes hourly) myself. ;) > In the storage world people don't use their storage appliances as general > purpose machines; they're dedicated storage machines. > Only those who have an RHS entitlement would/should be allowed to subscribe > to the Red Hat Storage channel, and I believe it would be highly unusual for > such a > customer to also subscribe their RHS appliance to other repos, including > the Fedora EPEL repo. I'll point out at least one major oversight in this assumption: Monitoring I can also think of about a half-dozen other reasons customers might tap EPEL here. > Enterprises aren't going to jeopardize their valuable data by using > unsupported configurations. Enterprises approve and release community software all-the-time, not just IHV and ISV software, on their Red Hat systems. They like EPEL as it provides many advantages over their own maintaining of upstream software. Also remember several enterprises employ maintainers are contributors to Fedora and EPEL. Continued interest to contribute to EPEL is very likely also dependent on working with Red Hat released and supported releases. > 2. I'm pretty sure it's the case that you can only get RHS updates, e.g. > glusterfs, and nothing else, from the Red Hat Storage channel. As with Clustering, Directory Services, etc... Child channels are additional entitlement offerings from Red Hat that are supported, certified with IHVs/ISVs in select configurations, etc... Many "EL Rebuilds" can and have taken the liberty to download the source, build, repackage and redistribute those additional entitlements as well. There's nothing stopping them from continuing in this role, as Storage now moves from a non-productized software to one that is an additional Red Hat entitlement. > Any regular RHEL or CentOS users who discover this channel, and who ought to > have access to the EPEL repo, only stands to encounter potential > confusion for glusterfs. Maybe I read that incorrectly, but I think that is exactly 180 degrees from the guidelines. ;) > 3. Niels mentioned it, but I think it merits repeating: GlusterFS has > been shipping EPEL6 RPMs since at least 2010, including GlusterFS-3.2.1 > in June 2011. (FYI, RHS started shipping in November 2011 after the > acquisition in October 2011.) It ought to be grandfathered regardless of > any other consideration. This isn't the first time this has happened. Red Hat has taken a codebase that it contributes to, even sponsors and/or purchases and ends up productizing it per customer requirements for support and/or certification. It won't be the last either. It's a delicate balance that I continually appreciate and thank the EPEL maintainers for. So the answer shouldn't be to look to the Fedora Project, but to look to the "EL Rebuild" projects to accommodate this change, like they currently do for Clustering, Directory Services, etc... Many claim to strive for bit-for-bit compatibility with Red Hat product offerings, so this is their area. > We (as in Red Hat, Fedora Project, and Gluster.org) have been providing > glusterfs RPMs for EPEL6 (and EPEL5) for a long time, and if we stop, > we're taking something away from the community. It's still in Fedora. It can still be in "EL Rebuild" repositories as well. Nothing is being taken away from the community. The guidelines seem to address this very well. >From my view, the guidelines were written to avoid this very detail. Again, it's happened before. And it will happen again. They do a great job of addressing it, to avoid marginalizing Red Hat customers, at least that has been my experience (first hand, at customer sites with EPEL deployed). -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
